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.getNumberOfCard
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".
