Session Bean Wraps Entity Beans

(This may be part of the recovery effort from the WikiMindWipe.)

Here's the basic idea -- EntityBeans as described in the EJB specification represent individual "entities" (e.g. objects) that each form a part of the data of your application. To perform a useful function, you will often need to combine several entities together. For instance, when creating a Customer, you will often want to create an Address.

So here are some problems with directly doing this from client code:

1. This exposes the details of both entity beans to the client. This increases the DistributionCrossSection of your application as a whole, and also means that each access to the beans to accomplish this feat (e.g. EmployeeHome.create(key), employee.setName(), AddressHome.create(key), address.setZip()...) is a remote access -- one that crosses the network.

2. You really want all of this work to happen within the same transaction. However, it's not really recommended that you manage transactions from the client side. That can get messy, and it encourages long transactions, which are usually not a good idea.

So the solution that most people come up with is to instead handle all of the access to the EntityBeans within a wrapping SessionBean. The Session bean has a single API that creates a customer from the individual data elements and which also does it all within the context of a single transaction. -- KyleBrown

---

In the example given, why would you not simply create a customer entity bean which is populated from different tables? (Assuming you want addresses in a separate table.)

I fail to see the rational behind creating Addresses as separate entity beans with the associated key requirements and entity bean overhead.

This is not a criticism of the pattern being suggested, rather a problem with the example. I have not thought enough about wrapping EntityBeans in session beans to make a fair comment on whether the pattern is actually a pattern. -- MichaelRichmond

---

This is because as of EJB1.1, EntityBeans can map to only one table, not to multiple tables. -- Mohit

---

As far as I can remember, the EJB1.1 spec, or 2.0 for that matter, does not set any limits on the number of tables you can map to. It only requires that the persistence mechanism implemented by the container has Serialization semantics; all else is vendor specific. -- NickOutram

---

Relational table mapping is not the major issue of that pattern. The basic idea is that you can use it to migrate (slow) client-initiated transactions to faster server-initiated transactions whenever several entities need to interoperate. Moreover, you can use the same SessionBean to enable clientèle processing, provided you store some additional information in the session instance. But maybe that's another Pattern... -- ChristophPohl