I want to thank everyone for their well-thought-out responses to my
question about entity beans, particularly Richard, who basically
banged out a magazine article on the subject within a few hours of my
original post.
I think I should clarify that the architecture we've decided upon does
not use session beans to model business concepts, We're using simple
data objects, with fields, setters and getters, much like entity
beans, except that these objects are serialized and sent to the
client. We use optimistic locking based on a timestamp and num_updates
field to keep users' updates from conflicting with each other. The
client can manipulate a data object to its heart's content, then pass
it back to a someSessionBean.update(someDataObject) method to save the
changes to the database. This strikes me as a much more scalable
solution; there's virtually no client data being kept in the EJB
container, and little if any conversational state. The main function
of the container is to provide services like DB connection pooling,
transaction management, and some security services. There's a data
access layer where the tables are mapped to data object classes, and
where all of the DB I/O occurs, and these methods (all static) are
called by session beans which are in turn called by the clients.
For our current project, the "clients" are going to be servlet
containers, but they could just as easily be Swing apps or applets.
When you have a GUI client, it makes even more sense, IMO, to have the
data objects on the client instead of a remote server. If, for a
JTable, you had a TableModel that made a remote call for each table
cell it had to paint on the screen, you can imagine how much network
traffic it could generate.
There are still instances I can think of though where entity beans
might provide some benefit, like where, as an order moves through a
system, multiple people must be able to access and modify it
concurrently, to the point where a simple optimistic locking scheme
would result in an unacceptably high number of failed updates.
On Thu, 18 Jan 2001 05:37:00 -0600, Richard Monson-Haefel
<[EMAIL PROTECTED]> wrote:
>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
===========================================================================
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".
