[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] distributed db <-> service config

From: Christian Heller
Subject: [Gnumed-devel] distributed db <-> service config
Date: Fri, 27 Sep 2002 13:42:31 +0200
User-agent: KMail/1.4.1

> Table db is a general table defining how to reach the various
> databases that can be used in a GnuMed system. Those may be
> hosted virtually anywhere as long as they are reachable via
> Table distributed_db is just a list of service names known to
> GnuMed. It's main purpose is to normalize the service names
> out of the service<->db mapping. This table should actually be
> called something like "service" (any objections to renaming ?).
> Table config maps service names to physical database
> locations. It links one database to one service for a

May I ask what you mean with "Service"? Any local/remote application
offering a service (being a server application)?

In ResMedicinae we are seeing one "CommunicationPartner" which can be:
- XML file (Stream)
- any Database (SQL)
- remote Server (CORBA, SOAP-XML, RMI)
- User (yes, even the user, as the application is a system and the user
is another system and both communicate; but that leads to far now)

For each possibility there is a special model:
- DomainModel (core of the system data)
- OO model for XML
- Entity-Relationship Model for DB
- DataTransfer Model for remote processes

The core of every system/application for us is the OO DomainModel.
1 A system queries a remote server for some EHR data.
2 The data are retrieved in the DataTransferModel structure.
3 The data are translated by an "Assembler/Mapper" class from
DataTransferModel into the core DomainModel.
4 The application/system now works on those data.
5 The date shall be written out to a DB.
6 Another Assembler/Mapper object translates the DomainModel data
into an EntityRelationshipModel (mostly called the "Mapping" layer;
EntityRelationshipModel mostly has one class per one DB table)
7 The EntityRelationshipModel data are now send to the DB service.

Does that make sense in your way of thinking?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]