I'm glad the discussion on this list has come back to some real interesting
topics, after all the weeks of exchanging blows.
My suggestion for the layers of an (ideal) system looks like this:
webbrowser
|
/----------------------------------- network
/ |
userinterface (standalone) / userinterface (web)
| / |
--------------------------/ |
| |
| |-------------------------|
| |
application
|
domain (perhaps with oodbms) --- network --- otherdomain (end of the world)
|
datainterface (if rdbms)
|
datasource (rdbms)
Some explanation:
The well known 3 tiers are 1 userinterface, 2 domain, 3 datasource.
Domain is the core, the layer containing the actual business objects in a
certain structure and logic. That's where Thomas' and Daves works fit in.
The datasource and datainterface layers are only necessary when using RDBMS.
In this case, the optional datainterface layer does nothing than translating
the OO structure of the domain into the ER model of the database.
They get superfluous when using an OODBMS which smoothly integrates into the
domain layer.
To increase the flexibility of a system, it is always helpful to have
an (optional) application layer. It does nothing than implementing the actual
workflows of interest for an application, i.e. it just accesses the objects
of the domain layer and works with and changes them. Hence, this layer can be
seen as a collection of special methods/use cases/business scenarios/views
on the domain objects.
What's left is the userinterface layer. Basically, it can be textual or
graphical or anything else provided some special devices, e.g. for blind
people. I wouldn't call it presentation layer, as it also receives input
from users, so the name interface suits better.
Having a graphical user interface, it can be either a classical standalone
application (e.g. Swing) or web based (JSP/servlets). Actually, most projects
use the JSP/Servlets as their application layer encapsulating the workflows.
But if one wants to offer both, standalone client and web based access,
it is better (in my mind) to encapsulate the workflows in an extra
application layer that can be accessed from the standalone client as well as
from the web layer. The browser is not a layer as it just displays the
data coming from the web (userinterface) layer.
I don't like to use the terms "client" and "server" for special layers.
Nearly every layer can act as a client as well as a server.
Likewise there can be network connections not only between userinterface
and application layer or web layer and browser as shown above -
every layer can run as an own application being connected to others
over network only. Of course, that doesn't make always sense.
I tried to put it all into some html but it doesn't look so nice.
Also, some of the techniques mentioned there might not be sorted quite
correctly yet. And the forking from the application layer to either
a standalone or a web userinterface as shown above couldn't be displayed
properly in the table by me. Your comments are welcome! Here's the link:
http://www.tuxtax.de/en/service/training/develop_software.html
For the moment, I see my part in the creation of a Java Swing user interface
and that's what I am coding on since some weeks. I had synchronized this task
before with David's OpenEMed which already includes some web based interfaces.
Of course, I plan to implement the CORBAmed/HDTF interfaces later and try
to access David's test servers. But that still needs time...
My today's question goes around that implementation of CORBA again:
The objects (e.g. EJBs) of the domain layer must have CORBA interfaces
to provide data access to all applications out there, that's clear.
Imagine, I have my Swing userinterface application and want to fill it
with data. Of course, I will use my own application layer that serves
the userinterface with data. Now, this application layer gets its data from
a domain layer - but which one? There are many servers around the world
running such domain layers.
1 Is my application layer responsible for managing the location where to get
my domain objects from, automatically?
2 Does the user always have to choose the server he currently wants to access
(like in the OpenEMed test client form)? That is not very comfortable.
3 Perhaps I just set one fixed domain server for my application layer and
the domain servers are responsible to exchange data among each other?
To repeat it in short:
Is there connections between the domain layers as shown in my "picture" above
or are certain domains around the world only accessed from application layers?
Thanks,
Christian
> >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.
