I wanted to expand on our notion of KISS; that is you take the approach
of starting with what you think is the simplest set of tools you need to
get the job done, and then add things as needs arise. We have been
doing this for one year and have a good handfull of applications using
this approach in production. None of them are clincal applications and
all of them use data integration via backend relational database
mapping.
We are not trying to build a collection of higher level network services
such as CorbaMed provides, our applications are pretty much self
contained, they get whatever they need from the local execution
environment, the database and the authentication server. This is pretty
much a 3-tier web application environment.
To make this understandable here is a rough diagram:
Client (browser) ------ Servlet container (HTTP) -------- SQL database
|----------
Authentication server
The addition of a layer of CORBA JavaBeans below the Servlet container and the SQL database
is all that is really needed to make this work in a more general way and is what
we have tried to build with OpenEMed. We have a number of examples in our current release.
All the performance issues we find are in the SQL database, not in the other CORBA layers.
The CORBA complexity is nicely offset by the logical componentization that goes on
that defines reuse of large objects in a very clean way. It reduces the generation of spaghetti code,
or at least keeps in nicely contained. Then in the future if you want to link to another
system using the same interfaces, there is no re-engineering to do.
I'm a strong believer in KISS, too. We've tried to make as simple CORBA components as possible.
Keeping the database SQL from the back end of the web server really simplifies that part of the
application and allows us to deploy with a very lightweight database or a big one with no recoding.
Where the dashed lines are the network. This is basically 4 network
services, all other services remain within the servlet container.
That's the main difference between this kind of environment and a full
blown distributed service environment. I can get all my id and name
resolution from our database's, I am not trying to get a name and an
authorization from another Medical School as would be the case if we
were building a virtual student record across several schools. Yes, we
do have information that comes from a variety of outside organizations,
but it comes with no real time needs and can be dealt with in periodic
'batch' style imports and exports.
SO what Dave and Thomas are talking about is just that, accessing, in
real time, information from multiple organizational entities. These
entities don't do backend database integration in real time, so one
can't get all the information from a single system. You have to make
network calls, and to that efficiently, securely and robustly, you need
something like Corba services.
So I really believe that there two kinds of fundamental use case
scenarios among the folks on this list:
1) Those whose real time data needs are largely self contained.
2) Those whose real time data needs are spread out among multiple
systems.
This will lead to different system architectures.
Yes, I know that the needs of #1 can be met with the more complicated
architecture demanded by #2, but KISS or Occams razor or just plain lack
of resources and a striving for maximal efficiency probably means that
#1 will be built with a simpler architecture.
I don't see this as a 'fork' in the code base ala some rapidly moving
open source projects. I see this as two different worlds, the forking,
if any, is yet to come!
Computer and Computational Sciences
Los Alamos National Laboratory
505-665-1907
