These characteristics need to be evaluated in the context of the EJB framework and the design options that framework presents. We should also rely on the experience of others in building robust J2EE applications - after all, that's what design patterns are all about. Let's take a look at some key design aspects and see what Core J2EE Patterns has to say about them.

Entity Bean Design - the Composite Entity Pattern
One of the early decisions we need to make when applying our pattern to EJB technology is which classes should be implemented as entity beans. The Composite Entity pattern states "entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects." Applying this principle to our high-level design for CachedBalanceSet, we see that most classes within this design are best left as simple Java classes; in other words, they are dependent objects. Should the CachedBalanceSet class itself be implemented as an entity bean? Given the previously listed characteristics (specifically that the CachedBalanceSet method implementations are self-contained), we can make a reasonable case for implementing CachedBalanceSet as an entity bean. However, we also need to consider what its relationship to the Product class should be and how its methods interact with broader business processes, as these points may very well cause us to revisit our initial decision.

The Product class is a natural candidate for entity bean implementation. It represents a business entity with considerable information and functional behavior, and it presents us with a natural primary key - the product ID. If we implement the Product class as an entity bean, what effect does that have on our CachedBalanceSet class? Much depends upon the behavior we choose to expose on Product's interface. If we choose to treat the Product class primarily as a data holder, maintaining information such as product name, description, ID, and the like, without incorporating additional business process-related behavior (like product balance updating and retrieval), then we maintain a loose coupling between the Product class and the CachedBalanceSet class (see Figure 3). This lends credence to our tentative decision to implement the CachedBalanceSet class as an entity bean in its own right, but raises the question as to where to contain the business process- related behavior that manages product balances.

Another aspect of the EJB architecture that we need to take into account is our ability to choose whether an entity bean is defined as local. Local entity beans reduce overhead associated with remote calls but at the expense of limiting access to the entity object to the local process. At this point in our design process we don't have clear guidance based on the Composite Entity pattern, but as we continue to expand our design toward components and Web services, we will see that local entity beans are the best choice for our design.

If, on the other hand, we choose to embed product balance maintenance within the Product class, we see that we have introduced tight coupling between the Product class and the CachedBalanceSet class. Such tight coupling might cause us to reconsider our earlier decision to make the CachedBalanceSet class an entity bean, instead choosing to implement the CachedBalanceSet class as a dependent Java class within the Product class implementation (see Figure 4). However, this raises another question - how much overhead does introducing these dependent classes introduce to EJB activation and passivation? If our typical use of the Product class does not involve balance management, we might be better off separating the CachedBalanceSet class from the Product class as we originally proposed. If, on the other hand, most uses of the Product class involve balance management, then embedding the product balance management code as dependent objects within the Product class is probably the right decision. If we choose this option, we may be able to mitigate the EJB activation and passivation overhead through a bean-managed persistence (BMP) approach, deferring activation of the dependent CachedBalanceSet object within the Product EJB until it is needed. In fact, this is likely to be the choice we will make for CachedBalanceSets even if we choose to implement it as a separate entity bean, given that the internal intricacy of its contained objects, in this case as it is in general, involves a series of tradeoffs.

Session Bean Design - the Session Facade Pattern
Let's assume that we have chosen the decoupled approach as described above, resulting in two entity beans: Product and CachedBalanceSet. Where does the business logic responsible for maintaining product balances then reside?

