all inline // my ICQ UIN is 91653297
> -----Original Message-----
> From: Bill Leonard [mailto:[EMAIL PROTECTED]]
> Sent: Mi�rcoles, 05 de Septiembre de 2001 18:22
> To: [EMAIL PROTECTED]
> Subject: Re: Entity and Session Facade Design Debate
>
>
> 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).
Whoa. Distributed access or distributed solution? How does the client
connect?
Does it interact with a web service or directly with the app server using
RMI?
> If I now wanted automatic
> transaction management, I would have to provide it on the session bean
> method, right?
no.
SB* is a SLSB with a contained instance of NetworkElement (which, if I read
correctly, is
your persistence manager)
C ---> SB* --> NetworkElement --> DataSource.
or
C ---> EB --> NetworkElement --> DataSource.
with CMT, transaction enrollment is automatic (specially if your app server
is a pure java imp, such as Orion or JBoss). Usually, transactional context
is maintained by thread affinity, so, this is possible and does not hamper
CMT:
C ---> EJB ---> Class ---> DataSource.
Class participates in the TX by throwing (or not) Exceptions to abort it.
> 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).
Yes, specially if you're using Session Beans. Entity Beans aren't VO's.
They're
fully blown, BL carrying, business objects(note word objects). I'd still use
a Session Bean
in front of them for two reasons:
1. Limit the number of TX's fired by non transactional clients
(JSP,Servlets, Applets/Applications).
2. Execute inter-entity BL-- Managing relationships, etc.
> Of course,
> I could just do the trans mgmt manually but ... I want to use
> tools and
> automate my tasks.
And who doesn't? ;-)
Yes, IMHO, delegating all tasks in the infrastructure (namely, the App
Server) is the way to go.
Of course, you may have to go around it sometimes, but first I try to make
someone else responsible
for all the plumbing(or else, sooner or later, my projects finally turn to
be a rewrite of the app server).
> 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)
getter/setters is what I use; I also embed operations in the entity beans,
as long as they aren't inter-entity(what I mean by inter-entity is that they
don't involve other bean classes, but may involve other 'instances' of the
same class)
> but I
> don't know how much of a need there is for this.
Well, unless the problem you're solving with this app is extremely clear,
getter/setters (and some methods with more complexity) give you enough
flexibility to change in the middle of development.
>
>
> >> 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'?
Nop. Separation of state and behavior favors performance and efficiency, not
an OO design. What happens if a field in your entities(I mean the ones in
the solution domain) turns out to be obsolete, and needs to be replaced
with, say, two fields. In one approach(EBs), you may not need to change a
lot of code (and with some luck, you won't be needing to break the
interfaces). On the other approach(SBs), a lot of rewritting/regenerating
code would be needed.
This is an interesting issue, It's been long since I got into some like this
on the list.
There are tradeoffs in both approachs and the only guys that can work it out
are you, because you
know the solution domain (in contrast with yours truly). Either way may
work, some may perform more than the other, but in the end, it's a matter of
taste. I taste EB's, but use SB's all the time (specially to limit the
number of TX's that are generated).
Just my 2c,
Juan Pablo.
>
> 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".
>
>
> ______________________________________________________________
> ______________
> 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".
