[Gnumed-devel] Plugin = Component?

[Christian Heller]

Hallo Horst,

[English Readers: See below!]

um die mitlesenden Anwender nicht mit technischen Details zu nerven,
sollten wir diese Diskussion vielleicht in die folgende Liste verlagern:
address@hidden
Von mir aus auch gnumed-devel. Oder beide.

> sehen. Das Problem ist dass wir immer noch durch einen evolutionaeren
> Prozess gehen, bei dem es wenig Sinnn macht Code auf die CVS Server zu
> laden der dann kurze Zeit spaeter wieder verworfen wird.

ist bei ResMed noch genauso :-)

> Das hat wenig mit Mangel an Planung zu tun als mit dem Ausloten
> "unbefahrener Gewaesser": wir versuchen, eine flexible plugin-faehige
> Architektur zu finden, die es uns erlaubt die "eierlegende Wollmilchsau"
> der Medizininformatik zu produzieren.

0 General Remarks

In the center, I see the Domain (Entities=DomainObjects=EHR-Model=~DB).
Around, there are several Applications (Modules), doing their very own
things such as EHR-Editor, LabData, FormPrinting/ReportGeneration etc.
Most of these Applications will have to access data of the Domain.

That's why I suggest a top-level distinction of Application and Domain and
that's why I created two independent directories for them in ResMedicinae.
KDE or GNOME for example are basically collections of Applications. They
don't have a special Domain directory because the data these Applications
are processing, are stored in files (or very small, Application-specific DB).
For our health domain, on the other hand, we need to create a big, common
Domain (Model) - similar to the GNUmed DB tables or to OpenEHR/GEHR. I guess
this kind of Domain would rather be comparable to SAP/BAAN/Peoplesoft's
Domain/DB Models.

1 Domain

For now, GNUmed/ResMedicinae should use their own DB models.
On the long run, however, these models should be replaced by the OpenEHR
ReferenceModel/Archetypes. That is also what the eventual
European/LatinAmerican/Australian (?) project will try to work on.

2 Applications

This is where we need to talk about things like ApplicationFramework/
Components/Plugins and Data/MessageExchange between Applications.
In ResMedicinae, I offer a common class (currently called AbstractApplication)
which can be used (by inheritance) as the parent class of any Application
(Module) to be created. Doing so, a developer gets offered a big amound of
default functionality for the new Application.
He/She doesn't need to use that default functionality, though. The
functionality (=Concern=Aspect) that _is_ used, however, should be indicated
by Interface classes. Example:

AbstractApplication (Module)    --- LabDataApplication
Configurable                    -|
Initializable                   -|
Displayable                     -|
...

The Module LabDataApplication inherits from class AbstractApplication
and also from the interfaces Configurable, Initializable and Displayable.
The interface Initializable forces the LabData Module to implement the two
methods "initialize" and "finalize". The interface Displayable forces the
implementation of the two methods "show" and "hide" or sth. similar.
When another (Main) Application starts the LabDataApplication, it needs to:

2.1 Call the constructor:

LabDataApplication a = new LabDataApplicationImpl();

2.2 Configure the LabDataApplication and hand over a Configuration object c,
to be determined somewhere in the code before:

a.configure(c);

2.3 Initialize the LabDataApplication

a.initialize

2.4 Display the LabDataApplication and possibly hand over a display
manager mgr (still need to figure out myself, am working on it):

a.show(mgr);

2.5 The other way around, the LabDataApplication would have to be destroyed
(hide, finalize, de/unconfigure).

That whole procedure is called lifecycle of a Component (=Module=Application)
and is described in detail at:
http://jakarta.apache.org/avalon/framework/lifecycle.html
http://jakarta.apache.org/avalon/framework/index.html

Now, concerning data exchange. To exchange messages between Applications,
there is something in Java called JMX. Don't know details yet.
To exchange data between Applications in terms of Client/Server, there
is CORBA/SOAP/RMI=RPC etc. It doesn't matter really if an Application is
a Client or a Server, since it can be even both at the same time. It can
offer data to other Applications through interfaces while using data of
other Applications as well. That is what people call "Distributed Objects".

That's why I don't know why OpenEMed distinguishes so hard (extra directories)
between Clients and Servers. But I think the reason is to offer clearly
separated Demo Applications for special purposes/CORBA IDL Interfaces.

I haven't done much with Plugins, but know roughly what it aims at (as user).
Could you write more on that?

3 Library/Framework

Like in KDE or GNOME, our Projects/Systems ResMedicinae and GNUmed etc.
should have a common library/Framework. This is the third top-level directory
in ResMedicinae, called "ResMedLib".

Keen on further discussion,
Christian