Andrew po-jung Ho wrote:
> Hi Dave,
> Excellent points! Since federated systems are exactly what I am interested in
>implementing, I will do my best to address some of the issues below.
> ---
> On Sat, 11 Nov 2000 22:49:49 David Forslund wrote:
> >How does one create a federated system with Zope so that a medical record
> >could be created
> >from multiple repositories working together?
>
> Inter-node communications can go through CORBA / XML-RPC / SOAP / HTTP etc. This is
>not different from any other application server or system.
That's the technical side. Real question is what is the object model being used? I.e.,
CORBA and the rest expose an object-oriented interface of a server to the network.
This interface is defined by an oo model; so a choice has to be made here. For
example, CORBAmed's PIDS interface specification is effectively a model for demographic
information.
> > Especially, if each does it a little differently?
>
> Now, you know very well there is no magic bullet for this (except CORBA?). The
>solution must include some type of metadata standard. This has nothing to do with
>whether the implementation is done with Eiffel, Zope, C++, etc.
Well.... not quite. Back to the GEHR kernel: the interesting thing about it is not
really that it's done in Eiffel, it's that it processes archetypes, (i.e. knowledge
definitions, or if you like, meta-data definitions) written XML-schema. It is
completely data driven by these definitions, and the development and operational
context for
archetypes is what turns it into a different class of system. (I did not invent this
kind of concept of course - there is a great deal of literature on data-driven and
meta-modelled systems).
So archetypes provide a kind of meta-data standard to drive systems with. They are
designed to be edited standalone, managed and QA'd by clinicians, and used to drive
installed systems. Most of all, they are designed so that standardisation processes
can be built around them, without reference to any software technologies whatsoever.
GEHR archetypes as they stand today are not the last word on this approach, on the
contrary, they are just a beginning. But all the same, the approach is already bearing
fruit. For some time now, we have been able to perform the process mentioned above
(write an XML-schema archetype, parse it via Java & Eiffel, load it into a GEHR
database, retrieve it, and finally, build EHR content compliant with the archetype,
and save that as an EHR transaction).
Whether or not you like Eiffel is irrelevant; you could write a homologous system in
Java if you wanted.
> >Zope seems to be a deployment platform but hardly a system development environment.
>
> Not sure what you mean by that. If I can *develop* an application using Zope, then
>I think it qualifies as a "development" environment. It may not be the *preferred*
>development environment for all possible applications (for example- it is probably
>not suitable for developing the next version of Quake), but that does not say much.
Well, as per my other post, the core problem in designing systems is doing the
business logic, or middleware model and software. Database and front-end are really
predicated on this. And Zope is not suited for developing such a model or software at
all; however, it seems that it could provide a nice back and front-end "sandwich"
environment to do the core development in/with.
> >It should be possible to drop a GEHR kernel into Zope and have it provide services
>for it.
>
> Do you mean like an ORB?
He means that he kernel provides "services" (available as functions/objects in an OO
API) which relate to the high-level concepts of a model of an EHR, e.g. GEHR's
"transaction", "organiser", and various other content classes. So... front-end talks
to GEHR (and hence only needs to know about high-level concepts); middleware converts
these concepts, eventually, into calls to store and retrieve data in a database or
some kind of persistence mechanism (or another, lower-level CORBA enabled data
service).
> >If I have a Java application, how do I use Zope as an application server for that
>application?
>
> Zope does not have a built-in JVM and thus does not run Java. Thus, server-side
>Java is not supported. However, it can serve Java Applets just fine.
Which is what you would write your GUI in. But the question about the server side
relates to business logic.
> >Especially one that might need to communicate cooperatively with a number of other
>heterogeneous
> >applications to create a medical record for a patient.
>
> I think the keyword here is "heterogeneous". Currently, OIO exports
> metadata in XML format. This means compatible systems are defined by
> their ability to use that metadata. Data interchange is easy among
> compatible systems since metadata is transportable. This is really no different
>from any other data interchange schemes. Two systems that wish to communicate must
>have at least one shared metadata format. It could be TCP/IP, CORBA, ASCII,
>OIO-forms, etc.
They need more than the same format - they need to agree to a common meta-data model.
I think we're getting somewhere with this!
- thomas beale
