Re: [Gnumed-devel] Where to start with gnumed

[Horst Herb]

On Tue, 25 Feb 2003 09:31 am, richard terry wrote:
> What is a XML-RPC interface.

An interface for rwemote procedure calls

> Does that mean we drop wxPython and use a web interface!

Has nothing to do with the user interface at all (other than potenially 
simplifying user interface development tremendously - you can go ahead and 
implement, all you need to know is the current API which you can modify to 
your hearts content as long as you don't break backwards compatibility)

> Can you explain all this in simple terms.

Our API currently requires that all called procedures reside on the same 
machine, unless you communicate directly with the backend (Python function 
calls or libpq function calls).

We need an abstract API, but we don't want to sacrifice the power of direct 
backend communication.

The idea is to take our concept of "services further, where it should have 
been in the first place: any service can reside on whatever machine wherever.
*Within* a service, all modules talk directly to their own backend.
*Between* services, they talk to each other using remote procedure calls.

Example for "standard" remote procedure call protocols: CORBA, SOAP, XML-RPC.
Example for "non-standard" RPCs: our backend interface (all the way from libpq 
-> PyPgSQL -> gmPG non standard)

CORBA and SOAP are heavyweight protocols, involves a lot of work to fully 
implement. CORBAMED is even worse. 
XMLRPC is feather light, versatile, and if you stick to basic data types like 
numbers, strings, list and dictionaries nothing can go wrong

Now, the *user interface* does not need direct access to the server. Our 
business logic does. Business logic gets packed into services, services get 
an API that is callable via XMPL-RPC *as an option!*, and everybody is happy.

If one day we think that OSCAR's (just as an example - nothing negotiated yet 
with them other than brief talk to David Chan during the LA conference that I 
am planning to do so and he loves the idea) immunisation database 
implementation is smart - we use their XML-RPC interface and do not worry how 
they have implemented it and what backend stores the data. They can use our 
"address book" or "social history" in exchange.
If either party one day decides  that the respective module is not up to 
scratch, you simply re-implement that module, but it won't break your 
application.

In short: the concept of API is extended to a distributive model. The 
simplicity of XML-RPC allows even non-experienced programmers to participate 
in development. It allows abstraction of services in a *language independent* 
(!!!) way. You can implement one module in C++, one in Java, and one in 
Python and you'll never be able to tell the difference at application level.

To illustrate the simplicity, have a look at the attached myserver.py and 
myclient.py which implement a simplicistic "proof of concept" client and 
server.

Horst

myclient.py
Description: Text Data

myserver.py
Description: Text Data