Dave Glasser wrote:
> Assuming that concurrent access is not a major factor, can someone
> explain to me what the benefits of using entity beans are, as opposed
> to a basic object->relational mapping?
One of the benefits that entity beans offer is composable transactions. In
other words, entity beans allows you not only to put a component model around
data, it also allows you to build new transactions from existing components.
For example, practically every project that I'm familiar with has an entity
bean that maps to the concept of a customer. Every time the Customer entity is
used in a new scenario it's automatically enrolled in the transaction. This
ensures that changes to Customer are only committed if all the other work
succeeds in that scenario. This is accomplished automatically by the container;
the application developer doesn't need to mess with transactional demarcation,
resource enlistment, synchronization, etc. As each entity is added to the
scenario the transaction automatically expands to include them. That's a
powerful concept.
However, this can also be accomplished with session beans, so the question is:
Why use Entity beans over session beans to model persistent business objects?
Well, concurrent access is certainly the most obvious reason. If many clients
need to access the same entity, the container will ensure some level of
concurrency. I say "some level", because different containers provide
concurrent access using different models. One model keeps entity beans in a
cache (not a pool) and only allows one client to invoke methods on a specific
entity at a time. These systems manage concurrency at the server, not the
database, and supposedly provide a big performance advantage because the cache
is in-memory, so database reads are not required (writes are however).
Obviously this can not be duplicated by session beans which use JDBC or some
other data access technology to work directly against the database. The other
model may provide less of a benefit over session beans in terms of
performance. This model places the responsibility of transaction isolation
(effectively concurrency) on the database. Every time a client requests access
to a particular entity bean, it's given access to its own copy of the data
(entity instance) instead of standing in line to access the same cached copy.
This may provide better scalability because clients are not queuing for access,
but it also requires frequent database hits which may offset that advantage.
The caching system of most relational databases, however, is very advanced. If
the container and database are on the same machine, the database cache will
provide many of the same benefits as the server cache discussed in the first
model. The point of this whole paragraph is that concurrent benefits may not
be all they are cracked up to be and in some cases a stateless session bean
using JDBC will be just as fast using an entity bean.
So now that advantages of composablity and concurrency in entity bean are in
question, what's left? To understand the inherent benefits of entity beans we
have focus on the concept of identity.
Lets say we decide to use stateless session beans to model persistent business
concepts instead of entity beans. (Statefull beans would require too much
overhead). When you use a stateless session bean to model the concept of a
Customer or some other entity bean you must explicitly pass the identity you
wish the stateless session to manifest with every invocation. This is because
the stateless session bean is, well, stateless. It can't remember who it's
supposed to be. Below is an example of client code that uses stateless beans
as entities.
StatelessCustomer customer = ... get the remote reference (EJB object)
Integer primKey = ... get the unique identifier for a specific customer
String name = customer.getName(primKey);
Address address = customer.getAddress(primKey);
customer.setLastName("Monson-Haefel", primKey);
While the above is pretty ugly in my opinion, its not totally untenable. But
suppose you have to manage the interaction of a large population of entities.
Eventually you'll discover that you have exhausted an awful lot of development
time managing the keys and ensuring that the right ones are used with the right
sessions. In fact, you'll find yourself putting more and more information into
the keys so that they are easier to identify and manage. Then one day, you'll
think, why don't I make a smart key that wrappers a reference to a stateless
session bean and acts as the remote proxy to the bean? So you do exactly that
hiding the stateless session inside the key. The key implements the remote
interface and simply delegates calls to the stateless session, passing itself
as the key.
public class SmartKey implements Customer, Serializable {
// EJB object reference
private Customer customer;
// prim key value
Integer mykey;
public SmartKey( ){
// code to obtrain reference to Customer
}
public String getName( ) throws RemoteException {
return customer.getName(mykey);
}
...
}
This smart key avoids the need for the client to explicitly pass the primary
key every time it invokes a stateless bean method. Your client code looks as
follows:
CustomerKey customer = .. get the customer primary key with an embedded
stateless session bean
String name = customer.getName( )
Address address = customer.getAddress()
customer.setLastName("Monson-Haefel");
Doesn't the above code look much better? Of course we had to build an entire
infrastructure of smart keys which implement the remote interface, maintain
their own identity (primary key), lookup the proper stateless session, and
delegate requests to the stateless session bean. Hmmm .... this all looks very
familiar. Don't entity beans accomplish basically the same thing? They
maintain an assocation between a remote reference used by the client and a
primary key. Of course they do it automatically on the sever and hide the
details from the developer. If we had just used entity beans in the first
place, we would have obtained exactly the same benefits with at least the same
performance if not better.
The last comment about performance should be raising your eye brows. The truth
is, however, that entity beans can out perform stateless session beans if the
first model is used where the beans are cached. In addition, you will
sometimes discover that vendors who use the second model will have entity
containers that perform just as well as a stateless session containers.
Speaking as someone who has built an EJB container system (OpenEJB) I can tell
you from experience that entity beans may require no more overhead then
stateless session beans when it comes to accessing the database. Don't get the
wrong idea, however: Stateless session beans are very important and when used
in the right context can be more performant then entity beans. Its important
however to dispel the myth that entity beans are always going to be slower and
require more resources then stateless session beans. Its simply not true in all
cases. Its especially not true when you pit them against each other modeling
"entity" business objects.
The main point is this: Entity beans allow you to keep a set of specific
database records associated with a component. Entity beans have implicit
identity. This eliminates the necessity of inventing (re-inventing)
architectures for managing the associations of identities with references. In
addition, the entity component is not just a data wrapper, its can include
business logic and access resources and do all sorts of things while being
completely reusable within an organization. With an entity bean you get a
complete package of data and business logic.
The benefits of entity beans, however, are dramatically increased with the new
container managed persistence model in EJB 2.0. It completely and totally
hides the overhead of managing identities with regard to relationships between
persistent business objects. In fact, the new CMP in EJB 2.0 is so much more
powerful then the current CMP that it will completely whip out any arguments
about using stateless beans instead entity beans to model persistent business
objects. That's a whole different thread that I will avoid.
> One of the most hyped features about entity beans has been CMP, but
> unless we're missing something, that seems to be a joke, not nearly
> sophisticated enough to meet our needs. And even if it did, all it
> would save us is time and effort, and that's not one of our overriding
> goals in building this system, it's performance, stability,
> scalability, etc. As it happens anyway, we already have a homegrown
> code generator that, given a DB table's metadata, will generate a
> matching data object class, a class to do all of the basic CRUD
> chores, and a session bean (with the attendant interfaces) for
> accessing it, so CMP would not even save us a great deal of work.
Your right about CMP in EJB 1.1: Its pretty crude, but products like TopLink
and CocoBase can offset its limitations. Not that these products are perfect,
but I'm betting they'll make you more productive then writing an entire O-R
mapping framework from scratch.
> Another thing that had us scratching our heads was, a great deal of
> the literature pertaining to entity beans is about ways you can work
> around their excessive overhead, like network chattiness, excessive
> hits on the database, scalability issues, etc., and some of these
> workarounds, e.g. Monson-Haefel's "bulk accessor" methods just seemed
> clumsy and awkward. If there are so many pitfalls and gotchas
> associated with entity beans, why on earth does anyone use them?
You right again. Things like bulk accessors and data objects are clumsy and
awkward, but this is not a reflection on entity beans. You'll still need to
use these things if you model your system with stateless session beans. These
types of techniques have been used for as long as there has been remote objects
-- as a former CORBA developer I can tell you that they are nothing new. The
fact is you are working on a network and so you must program for the network.
> I hope no one misinterprets this post as an anti-Java or anti-EJB
> troll. Believe me, I love just about everything else about Java and
> J2EE. In fact, I would be happy if someone who has some actual
> experience with entity beans could enlighten me if there is some great
> payoff in using them that I've missed.
I get asked this same question frequently, and I think its a valid and
intelligent question. I hope that I have provided a decent explanation of the
advantages of using entity beans.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.EjbNow.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".
