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@yahoo.com]
Sent: 07 October 2000 14:18
To: pgsql-novice@hub.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@yahoo.com)

http://www.geocities.com/siliconvalley/campus/5261
<http://www.geocities.com/siliconvalley/campus/5261>

 

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