I forgot to copy EJB-INTEREST; let's break down the arguments
> > Arguments for a Session Facade:
> > ========================
> > 1. With the advent of Local Interfaces, the main argument for
> > the use of a
> > Session Bean facade in the case where a GUI request maps to a
> > single entity
> > bean is separation of responsibility and the ability to take
> > advantage of
> > tools that leverage separation of responsibility:
> > a. Separation of responsibility means that we should have a
> > separate class
> > that handles just the persistence. A facade class will use
> > that class as a
> > 'helper' class; the client sees only the facade. Separation of
> > responsibility brings with it the promise of easier maintenance.
Bottom line, let's use a tool that creates DAO's / BMP implementations, but
are fired
from a Session Bean; what about implementing VO's, then?
> > b. Separation of responsibility also means that we can use
> Entity Bean
> > object-to-relational tools (e.g. JBoss' JAWS) to generate the
> > code for us if
> > we're using BMP Entity Bean (and, although we could still add
> > the code for
> > the freshness mechanism to the callback methods of the BMP
> > Entity Bean, it
> > would be kludgy).
Again, it looks a lot like a DAO / VO's approach. What I would do is have
the DAO (Persistence-Manager) written as a class (not session nor entity),
then used from wherever you like.
Both ways should work, but from an OO's point of view, I'd keep everything
in the Entity Beans. I wonder if many of the Session Facade supporters down
there used to be MTS/COM+ developers.
HTH, JP
> -----Original Message-----
> From: Bill Leonard [mailto:[EMAIL PROTECTED]]
> Sent: Mi�rcoles, 05 de Septiembre de 2001 16:29
> To: 'Juan Lorandi (Chile)'
> Subject: RE: Entity and Session Facade Design Debate
>
>
> Thanks for looking at this, Juan.
>
> Note that you didn't CC the EJB-INTEREST group; therefore,
> I'm replying only
> to you on this (and I also posted a clarification to my
> original post in
> order to provide some additional information).
>
> I had trouble understanding the response - meaning, how are
> the arguments
> for separation of responsibilities dependent upon lack of
> support for Local
> Interfaces and Dependent Objects (or, for that matter, how
> are the arguments
> dependent on support of these mechanisms)?
>
> -----Original Message-----
> From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 05, 2001 4:10 PM
> To: 'Bill Leonard'
> Subject: RE: Entity and Session Facade Design Debate
>
>
> Most of your arguments for a SB Facade fall apart if the
> (new, unpublished)
> spec doesn't consider Local interfaces; Local Interfaces &
> Dependant Objects
> are leaving the spec. Gene, have you heard anything 'bout it(Local
> Interfaces leaving the spec) ?
>
> JP
>
> > -----Original Message-----
> > From: Bill Leonard [mailto:[EMAIL PROTECTED]]
> > Sent: Mi�rcoles, 05 de Septiembre de 2001 15:19
> > To: [EMAIL PROTECTED]
> > Subject: Entity and Session Facade Design Debate
> >
> >
> > I (and others in my company) are EJB newbies and could really
> > benefit from
> > some feedback on this. I'm hoping that people can add
> > arguments or let me
> > know where mistakes have been made in the logic.
> >
> > In my current company, there has been some discussion with
> > respect to what
> > should be in the Entity Bean. We want the Entity Bean to handle the
> > persistence to the database but the issue has become fuzzy
> > because we have
> > this mechanism that indicates whether an object's data in the
> > database is
> > 'fresh' with respect to the device which is the source of the
> > data. If a
> > request for data indicates that the database is not in sync
> > with the device,
> > we go to the device and update the database. We then return
> > the data from
> > the database.
> > => I show examples of the implementation of both sides at the
> > end. These
> > very much help to show what I am trying to get across. <==
> >
> > The 2 sides of the issue are:
> > 1. Entity Beans should only be used for persistence to the
> > database. Any
> > other mechanism (such as our freshness mechanism) should be
> > handled by a
> > facade class. In our case, we would create a Stateless
> > Session Bean as our
> > facade.
> > 2. Since this 'freshness mechanism' is part of the
> persistence for the
> > object, all of the code for this should be in the Entity Bean.
> >
> > If the 'freshness mechanism' were not so closely associated with the
> > persistence of the object, there would not be an issue.
> >
> > Note that I want to consider these in the light of Local
> > Interfaces so that
> > different clients can use either remote or local session or
> > entity beans.
> >
> > Arguments for a Session Facade:
> > ========================
> > 1. With the advent of Local Interfaces, the main argument for
> > the use of a
> > Session Bean facade in the case where a GUI request maps to a
> > single entity
> > bean is separation of responsibility and the ability to take
> > advantage of
> > tools that leverage separation of responsibility:
> > a. Separation of responsibility means that we should have a
> > separate class
> > that handles just the persistence. A facade class will use
> > that class as a
> > 'helper' class; the client sees only the facade. Separation of
> > responsibility brings with it the promise of easier maintenance.
> > b. Separation of responsibility also means that we can use
> Entity Bean
> > object-to-relational tools (e.g. JBoss' JAWS) to generate the
> > code for us if
> > we're using BMP Entity Bean (and, although we could still add
> > the code for
> > the freshness mechanism to the callback methods of the BMP
> > Entity Bean, it
> > would be kludgy).
> >
> >
> > Arguements for using just the Entity Bean:
> > ===============================
> > 1. Since the freshness mechanism is an essential part of the
> > object, it
> > should be part of the entity bean.
> > 2. Why introduce the extra overhead of a facade? We now
> have 2 beans
> > instead of one. Even with the use of local interfaces, we
> > have the overhead
> > of EJB itself for the second bean.
> > 3. In the case where a client request for data maps to a
> > single Entity Bean,
> > we don't need a facade to encapsulate the interaction of
> > multiple beans; the
> > methods of the Entity Bean provide all the encapsulation we need.
> > 4. Again, in the case where a client request for data maps
> to a single
> > Entity Bean and the Entity Bean methods are not units of a
> transaction
> > (meaning, each method call is its own transaction; it doesn't
> > participate in
> > a transaction with the other method calls), we don't get the
> > problem of
> > 'long transactions'.
> > 5. If we need to use BMP, writing JDBC is no big deal. What's so
> > advantageous about using CMP?
> >
> >
> > Implementation Example of the Session Facade:
> > ===================================
> > // Session Bean Facade to Entity Bean that just handle the
> persistence
> > class NetworkElementStatelessSessionBean
> > {
> > int getNumberOfCards()
> > {
> > if
> > (dataFreshnessEntityBean.isFresh("NetworkElement", key)
> > == STALE)
> > {
> > NetworkElementData networkElementData =
> > device.getData(key);
> >
> > networkElementEntityBean.setNumberOfCards(networkElementData.g
> > etNumberOfCard
> > s());
> > dataFreshnessEntityBean.setFresh();
> > }
> > return networkElementEntityBean.getNumberOfCards();
> > }
> > }
> >
> > Implementation Example of the just using an Entity Bean:
> > ==========================================
> > // Entity Bean handles the persistence and also implements
> > the freshness
> > // mechanism that is closely tied to our persistence
> > class NetworkElementEntityBean
> > {
> > int getNumberOfCards()
> > {
> > if
> > (dataFreshnessEntityBean.isFresh("NetworkElement", key)
> > == STALE)
> > {
> > NetworkElementData networkElementData =
> > device.getData(key);
> > numberOfCards =
> > networkElementData.getNumberOfCards();
> > dataFreshnessEntityBean.setFresh();
> > }
> > return numberOfCards;
> > }
> > }
> >
> > ==============================================================
> > =============
> > 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".
> >
> >
> > ______________________________________________________________
> > ______________
> > For your protection, this e-mail message has been scanned
> for Viruses.
> > Visit us at http://www.neoris.com/
> >
> ______________________________________________________________
> ______________
> For your protection, this e-mail message has been scanned for Viruses.
> Visit us at http://www.neoris.com/
>
==========================================================================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".
