[Gnumed-devel] gnumed architecture

[Horst Herb]

Somehow we are moving in circles.

The original idea was a three tier architecture: user interface, transactional 
middleware, and dumb datastore

However, no matter how hard I tried, I found no way of reliably preventing 
users from bypassing the middleware and doing stupid things on the backend, 
so we decided to scrap the middleware and implement as much bsiness logic as 
possible on the server via stored procedures

Then, the concept of splitting the monolithic database into "black box" style 
"services" was requested and generally found useful. Since the backend itself 
has trouble preserving referential integrity between databases, we again 
needed some "middleware".

Strangely, this middleware layer slowly seemed to creep into the user 
interface layer via "business objects". Now the UI client gets fatter and 
fatter. Do we want this?

I spent the past 4 month doing nothing else (for gnumed) but rethinking our 
architecture. I tried out a large number of distributed service concepts 
(DCE, SOAP, XML-RPC, CORBA, and dozens of esoteric ones). To my shame I must 
say that te best performing language independent one I found so far is CORBA 
which I initially outrightly refused for it's complexity. It still has quirks 
with authentication, but it is fast.

XML-RPC via Jabber is fast too - not as fast as CORBA, but magnitudes simpler 
to implement and authentication works reasonably well. The automatic 
"store-and-forward" capacity, the "guaranteed delivery" option etc. make it a 
reliable workhorse for any kind of information exchange, and persistent 
connections reduce the performance penalty for traditional XML-RPC via HTML 
considerably.

If we would limit ourselves to Python (which we should not), PYRO (Python 
remote objects) is a wet dream for any distributed system developer.

Why am I mentioning this? The point I want to get at is again our 
architecture: Once we separate our services cleanly into truly independent 
services, and bolt any kind of reliable RPC interface onto the backend, we 
can pack all business logic needed onto the backend in a way that the 
interface implementation becomes simple and straightforward again. You user 
interface presents the data x-y-z style?  - The services delivers the data 
x-y-z style, voila.

We would not even need the rather heavy PyGresQL+ DateTime libraries on the 
interface clients any more. We could stop bickering which way to present data 
on the user interface is best, since user interface implementation would 
become more trivial again.

Only problem is that I still don't know which RPC interface wil be best suited 
and most future proof for us. And I still don't know what the most sensible 
way of splitting our databse into services is. I do believe increasingly that 
demographics and geographic information should not be separated after all 
(???) since still in too many countries people are identified (silly enough) 
by their addresses, causing a huge performance hit when you subsequently have 
to query two different services multiple times for common views (like a 
Patient selector box).

Horst