Again, Core J2EE Patterns gives us a strong hint. Reading from the Session Facade pattern, we see that a session bean "...manages the business objects and provides a uniform coarse-grained service access layer to clients." There are two important points being made here, one of which is directly applicable to our specific problem - session beans should be designed to manage underlying business objects. (We'll consider the second point when we discuss the relationship of Web services to components.) By introducing a WarehouseManagement session bean following the Session Facade pattern, we now have a natural place to locate our product balance maintenance implementation (along with many other business process-related algorithms that span products, warehouses, and other related business concepts such as lead and shipping time calculations (see Figure 5). By doing so, we have in fact created a coarse-grained component - one that presents a series of business services to clients without exposing those clients to the underlying complexity inherent in the implementation of those services. This approach also reinforces our earlier decision to separate product balance maintenance logic from the Product entity bean and maintain loose coupling between the Product and CachedBalanceSet classes.

Now that we've introduced a session bean into our design, we need to consider whether this bean should be stateful or stateless. In general, Core J2EE Patterns recommends stateless session beans, as this allows the application server to more efficiently manage its memory pool by allocating beans out of a bean cache on a method-by-method basis. If, however, there is a need to maintain client session state outside of the client itself, then a stateful session bean approach may be warranted. In our case, we will assume that the stateless session bean approach is appropriate.

Other design patterns may come into play as we drop down into the detailed design of our WarehouseManagement session bean. For example, we might choose to implement each of the methods our session bean exposes using the Strategy pattern, thus making our session bean highly configurable. Individual strategy implementations might in turn use the TemplateMethod pattern to provide a partially built algorithm that can be customized on a point-by-point basis. These are just a couple of examples of how design patterns can influence detailed design decisions.

Bringing Web Services into the Picture
Server-Side Considerations - the Transfer Object Pattern
Now that we have our coarse-grained business services defined, we need to adapt them to the needs of potential clients. One type of client that is of considerable interest these days is remote invocation via a Web service. Web service- based invocation involves transmission of a client request to a remote service via an XML message whose format is specified by SOAP, typically transmitted over Internet protocols such as TCP/IP and HTTP. Introduction of this XML-based invocation into the picture adds some additional design restrictions above and beyond those created by the base J2EE architecture.

Specifically, because our client communicates with our service via XML documents rather than remote objects (as would be the case in an n-tier J2EE implementation with JSPs and servlets invoking session bean methods through their remote interfaces via RMI), we need to ensure that the interface presented by our server component is easily consumable by the SOAP client and does not introduce a lot of overhead at the component (i.e., session bean) interface.

The Transfer Object pattern provides us with an approach for consolidating the business information to be communicated between client and server. This pattern encourages the use of simple Java classes to encapsulate business data exposed on the public interface of a coarse-grained component. These simple data-oriented Java classes can then be easily processed by the serializer/deserializer logic provided by SOAP development and runtime frameworks such as those following the JAX-RPC specification.

Client-Side Considerations - the Proxy and Business Delegate Patterns
Remote Web services clients typically interact with a service via object-oriented proxies that are often generated by specialized Web services development tools from the WSDL document describing the service. These simple proxy classes provide individual methods for each of the operations described by the WSDL document. Each method directly invokes the underlying service (in our case the coarse-grained component implemented by our WarehouseManagement session bean) via the SOAP-based framework provided by the Web services runtime.

In some cases, these directly generated client methods will be sufficient. There may be cases, however, in which it is desirable for the client to have an additional level of decoupling from the services it invokes. For example, we might choose to build up a cache of recently accessed product information to minimize remote activity and thus improve performance of our client, or we might want to build up a consolidated client view over multiple Web services. The Business Delegate pattern describes an approach that supports this level of isolation. Client activities occur solely through a client-side class, the Business Delegate, which in turn delegates any necessary remote invocations to the underlying business service (in this case our generated SOAP client). Because the Business Delegate class is interposed between the client code and the SOAP client, we have the freedom to introduce client-side caching for frequently accessed information, consolidated service groupings with embedded glue logic, or other useful features. The Business Delegate class can also serve as a stable interface point for the remainder of the client code, isolating any client-side changes that might result from changing server-side implementations to a single touch point.

Summary
Figure 6 shows our full set of patterns working in concert from client to server through a client request scenario. As you can see, by defining our pattern independently of the technical architecture, we were able to easily take advantage of a number of useful concepts:

Underneath it all reside our original business patterns, doing the heavy lifting of managing our product balances.

Resources