Reasons for EJB Objects

Reasons for EJB Objects

Why do we need this second layer of objects? Didn't we move to EJBs from CORBA and RMI to make things simpler? Why not just put all of the logic in your EJBs? There are several reasons for this. First and foremost, this is simply an application of layering. It is never a good idea to place too much behavior in a single object. If you layer the objects called by your EJBs in this way, you can gain the following benefits:

  • Placing the behavior in a set of objects one level in from the session makes it easier to test them in isolation, perhaps even outside of the context of a J2EE application server.

  • Multiple session façade objects can use the same inner-layer objects without fear of inappropriate transaction semantics and without the potential network and marshalling/unmarshalling overhead of cross-session bean calls.

  • A second layer of objects allows you to vary the implementation of those objects (by using the Strategy pattern from [Gamma]) in order to take advantage of particular features of an application server, while still allowing the entire design to remain portable across application servers. For instance, [Brown 2000a] describes some particular caching strategies for speeding up EJB performance that work under the WAS AE, but that would not work under the IBM CICS EJB support. By providing two implementations of the same Mapper or Action class, you can keep the overall design portable, while taking maximum advantage of the peculiarities of each server.

  • In cases where you do not need a JTA transaction context (e.g., you are working against a single data source) this pattern allows you to choose to deploy and build your applications either with or without EJBs. For instance, in some simple query cases it may be significantly more efficient to call a factory directly from a servlet in order to avoid the overhead of the EJB calls.

Also, we have found through review of several projects that reuse only rarely occurs at the session level. Each session will have a specific combination of transactional settings and method signatures for a specific application. Having a second layer of objects can instead result in reuse at the inner-layer level, where we have seen reuse in many projects, both within projects (across different session beans) and across projects in the enterprise.

We have seen that if you employ this design strategy then your designs can often use stateless session beans as your façade objects. Since each stateless session bean is not unique to a single user, this allows you to gain the additional scalability that stateless beans provide.

Now we can start to look at what kind of methods the façade will present to the outside world. We have seen that façade methods will usually fall into the following types:

  • Collectors— Collector methods often begin with get and return a single object or a collection of objects (represented as an enumeration in EJB 1.0 or a Java collection in EJB 1.1 and 2.0). The collector method will defer its implementation to a mapper object (possibly through the intermediary of a helper object).

  • Updaters— This method will locate and update an entity bean or a set of entity beans based on information held in value objects passed in as the arguments. The method name will often begins with update or set. An updater method's implementation can be either deferred to a mapper or enclosed a separate class.

  • Actions— An Action method (e.g., AccountBean.transfer(String fromAcctNum, String toAcctNum, BigDecimal amount)) will defer its implementation to an action object.

A last point to make about this template architecture involves why we have chosen to use mappers (or factories) to create our DTOs from our entity beans. A potential competing solution to the use of mappers is what [Monson-Haefel] describes as bulk accessors—methods on an entity bean that create and return value objects to represent the data in the entity bean. This is, in fact the solution employed by the CopyHelper access beans in WebSphere Studio. However, this has the unfortunate downside that it assumes that all requests will need all of the data in the EJB—resulting in returning unnecessary data to the user, and (in remote calls) incurring additional overhead for marshalling and unmarshalling the larger DTOs.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows