Entity Beans As Domain Objects

Contrast with EntityBeansAsDataGateways.

EnterpriseJavaBeans Entity Objects can be used as your business objects in the domain layer of a FourLayerArchitecture.

The main point of doing this is that is that you can then use ContainerManagedPersistence to avoid all the persistence issues. You update the bean to change data, and the container figures out how to keep the database up to date.

Another advantage is that the entity bean can be moved and put on another server. But that may not be an advantage. Domain Objects tend to be fine-grained. FineGrainedDistributedObjects are a bad idea because they lead to a very chatty application which runs like a tortoise in treacle and is unreliable as well. As such, we prefer FacadesAsDistributedComponents. But FacadesAsDistributedComponents does not fit so well with EntityBeansAsDomainObjects.

Entity beans have some maturity issues. The version 1.0 EJB spec didn't make it clear whether you can inherit from an EJB, or whether a method on an EJB can return another EJB. These were cleared up in EJB 1.1, but not all products are there yet.

References between EJBs are done with IDs. Although you can (and should) hide this in the interface, it doesn't feel like objects, and that makes an old ObjectBigot feel pretty uncomfortable. There are also performance implications. Since EJBs are expected to be remote, the lookup can take time as various issues are dealt with (such as security checking) which aren't actually needed when you know objects are in the same process.

IbmSanFrancisco essentially uses this approach. Currently they have Entity Objects which work very much like Entity Beans (indeed they influenced the EJB specification.) They have additional features that mitigate some of the disadvantages of this approach.

References between EJBs are done with IDs. Could you elaborate on this, please?

OK, this refers explicitly to the EJB 1.0 spec -- things are slightly different in the EJB 1.1 spec.

An EJB can contain attributes that are either primitives or serializable objects and can implement methods as part of its remote interface. However, most current EJB Servers (WebSphere, WebLogic, etc.) do not allow an Entity EJB to CONTAIN another Entity EJB as an attribute. This was because this was disallowed (well, it was vague) in the EJB 1.0 spec.

As a result, when you wanted to represent a "relationship" from one entity bean to another in EJB 1.0 what you had to do was store some "foreign key" to the referred object in the referring object. Since you could store a Serialized object as an attribute, you could choose to store an entire EntityKey. However, when I did this, I would normally just store the key field of the other entity (like a String) and then reconstruct the EntityKey on the fly.

This changes in EJB 1.1. In EJB 1.1, a container-managed field can explicitly contain a reference to another Entity bean. When the application servers and tools catch up to the spec, things will be much simpler.

-- KyleBrown

Thank you

You can see a more detailed example of doing this in a series of articles that I've written in the VisualAgeDevelopersDomain. Take a look at:

http://www7.software.ibm.com/vad.nsf/data/document2616?openDocument&p=1&BCT=1&Footer=1

and

http://www7.software.ibm.com/vad.nsf/Data/Document2310?openDocument&p=1&BCT=1&Footer=1

-- KyleBrown

Sorry, I don't find Entity Beans are the ultimate solution. An approach with dramatically less effort is to be found at http://www.must.de/Jacompe.htm.

-- Christoph

I am wondering if anyone experimented with local interfaces from CMP and CMR from EJB 2.0. I can get CMP and CMR working with Weblogic 6.1, but I find myself dealing with EJBs and database tables, instead of deadling of domain objects. Is there a mapping between domain objects and EJBs, especially local ejb objects?

I do not see EJB 2.0 CMP/CMR entity beans so far from domain objects. Most of the arguments above apply until EJB 1.1 but not when EJB 2.0 comes into play.

I model domain objects in UML using a CASE tool and subsequently generate the EJBs using UML2EJB (see http://uml2ejb.sourceforge.net). The mapping between domain objects and EJBs is partly in my head, partly in the templates that drive the generator. The current template set uses entity beans with local interfaces and session beans as facades with remote interfaces. Works quite nicely and does not distract my thoughts too far astray from the problem domain.

Thoughts? -- MatthiasBohlen

I'm now of two minds with this. When you do an Entity Bean with a Local Interface ONLY then I can make a pretty good argument that it really and truly is a DomainObject, expecially with EJB 2.0 CMR. With Remote Interfaces it's a tougher sell -- the very fact they were remote, shared objects meant to me that you didn't want lots of them around -- thus leading me to put domain logic somewhere other than the EntityBean itself so you would only have one shared Entity Bean type per table, and multiple domainish objects operating on the data from them. However, in a purely local case, I don't mind putting domain logic in the EntityBean -- especially since it's not too heavy weight to have multiple EntityBean types for essentially the same database tables. So, my thinking has come around a bit such that I'm now willing to consider EntityBeansAsDomainObjects with these caveats.

-- Kyle

Would that "pretty good argument" include a solution to the challenge in EjbTernaryRelationshipExample?

CategoryEjb, CategoryAntiPattern