In this article, I will focus on the Business Delegate enterprise design pattern. This pattern describes a relatively new application of an old concept that facilitates decoupling between application tiers and various business services. I will describe the pattern in detail with an example of real enterprise usage. In addition, I will talk about key concepts and the evolution of this pattern. The idea of hiding complex implementations from different software clients or tiers is not new, GoF* book describes several patterns that make it possible. For example, a Façade [GoF] pattern provides a single high-level interface for a set of interfaces in a system and therefore hides the original implementation from the client subsystems. An Adapter [GoF] pattern or Broker pattern provide coupling for disparate systems, thereby also concealing the implementation of the parent system from the subsystems that use it.
* GoF: Gang of Four book Design Patterns: Elements of Reusable Object-Oriented Software (see references and my previous article for more info).
Business Delegate Concepts
Patterns such as Façade or Adapter were designed to work on the object level on the same machine. However, a more robust solution is needed due to the scope of the complex distributed enterprise systems using multi-tier components, which could span across multiple containers, networks, and platforms.
Why would one want to decouple the implementation of the presentation-tier components from business services? Why prevent direct interaction of the remote invocation clients with the server? After all, the distributed components provide public APIs that other components can call. To answer these questions, imagine a massive in-house developed enterprise application that delivers corporate e-mail to various software clients. Some clients are Web-browser based, some are remote-invocation Java Swing applications, and some are WEP cell phones and PDAs. If business service layer APIs that deliver e-mail change, as business requirements for e-mail delivery evolve, all of the dependent software clients would need to be rewritten.
Another example would be a dependence on the lookup and instantiation logic of EJBs by the distributed clients or lookup and instantiation of the JMS clients which, if hard coupled by the direct APIs, would be susceptible to the changes in the implementation of the business layer.
In all of these cases, a poorly designed distributed architecture could lead to massive amounts of work later on. In comparison, the Business Delegate pattern requires only a small upfront development time, and its incorporation, especially in large enterprise applications could be very cost efficient.
Business Delegate Implementation
There are many different implementations of the Business Delegate pattern. Most of the implementations reduce coupling and provide greater manageability, and hide complex business APIs by exposing a simpler interface. In addition to theses features, Business Delegate also can (and should) be used to provide additional functionalities, such as conversion of the business level errors into client level (or application level) exceptions, or caching data and request information; therefore, improving distributed performance and reducing load on the business service components. Business Delegate can serve as a proxy to the remote clients to reduce the network traffic. Business Delegate also can hide problems in the business level by implementing error recovery logic to retry operations or bypass issues. This occurs without revealing errors to the subsystems and removing the need to code error recovery logic in the different software clients.
Evolution of the Business Delegate Pattern
Look at the real-world example where this pattern could be applied. An enterprise trading application needs to have a JMS feed of the market data, interact with the EJB layer that provides container managed persistence for some of that data as well as other services, and display some of the transaction information in the GUI to the clients. In addition, the application needs to expose some functionality as a Web service.
With the Business Delegate pattern, architects conceptually need to separate consumers of the services from the providers. In this case, the application will be a consumer of the JMS feed and a consumer to the EJB business layer. It will also be a provider to the GUI clients, and a provider to the Web service clients. Therefore, four different Business Delegates potentially can be implemented. The Web service Business Delegate is really an extension or an evolution of this pattern because, by their nature, Web services already hide the implementation from the clients. Wrapping a Web service in a Business Delegate makes interaction with the Web service even more transparent. In addition, the Web service Business Delegate could also add caching, error translation, and error recovery, or even modify/format the results from the service.
The other Business Delegates can be used in conjunction with the Session Façade and Service Locator design patterns to further decouple the application.
Here is a more detailed diagram of the enterprise application.
Considerations of the Business Delegate’s Use
If the core logic of the large applications is encapsulated by several implementations of the Business Delegate, all of the subsystems or remote software clients talk to the business layer though them. Changes to the business rules consequently would require modifications to the Business Delegates. Therefore, architects need to keep that in mind when designing the system. But, the maintenance cost of several Business Delegates is still much lower than changes to all of the client modules. Furthermore, the business logic that overleaps in different Business Delegates should be combined or inherited. For example, logic that retrieves the stock data for the web GUI also can do so for the Web service in the one parent delegate, and the output specifics can be handled by specific delegates.
In this article, I have talked about the benefits of decoupling of business services from the distributed clients, and have described the standard software pattern to do it. The notion of the separation between business tier and components that consume business logic can greatly simplify large scale applications. Thus, the Business Delegate should definitely be familiar to any enterprise architect.
- Thinking in Patterns with Java
- Bruce Eckel: http://www.topica.com/lists/TIPatterns/
- Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Publisher: Addison-Wesley Professional; 1st edition (January 15, 1995). ISBN: 0201633612
- Core J2EE Patterns: Best Practices and Design Strategies by Deepak Alur, John and Dan Malks. Publisher: Prentice Hall/Sun Microsystems Press. ISBN: 0130648841; 1st edition (June 26, 2001)
- EJB best practices: The Business Delegate pattern
- Brett McLaughlin (brett@newInstance.com)
- Façade Pattern.
About the Author
Vlad Kofman is a Senior System Architect. He has implemented enterprise-scale projects for the major Wall Street firms, defense contracts, and the U.S. government. His main interests are object-oriented programming methodologies and their design patterns.