[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] New Zealand's Intrahealth
From: |
Syan Tan |
Subject: |
Re: [Gnumed-devel] New Zealand's Intrahealth |
Date: |
Sun, 17 Jul 2005 19:27:28 +0800 |
On Sun Jul 17 17:31 , Elizabeth Dodd sent:
>
>it does run on interbase.
>
I once had to do a 3 tier student app with 2 fellows for a
distributed computing subject (mtech at rmit),
and it had ultimately a SQL Oracle backend , running ? somewhere,
(? numbat , yallara, melanoma ) ; the idea was to get
a thick client which ran on your windows student machine (the UI layer)
that made java remote method invocation calls to
various processes ( the CS layer , composite service)
running on ? yallara, that then made DAS ( data access) RMI
calls to processes running on numbat , that then produced
SQL queries for oracle running on melanoma (or some such name)
, get the results back as (wrapped up in java sql api ResultSet objects),
remap back into serializable data objects , to send back to
composite services, that may repackage, further process the data again,
and send it back to the thick client as serialized objects,
which the thick client then maps to the java swing UI framework objects.
gnumed does this, but doesn't physically make the business objects (CS +/- DAS)
remote, but runs them in the same process as the thick client's, and
SQL is sent over the wire to the database server.
The advantage of having a remote business and data access interface might
be reusability across different kinds of applications accessing the
same data. Actually, what the point of the subject we did was, that
asynchronous Message Queues might work better across an enterprise of
disparate legacy applications that require integration, than synchronous
remote method invocations, or distributed transactional SQL (XA interface)
which might cause more blocking , but we never got to implement it !!