Entity Bean Facade

An Entity Bean is used as a Distributed Facade.It becomes coarse-grained.

Application: Suppose the case of an Employee. An Employee can have multiple addresses. In this case, I have an Entity Bean for Addresses(suppose Address Bean). For Employee, I have Employee Bean. Now Address Home is a member variable of Employee Bean. Thus Employee Bean actually contains the container of Addresses. In the get Addresses method of Employee Bean, I would call the finder method on Address Home, to find addresses for the Employee.

Benefits: So an Entity Bean becomes coarse grained, and design maps to the world reality(An Employee has multiple addresses) By, Pol parikshitpol@usa.net

Comments

1.I don't see this as an EntityBeanFacade, but as a case of a one-to-many relation (one employee and many addresses). If so, why should I have to use home interface? Why can't I directly use the remote interface inside the Employee Bean?

Example:

interface Address implements EJBObject{

}

class EmployeeBean implements EntityBean{

Address address;

}

This can be done under InpriseAppServer and has some performance hit over using the Home interface (refer Inprise docs).

2.The other example I can think of using an EntityBeanFacade (which I can also do using StatefulSessionBeanWrapsStatelessSessionFacades). Is SearchResultAsEntityBean.

-- SeshKumar

Since the cardinality is one to many, I believe the EmployeeBean class should be defined as:

class EmployeeBean implements EntityBean{

Collection addresses;

}

You'll need a special Collection implementation, however, that checks member identity for equals/indexOf/etc using EJBObject.isIdentical(), rather than EJBObject.equals().

I HaveThisPattern but am dissatisfied with it. Maintaining a collection of EJBObject references, as opposed to finding them each time through the Home, results in faster retrieval but at the cost of decreased elegance. The "facaded" objects are now essentially private to the library, but its create and remove methods are public. The EJB spec doesn't let you remote non-public methods, probably because the container needs absolute access. Sure, javadoc can warn users not to use certain areas of a library, but this doesn't sit right with me.

I see two ways of managing the EJBObject references in this example:

1) EmployeeBean.addAddress calls AddressHome.create and addresses.add. EmployeeBean.removeAddress calls AddressHome.remove and addresses.remove. Employee.addAddress and Employee.removeAddress are usable to clients. AddressHome.create and AddressHome.remove are private to the API.

2) EmployeeBean.addAddress calls addresses.add. EmployeeBean.removeAddress calls addresses.remove. AddressHome.create calls Employee.addAddress and AddressHome.remove calls Employee.removeAddress. Employee.addAddress and Employee.removeAddress are private to the API. AddressHome.create and AddressHome.remove are now usable to clients.

I prefer the second way because it is more consistent with EJB semantics to use a bean's home for creates and removes. Why would you create/remove an Employee through EmployeeHome, but not create/remove an Address through it's AddressHome. This is potentially more confusing for API users than having add/removes on the facade that are private.

-- MarkSawers

Does this pattern really result in coarser-grained components? It seems that, at least with this example, it's adding accessors without reducing the number of remoted objects. Employee.getAddresses() returns a collection of Addresses, which are EJBObjects. Address will certainly have business methods to get it's primary key value and attribute values. So if a client needs to display an employee's addresses, it would call Employee.getAddresses(), iterate through each Addresss, calling it's getStringRepresentation() or some remote method. That is 1 + number of addresses remote calls. How is that different than calling AddressHome.findByEmployeeId() and iterating through it's result? Isn't the intent of coarseness to decrease inter-process traffic? Wouldn't converting the Address domain object into a DataTransferObject or a DomainObjectStateHolder achieve this intent? -- MarkSawers