Thanks for the feedback, Juan ... I'm learning alot from the discussion both
at work and here so ... here are my comments/questions ...
>> 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?
>> 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.
I'm trying to think of this in terms of how I would get automatic
transaction and synchronization management. If I don't need these, then I
would have no need to use Entity Beans. But if I want to use this, then ...
Let's say I use a tool that creates DAO's for the 2 persistence classes that
I need. 2 regular Java classes are produced, let's say FreshnessDb and
NetworkElementDb. For the sake of the example, I'm assuming that I'm not
modeling the relationship between these in the object or data model;
therefore, I need to interact with both of these classes in code (use one
and then separately use the other). I still need to provide code to check
the FreshnessDb and then go to the device and then update the
NetworkElementDb and FreshnessDb. This code, let's say, is put into a
non-bean Java object, NetworkElement.
The client needs distributed access which means I need to put this code into
a Session Bean for the distribution part (I could also hide the distribution
from the client with a wrapper object). If I now wanted automatic
transaction management, I would have to provide it on the session bean
method, right? This would mean that I would have less granularity in terms
of locking resources for the transaction, right? (because I can't use
automatic transaction mgmt on my non-bean persistence classes). Of course,
I could just do the trans mgmt manually but ... I want to use tools and
automate my tasks. In this scenario, I also thought of entity bean's
support for automatic syncing of data in memory; we lose this with this
approach (unless we deploy it in an entity bean with set/get methods) but I
don't know how much of a need there is for this.
>> Both ways should work, but from an OO's point of view, I'd keep
everything in the Entity Beans.
Could it be argued that the separation of responsibility, with a facade
class, is more 'OO'?
Thanks, again,
Bill
-----Original Message-----
From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 5:06 PM
To: 'Bill Leonard'; EJB-INTEREST (E-mail)
Subject: RE: Entity and Session Facade Design Debate
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".
