Even if others think that this exchange is entirely benighted, I would
appreciate other comments. Particularly from Dave and Thomas.
John
At 04:03 PM 5/18/01, you wrote:
>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
