From the book
From the book
Solution
Use a Business Delegate to encapsulate access to a business service. The Business Delegate hides the implementation details of the business service, such as lookup and access mechanisms.
A Business Delegate acts as a client-side business abstraction: it abstracts and hides the implementation details of the business services. Using a Business Delegate reduces the coupling between the client and the system's business services. Depending on the implementation strategy, the Business Delegate might 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 client code when the business service API or its underlying implementation changes.
However, interface methods in the Business Delegate might still require modification if the underlying business service API changes. Admittedly, though, it is more likely that changes will be made to the business service than to the Business Delegate.
Developers are sometimes skeptical when a design goal, such as abstracting the business layer causes additional up front work in return for future gains. However, using a Business Delegate has the following benefits:
- The main benefit is hiding the details of the underlying service. For example, by using the Business Delegate, the client becomes transparent to naming and lookup services.
- A Business Delegate also handles the exceptions from the business services, such as java.rmi.Remote exceptions, JMS exceptions, and so on. The Business Delegate might intercept such service-level exceptions and generate application-level exceptions instead. Application-level exceptions are easier to handle by the clients, and are more likely to be user friendly.
- A Business Delegate can also transparently perform any retry or recovery operations necessary in the event of a service failure, without exposing the client to the problem, unless it is determined that the problem is not resolvable. These gains present a compelling reason to use the pattern.
- The Business Delegate (302) can cache results and references to remote business services. Caching can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network.
A Business Delegate (302) uses a Service Locator (315) to locate the business service. The Service Locator (315) is responsible for hiding the underlying implementation details of the business service lookup code.
When a Business Delegate (302) is used with a Session Façde (341), typically there is a one-to-one relationship. This one-to-one relationship exists because logic that might have been encapsulated in a Business Delegate (302) relating to its interaction with multiple business services (creating a one-to-many relationship) will often be factored back into a Session Façde (341).
The Business Delegate (302) pattern is categorized as a business-tier pattern and not a presentation-tier pattern because the Business Delegate is a logical abstraction, not a physical one. When used with a presentation tier, the actual Business Delegate components live in the presentation tier. However, they are a logical extension of the business tier. Because of this, and because of the pattern’s close association with business components such as Session Façde (341), we recommend that business service developers implement Business Delegates.
Structure
Figure 7.1 shows the class diagram for the Business Delegate pattern. The client asks the BusinessDelegate component to provide access to the underlying business service. The BusinessDelegate uses a ServiceLocator to locate the required BusinessService component.
){kind=small}
Figure 7.1 Business Delegate Class Diagram
Participants and Responsibilities
Figure 7.2 and Figure 7.3 show sequence diagrams that illustrate typical interactions for the Business Delegate pattern.
The get ID message in the sequence diagram shows that the BusinessDelegate can obtain a String representation of the Handle (such as the EJBHandle object) for the BusinessService. The client can use the ID string to reconnect to the same BusinessService it was using previously.
)
Figure 7.2 Business Delegate Sequence Diagram
This technique avoids new lookups, because a Handle can reconnect to its BusinessService instance. Note that Handle objects are implemented by the container provider and might not be portable across containers from different vendors.
The sequence diagram in Figure 7.3 shows the Client obtaining a reference to a previously used BusinessService, such as a session or an entity bean, using its Handle.
BusinessDelegate
The BusinessDelegate’s role is to provide control and protection for the business service. The BusinessDelegate can expose two types of constructors to clients:
- A default constructor to instantiate the BusinessDelegate.
- A constructor to instantiate the BusinessDelegate with an ID as an argument, where ID is a string representation of the reference to a remote object, such as EJBHome or EJBObject.
)
Figure 7.3 Business Delegate With ID Sequence Diagram
When created without an ID, the BusinessDelegate requests the business service from the ServiceLocator, typically implemented as a Service Locator (315), which returns a service factory object, such as an EJBHome. The BusinessDelegate uses the service factory to locate, create, or remove a BusinessService, such as an enterprise bean.
When initialized with an ID string, the BusinessDelegate uses the ID string to reconnect to the BusinessService, shielding the client from the underlying implementation details of BusinessService naming and lookup. The client never directly makes a remote invocation on a BusinessService; instead, the client uses the BusinessDelegate.
ServiceLocator
The ServiceLocator is a role fulfilled by a Service Locator (315) implementation. The ServiceLocator encapsulates the implementation details of locating a BusinessService component.
BusinessService
The BusinessService is a business-tier component, such as an enterprise bean, that is being accessed by the client. The component is typically implemented as a Session Façde (341) or a JMS component.
Strategies
Business Delegate offers a simple but powerful abstraction to decouple the business service components in the business tier from the rest of the application. This makes it easier for application developers to use these business services. The following are some of the common implementation strategies for the Business Delegate pattern.
Delegate s Strategy
A Business Delegate exposes an interface that provides clients access to the underlying functionality of the business service API.
In the Delegate Proxy strategy, a Business Delegate acts as a proxy for a remote business service, passing client method calls to the service object for which it is acting as a proxy. Because you implement this delegate proxy as a business-tier developer, you can add behavior such as some types of validation and caching business data and references. Caching can include the remote references to a session bean’s home or remote objects to improve performance by reducing the number of lookups. The Business Delegate can also convert, such references to String representations (IDs) and vice versa, using a Service Locator (315).
Delegate Adapter Strategy
If you’re running a B2B environment, you must assume that the systems interacting with yours might not be running on J2EE. You must provide a solution for integrating these external systems so they can interact with your system, and using XML is a common approach. The Delegate Adapter is a good strategy for doing this. Figure 7.4 gives an example.
)
Figure 7.4 Using the Business Delegate Pattern With an Adapter Strategy