Entity Beans Are Evil

While I agree that EntityBeans can be used for evil, I do not believe they are inherently evil. Stateless session beans are fine where state is managed outside of the application server and everything that entity beans/stateful session beans do can be done with stateless session beans backed by a datastore. However, this is a very services oriented approach (as opposed to an object oriented approach). In fact, stateless session beans are a great deal more like C functions than they are objects.

I'd say that the main advantage of entity beans is that they provide a pattern for providing more specific services, where the service is usually requested in the context of an object. Good examples here are where the entity bean is mapped onto a real life object, e.g. a printer. A printer has state, that state is persistent and there should be shared, transactional access to the printer. In this case I don't believe a session bean would not be that useful (ps. yeah, I know that jini would probably be better fit for a printer specifically).

I do not believe that Entity Beans are an appropriate choice for just representing rows in a datastore. In this case I would propose instead of EntityBeansAreEvil, JDOIsGood.

If session beans represent actions and entity beans represent data, then do all you people who hate entity beans have no data?

That's not what RandyStafford and the other EntityBean skeptics are saying at all. They're saying that EntityBeans aren't the best (or even a good) way to represent data, not that they don't have data. The problem is that EntityBeans (at least prior to EJB 2.0, final spec 2) are big, heavyweight distributed objects that are often much better replaced by small, lightweight local objects.

In general, I agree with the title. There is one usage, SearchResultAsEntityBean, where we've found them to be useful (although I doubt the EJB spec writers intended that usage).

I think the following exchange from EJB-INTEREST circa 8/24/200 is germane to this page:

Tim Fox wrote:

RandyStafford wrote:

 > > I'm interested in EJB but I've yet to be convinced that EJB *per se* can
 > > actually add anything to our setup.
 > >
 > > Its seems to me that EJB simply would add distributed transactions (which
 > > we
 > > wouldn't use) and give us RMI interfaces to our business objects (which we
 > > wouldn't need).
 > >
 > > Is this is a fair summary of the capabilities of EJB or am I missing
 > > something
 > > (and I guess I am ;-) ) ...
 > >
 >         [Randy Stafford]  No, it's fair.  I'm with all that. Personally, I
 > don't have much use for entity beans.

Ok, so are you recommending pure "service based objects" rather than storing state and having to synchronize? - isn't this though the model I am currently using (instantiating the business objects on every request, and no in memory caching). It seems to me that stateful models + load balancing just don't go together. This seems to be the way a lot of architects are going (including Micros*** with MTS!)

[Randy Stafford] No, I'm not recommending "service based objects", which I'm interpreting as objects without intrinsic identity or instance variables that load/store their state every business method. I saw how MTS does that, passing an oid into every method, and I was disgusted - it basically reduces OOPLs to a fancy way or organizing subroutine libraries. Entity beans are a little better in that they appear to have intrinsic identity and permanent instance variable values, even if tricks are done behind the scenes to maintain that illusion (e.g., load/store, instance swapping, etc.). But IMHO entity beans are the current embodiment of some questionable ideas (that business objects should be remotable and responsible for their own persistence) that have been around for a long time - the idea of entity beans actually has a long heritage within IBM (read RogerSessions' book ObjectPersistence sometime), and Sun people acknowledge this heritage. Plain old java objects and OODBMSes facilitate a much more elegant implementation of a domain model.

And you're right, there is a fundamental tension between load-balancing over multiple VMs (each of which can have its own instantiation of a persistent business object), and caching the state of that business object in-memory. GemStone's architecture was designed to resolve this tension 15 years ago, and currently does so in a scalable, performant manner.

> I prefer to implement my business > objects as plain old Java objects that are never exposed remotely - and > there are other, less-expensive-than-entity-beans ways of sync'ing in-memory > state with persistent state, especially with GemStone, but also with > RDBMSes.

I'm interested to know how would you sync state using an RDBMS? Would this be some kind of trigger that calls back into the containers and tells the objects to reload?

[Randy Stafford] Ah. There are two parts to the problem here. If the in-memory state of an object changes during a use case, it is pretty easy to flush the in-memory state to an RDBMS without requiring entity beans - it is easy to write a framework to do so, assuming you apply the patterns of service-based architecture (by which I mean a layered architecture featuring a "services" layer between the application and domain layers), short transactions, and service-controlled transactions. The other part of the problem is the scenario where the RDBMS can change out from under the cache as a result of some other application updating the RDBMS. If this scenario exists, it represents a harder problem that must be designed for. You have to know when to invalidate your cache. In general the only mechanisms available are polling or trigger-based callouts, but the problem has more to do with semantics than mechanisms. You have more potential concurrency conflict, which you have to detect and deal with at the application level. The easy way out is to not cache, which probably hurts performance otherwise why would you cache, and you still probably have to detect concurrency conflicts at the application level before writing the RDBMS. Note that this whole set of issues is recognized, in that some EJB containers contain an optimization where they'll skip some ejbLoad invocations if you tell them that they "own" the underlying database.

-- RandyStafford

Have you checked out generative solutions like TSpaces or JavaSpaces. As long as state is atomic to the remove object, I see no reason why this should inhibit load-balancing or dynamic fail-over.

A service-based architecture would be always desirable, but hard to achieve if you can't avoid working with the domain objects at the client level of the service layer, which might be the common situation.

The fundamental problem seems to be HowToShareStateAmongMultipleComputers.

Interestingly Microsoft nearly introduced a cache of it's own InMemoryDataBase? IMDB in COM+. They dropped it at the 11th hour.

Gee, I think your hand waving about how you would do it without EJBs you just reinvented entity beans all except in name.

Oh BS. Plain old java DomainObject(s) are not remotable and not responsible for their own persistence - those are two major differences between the non-EB approach and the EB approach. It's not hand-waving, either - go download a copy of FoodSmart and look at the source code. -- RandyStafford

Randy, points on persistence taken. Can you explain your objection/alternative to remotable business objects? Thanks! -- BrianEwins

DeleteMe? The following seems ripe for removal:

EntityBeans are available in Sun's EJB, but Microsoft avoids the whole issue. Why? Are EntityBeans useful or not?

They are not evil, merely misguided...

CategoryEvil