I think EJBs/J2EE fit the layered architecture model quite nicely. Let's
assume a five-layer architecture with layers as follows:
presentation
application
services
domain
persistence
(see http://www.c2.com/cgi/wiki?FourLayerArchitecture and
http://www.c2.com/cgi/wiki?HexagonalArchitecture)
The presentation layer can be implemented as JSPs, with JSP beans forming
the application layer. Clearly session beans form the services layer. For
the domain layer you have a choice of entity beans or domain objects or both
(with or without entity beans wrapping domain objects). For the persistence
layer you have whatever persistence mechanisms your domain objects or entity
bean load/store/create/find methods use.
The open-source FoodSmart example J2EE application on our developer's guide
CD (freely available at http://www.gemstone.com) uses this five-layer
architecture. It uses a Reified Layer pattern for the persistence layer.
Our domain objects implement CRUD methods that delegate to this reified
layer's API. Since our entity beans wrap domain objects, their
load/store/create/find methods simply delegate to their wrapped domain
object's CRUD methods (if they didn't wrap domain objects, they could just
delegate directly to the reified layer's API). We are able to switch an
RDBMS or OODBMS underneath the persistence layer at runtime, according to a
property read at startup.
If you use entity beans, it all depends on how you write your
load/store/create/find methods. Most EJB containers probably have little
choice but to use RDBMSes for persistent storage of entity bean state, and
their CMP implementations assume this. Entity beans add value in this
scenario by providing mechanisms for synchronizing with persistent storage.
But in GemStone you can use object persistence to store domain objects if
you so desire, and in fact entity beans don't add much value. Object
persistence is precisely why I have been using GemStone products since 1989
(I joined GemStone in 1999). Object/relational mapping can be a pain in the
neck at best, and a non-starter at worst (I've seen domain models that would
have been prohibitively difficult and horrendously inefficient to O/R map).
If you have to do it for legacy integration or enterprise stores of record,
you can still use object persistence for caching purposes, so as not to
incur the response time contribution of O/R mapping on every transaction.
Being a mathematician, I've never believed in proof by example :-) But
there does exist a freely available open-source J2EE/EJB application that
implements a very well-defined layered architecture, with reified layers and
policy-driven switching of entity bean encapsulation and persistent storage
sources behind the reified layers.
Does someone have a compelling argument as to why EJB *doesn't* support
layered architecture?
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: David W. Forslund [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, March 18, 2000 4:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB and ODBMS
>
> This is an excellent point and I would like to hear some discussion on
> this issue. We have not gone to the use of EJB because of this
> problem. They don't seem to fit our layered models very well. Is there
> a good answer here?
>
> Thanks,
>
> Guillaume Rousse writes:
> > In a well separated layer design, applicative layer should be
> independant of
> > persistance layer. So the use of a OODBMS or A RDBMS should not
> influate
> > modeling in the application layer.
> > Entity beans are clearly violating this separation rule. But from what
> i've
> > understood so far, session beans were designed to model process rather
> than
> > concept. Moreover, they have no persistance. So how can you use them to
> model
> > real-world entities ?
> > As they are powerful open-source RDBMS, and even hybrid DMBS available,
> this
> > question is important for people aiming public research project, rather
> than
> > e-business.
> >
> > Le jeu, 02 mar 2000, vous avez �crit :
> > > You can use Entity Beans with OODB, but it is overhead and does not
> add
> > > value. Session Beans to pure objects is a very nice model. Very clean
> on the
> > > server side, and forces Service Based Architecture, which we think is
> a good
> > > thing.
> >
> > Cheers
> > --
> > Guillaume Rousse
> >
> > Iremia - Universit� de la R�union
> > 15 avenue Ren� Cassin, BP 7151
> > 97715 Saint Denis, messagerie cedex 9
> > Tel:0262938330 Fax:0262938260 ICQ:10756815
> >
> > BRIDGEKEEPER: What... is the air-speed velocity of an unladen swallow?
> > ARTHUR: What do you mean? An African or European swallow?
> >
> >
> ==========================================================================
> =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> --
> David Forslund Voice:(505) 665-1907
> Advanced Computing Laboratory FAX: (505) 665-4939
> MS B287 EMAIL: [EMAIL PROTECTED]
> Los Alamos National Laboratory WWW: http://www.acl.lanl.gov/~dwf
> Los Alamos, NM 87545
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
