Sun Java Center J2EE Patterns

Print-friendly Version

Context

The system exposes the entire business service API to its clients, often across a network.

Problem

Presentation-tier components interact directly with business services. This direct interaction exposes the underlying implementation details of the business service API to the presentation tier. As a result, the presentation-tier components are vulnerable to changes in the implementation of the business services: when the implementation of the business services change, the exposed implementation code in the presentation tier must change too.

Additionally, there may be a detrimental impact on network-performance because presentation-tier components that use the business service API make too many invocations over the network. This happens when presentation-tier components use the underlying API directly with no client-side caching mechanism or aggregating service.

Lastly, exposing the service APIs directly to the client forces the client to deal with the networking issues associated with the distributed nature of EJB^TM technology.

Forces

• Presentation-tier clients need access to business services.
• Device clients (including rich clients) need access to the business service.
• Business service API may change as business requirements evolve.
• Goal should be to minimize coupling between presentation-tier clients and the business service API, thus hiding the underlying implementation details of the service, such as lookup and access.
• Desirable to implement caching mechanism for business service information.
• Desirable to reduce network traffic between client and business services.
• Business Delegate may be seen as adding an unnecessary layer between the client and the service thus introducing added complexity and decreasing flexibility.

Solution

Use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.

The Business Delegate acts as a client-side business abstraction; it provides an abstraction for, and thus hides the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services. Depending on the implementation strategy, the Business Delegate may shield clients, from possible volatility in the implementation of the business service API. Potentially, this reduces the number of changes that must be made to the presentation-tier client code when the business service API or its underlying implementation changes. However, the Business Delegate may still require modification if the underlying business service API changes.

Often, developers are skeptical when a design goal such as abstracting the business layer causes additional upfront work in return for future gains. However, using this pattern or its strategies results in only a small amount of additional up front work and provides considerable benefits. The main benefit is hiding the details of the underlying service. For example, the client can become transparent to naming and lookup services. The Business Delegate also handles the exceptions from the business services such as EJB exceptions, JMS exceptions and so on. The Business Delegate may intercept such service level exceptions and generate application level exceptions instead. Application level exceptions are easier to handle by the clients, and may be user friendly. These gains present a compelling reason to use the pattern.

Another benefit is that the delegate may cache results. Caching results can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network.

A Business Delegate uses a component called the Lookup Service. The Lookup Service is responsible for hiding the underlying implementation details of the business service lookup code. The Lookup Service may be written as part of the delegate, but we recommend that it be implemented as a separate component, as outlined in the Service Locator [SJC] pattern.

When the Business Delegate is used with a Session Façade, typically there is a 1-1 relationship between the two. This 1-1 relationship exists because logic that might have been encapsulated in a Business Delegate relating to its interaction with multiple business services (creating a 1-many relationship) will often be factored back into a Session Façade.

Finally, it should be noted that this pattern could be used to reduce coupling between other tiers, not simply the presentation and the business tiers.

Structure

The following class diagram represents the Business Delegate pattern:

Participants & Responsibilities

The following two sequence diagrams shows the interactions for the Business Delegate pattern:

The Business Delegate uses a LookupService for locating the Business Service. The Business Service is used to invoke the business methods on behalf of the client. The Get ID method shows that the Business Delegate can obtain the handle for the Business Service and return it to the client (e.g. as a String object). The client can use the handle at a later time to reconnect to the Business Service it was using when it obtained the handle. This technique will avoid a new lookup since the handle is capable of reconnecting to its Business Service instance. Handle limitations need to be observed depending on the component and the service implementation.

The following sequence diagram shows obtaining a BusinessService (such as a session or entity bean) using its handle.

The BusinessDelegate's role is to provide control and protection for the business service. The BusinessDelegate receives two types of client instantiation requests. One request instantiates the Delegate without an ID while the other instantiates it with an ID. When initialized without an ID, the Delegate requests the service from the Lookup Service typically implemented as a Service Locator (see Service Locator Pattern), which returns the Service Factory, such as EJBHome. The BusinessDelegate requests that the Service Factory locate, create or remove a BusinessService, such as an enterprise bean.

When initialized with an ID, the BusinessDelegate use the ID to reconnect to the BusinessService. Thus, the BusinessDelegate shields the client from the underlying implementation details of BusinessService naming and lookup. Furthermore, the presentation-tier client never directly makes a remote invocation on a BusinessSession; instead, the client uses the BusinessDelegate.

The Business Delegate uses the LookupService to locate the BusinessService. The LookupService encapsulates the implementation details of BusinessService lookup.

The BusinessService is a business tier component, such as an enterprise bean or a JMS component that provides the required service to the client.

Strategies

Users of the Business Delegate may consider it a nuisance to develop with implementations that use the Delegate Proxy Strategy, which provides delegate methods that basically mirror the underlying service API and act as a Proxy [GoF]. At the same time, the benefits of the pattern typically outweigh such drawbacks.

Delegate Proxy Strategy

The BusinessDelegate exposes an interface that provides clients access to the underlying methods of the business service API.

Delegate Adapter Strategy

The Business Delegate proves to be a nice fit in a B2B environment when communicating with J2EE services. Disparate systems may use an XML as the integration language. Integrating one system to another typically requires an Adapter [GoF] to meld the two disparate systems. The following interaction diagram gives an example.

Consequences

• Reduced Coupling, Improved Manageability
  Reduces coupling between the Presentation tier and the Business tier by hiding all Business tier implementation details. It is easier to manage changes because they are centralized in one place, the BusinessDelegate.
• Service Exception Translation
  The BusinessDelegate is responsible for translating any network or infrastructure-related exceptions into business exceptions, shielding clients from knowledge of the underlying implementation specifics.
• Simpler, Uniform Interface
  The BusinessDelegate, to better serve its clients, may provide a variant of the interface provided by the underlying session beans.
• Performance Impact
  The BusinessDelegate may provide caching services (and better performance) to the Presentation tier for common service requests.

Related Patterns

• Service Locator Pattern [SJC]
  This Service Locator pattern may be used to create the delegate's Service Locator, hiding the implementation details of any business service lookup and access code.
• Proxy Pattern [GoF]
  BusinessDelegate may act as a proxy, providing a stand-in for objects in the business tier.
• Adapter Pattern [GoF]
  Business Delegate may use the Adapter pattern to provide coupling for disparate systems.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta