Re: Thanks...and then the question:Architecture.

Stoffel van Aswegen wrote:
Unfortunately I haven't received much replies to my question. I am very new to
this all so I actually have no experience to share. The independency matter you
mention sounds like a good argument for building it the way I thought. The
independency I would get is "client(s) <->XML<->middle server<->SQL<->database"
which sounds good to me.

> I haven't seen any replies to your question - I'm also interested in this
> since I'm busy with something similar. If you have received any replies,
> please forward them to me.
>
> In my design, the front end (PHP scripts on a web server) talk to a middle
> tier app (dbagent written in C++) which is responsible for issuing queries
> to the (PostgreSQL) database - whether the queries are explicit SQL or calls
> to stored procs.
>
> So far, the benefits that I've seen, is that this architecture makes the
> entire app independent of any particular implementation/tool/technology. I'm
> using PostgreSQL, but if I need to implement it on MySQL which does not
> support stored procs or nested selects (I think), the dbagent will take care
> of it. Also changes in the middle or data tier is independent of the front
> end and vice versa.
>
> I've decided to use sockets for comms between the PHP scripts and dbagent. I
> have not got things running well yet, and dbagent is still just a single
> user app. In future, I might fork() dbagent and have the child process
> handle the actual request from the php script. This will (hopefully) make
> dbagent a multi-user app. Thinking about it now, if I use fork(), will it
> create another connection to PostgreSQL? What is the effect on multi-user?

Well I have nothing running, in fact I haven't written a single line of code
yet :-) All is in planning stage. What regards forking I understand it as
follows:when a process is forked you can regard it as a separate client to the
postgresql can't you? That is what I believe so it shouldn't be a problem. My
current idea is exactly to let the middle server ( in my picture ) fork on
requests from a client and let the forked process connect to the database. My
idea is also to let the client application ( leftmost in the picture, GUI
applications in my case ) live for a long time, e.g. started in the morning and
closed in the evening. Thus the forked process would live the same amount of
time as the GUI app and the actual database connection would be done right
after the fork and stay open for the same amount of time as the clients are
alive.

>
>
> I've not looked at security closely. I've created a single user (other than
> postgres superuser) which has access to the database. dbagent creates a
> connection as this user. This way, user access is limited to one more than
> the postgres superuser. (I still have to figure out how to disguise the uid
> & pwd in the code - I don't want to use: "user=dbagent passwd=abcd" since
> the literal strings are embedded in the executable as is.)

Security is also something I know too little about. One idea I got the other
day was to use some kind of encrypted tcp/ip connection but I don't know
how.Best Regards,
Greger

>
>
> -----Original Message-----
> From: Greger Haga [mailto:gregerhaga(at)yahoo(dot)com]
> Sent: 07 October 2000 14:18
> To: pgsql-novice(at)hub(dot)org
> Subject: [NOVICE] Thanks...and then the question:Architecture.
>
> Dear all,
> Thanks to all who replied to my "can you see it" posting.
>
> Here's my question:
> The question relates to architecture and what I am wondering about is the
> picture I am enclosing( Please see attachement ).
>
> The figure enclosed shows a number of clients communicating with a number
> server processes which in turn calls libpg ( or was it libpq, anyway ... )
> which then communicates with the database postgresql. What I am wondering
> about is the pros and cons of such an architecture, is it possible to do?
> and what's good and what's bad with it. I am in the early planning stage of
> a billing system for linux. No code is written yet, and won't be for a long
> time, until I have straightened a few things out. My idea is to use TCP/IP (
> sockets + XML ) to communicate between clients and the middle server's
> processes and the middle server's processes then communicate with the
> postgresql database. The middle server would handle all requests from the
> client, the client would be of various types for several different tasks,
> each task involving querying the database.
>
> I would very much like to have opinions from anyone with some experience
> designing similar systems. I have very little experience of client-server
> solutions and none on postgresql so I might be totally out of line...if so
> you are more than welcome to push me in the right direction.
>
> Thanks for reading,
> Best Regards,
> Greger
>
> --
>
> Greger Haga (gregerhaga(at)yahoo(dot)com)
>
> http://www.geocities.com/siliconvalley/campus/5261
> <http://www.geocities.com/siliconvalley/campus/5261>

--
Greger Haga (gregerhaga(at)yahoo(dot)com)
http://www.geocities.com/gregerhaga