Discussion groups have recently been abuzz with talk of "coarse-grained entity beans" - a slight misnomer deriving, I suspect, from the addition of mandatory entity beans in EJB 1.1. This month I'll examine the finer points of the Enterprise JavaBeans specification regarding coarse-grained entities, as well as my own, and provide an example for you - with plenty of comments to provide food for thought when you tackle the challenge yourself.
For those of you who finally came out of your Y2K shelter, EJB is a specification for building server-side business components on the Java platform. Its initial release required only enterprise beans called session beans, which are a logical extension of a client's business process. The specification mentioned entity beans, which represent persistent business components, but didn't mark them as mandatory for EJB 1.0 compliance.
However, industry demand for details about entity beans forced Sun and its partners to include them in the EJB 1.1 release. The updated specification provides some structure around entity bean development, but it created a whole new set of questions about EJB design patterns. The main EJB design pattern I'll cover this month revolves around coarse-grained entity beans and dependent objects.
Granularity of a Bean
I was recently on "The Hill," near the campus of the University of Colorado at Boulder, and noticed that the sidewalk had numerous quotes from philosophers and great thinkers - they must be there to provide inspiration to students who look at their feet when they walk or something! I'm going to start off with a few quotes myself, by way of helping to describe the granularity of an entity bean.
Section 9.1.2 of the EJB specification 1.1 reads: "In general, an entity bean should represent an independent business object that has independent identity and lifecycle, and is referenced by multiple enterprise beans and/or clients. A dependent object should not be implemented as an entity bean. Instead, a dependent object is better implemented as a Java class...and included as part of the entity bean on which it depends."
Great, but now you're asking what in the heck "dependent objects" are. Richard Monson-Haefel sums up the notion of dependent objects well in this quote from his book Enterprise JavaBeans (O'Reilly and Associates, 1999): "Dependent objects are objects that only have meaning within the context of another business object. They typically represent fairly fine-grained business concepts, like an address, phone number or order item. For example, an address has little meaning when it is not associated with a business object like Person or Organization. It depends on the context of the business object to give it meaning. Such an object can be thought of as a wrapper for related data. The fields that make up an address (street, city, state, and zip) should be packaged together in a single object called Address. In turn, the Address object is usually an attribute or property of another business object; in EJB, we would typically see an Address or some other dependent object as a property of an entity bean."
