Oops, perhaps you caught me in my lack of knowledge.
I will just write how I see the things hoping somebody else helps me out.
To start with, once more the layers to have some names to relate to:
1 userinterface
12 application <----|
2 domain |----> other domain layer (distributed system)
23 datainterface
3 datasource (RDBMS)
On Friday 18 May 2001 19:07, John S. Gage wrote:
> >I mean, domain (= middle) layer and database have a much stronger
> >dependency than for example a userinterface and domain layer.
>
> In the face of this dependency, I'm a little confused as to what the middle
> layer does. If for example, it simply automates SQL queries and relieves
> the user of the labor of writing SQL him/herself, then it certainly doesn't
> contribute to interoperability. If on the other hand, it permits full
> interoperability, then I'm not sure where the dependency comes in.
In my definition, the middle layer is the same as the domain layer.
The domain layer provides the business model, the system structure, the
static relationships between the objects. The objects just encapsulate the
data and some behaviour. In my 5-layer-model above, the datainterface
layer would have the task to receive asks from objects of the domain layer,
do SQL queries and finally provide the retrieved data back to the domain
layer.
You made me thinking now about what happened if there was no domain layer
and also no datainterface layer. Well, the application layer would have to
care about all the SQL queries etc. It wouldn't have to be written in OO
architecture even! But then the code would mix up thousands of unsorted
methods (functions/procedures). That is, because there would be no objects,
just entities (tables). The entities contain attributes (data) but no methods
(behaviour). In the end, one would loose overview and changing one piece
of a function somewhere would cause many changes everywhere else -
Spaghetti code.
May be that was clear to you and I got you wrong. So now let's consider
the interoperability. Don't mix the access of a domain layer to its database
with the interoperability of multiple domains! CORBA and all that is situated
in the domain layers running on many servers around the world. Having
an application (layer) with CORBA interfaces, it can access any of those
domain layers (which may have there own OODBMS or RDBMS) on any server.
See "other domain layer" in my drawing above.
Was that your question?
> >OODBMS are even implemented within the domain layer. They just store
> >the objects used by the domain layer as they are - as objects.
>
> But, to the extent that OODBMS are implemented in the domain layer, they
> aren't middleware and don't promote interoperability, right?
Yes. They are not responsible for interoperation between domains (middleware).
All they do is storing the data (states) of the objects of the domain layer.
But don't ask me more about OODBMS :-}
> >RDBMS exist outside the domain layer but their goal to store the data of
> >the domain layer makes them dependent on the domain object structure.
>
> Did E. F. Codd say that? I would rather say that they depend on the domain
> itself.
Of course the ERM depends on the considered problem/business domain.
I was presuming one uses an OO modeled domain layer that has to talk
to an ER modeled database. As both, domain and database layer mirror
the structure of the same domain, one better synchronizes their structure
for easier data exchange between them. Using EJBs for example, one can
accelerate this process by generating EJBs for each ERM database table.
Mr. Codd probably didn't know in 1970 what OO is all about.
> >It wouldn't make sense if some people created an OO model with objects
> >having certain attributes and you created your tables which represented
> >completely different entities=objects with attributes spread all
> > differently.
>
> But neither of those would be middleware.
True. I was talking about a domain layer and its underlying database.
The domain layer can contain middleware but that has nothing to do with
the pure database communication.
> The point I'm trying to make is that I have absolutely no gripe against
> modeling the domain with just about any tool one can get one's hands on
> (there are many commercial products that just use flat files), but if one
> starts to talk about interoperability, one has to have a layer that can
> talk to *any* model of the domain, I would think. Otherwise, don't call it
> middleware and simply use it directly to model the domain.
>
> John
Yes, if the domain layer contains middleware functionality such as CORBA,
many types of (remote) applications can talk to it. Likewise, if an
application layer contains CORBA IDL interfaces, it can talk to many types
of (remote) domain servers. The models of those servers don't have to be OO
even, as long as the neutral IDL is used to define their interfaces. We call
all participants just "components" that have certain interfaces and we don't
care about how they look inside.
Again, don't think a middleware component must be able to talk to a (remote)
RDBMS (ER model) directly. Where in this database would you want to implement
the CORBA interfaces and stuff? You don't talk to the database
(layer 3 in my picture) directly but to a layer above it that contains
the CORBA stuff and organizes the database access for me.
Christian
