In this chapter, we are going to take a detailed look at the Business Delegate Pattern.
What is Business Delegate Pattern?
The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other.
This pattern is a proxy that hides the complexity of remote service lookup and error recovery. It makes it easier to communicate requests and results from one layer to another.
This is not a pattern for a layer itself. It isn't a way for you to create a business logic component or structure. Rather, it is an interface to a tier so that you can change the underlying components and not disturb the presentation tier.
This pattern is like an ambassador. Like all good ambassadors, it can pass on the message from the host country to any other.
Whenever there is a dependency on a remote service, the probability of change between the caller and the called increases. How can you reduce the chances of the layer depending on the remote service breaking should the remote service change? This pattern helps protect the local layer from changes made to the remote service.
Ex: Lets say, the presentation tier interacts directly with a remote business logic layer. What if the business services change and the old API becomes invalid? If this happens the presentation tier will break.
This delegate is the proxy between the local layer and the remote service layer. It is responsible for reliably allowing the front layer to access the remote service.
This pattern isolates the presentation layer from changes in the business tier API.
This pattern matches presentation component calls to the correct business tier methods.
The current approach to multi-tier systems is to couple the presentation tier directly to the entire business service API; sometimes this coupling is made across a network.
• Presentation-tier clients (including devices) need access to business services.
• The business tier API may change.
• The industry trend for large systems is to minimize coupling between presentation-tier clients and the business service API. This isolates the two so that a change in either side can be managed by the middle layer.
• There is a need for a cache between tiers.
• This pattern adds more work to building a system.
Large systems change components often. There is often a change in the business tier that breaks the access portion of clients.
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers from each other by adding a director between the two, making it is easier to manage changes on either side.
• B2B systems usually employ an XML exchange for communicating between disparate systems.
• Proxy services represent this pattern.
• Look up services usually represent this pattern, too.
• This pattern can be thought of as an underlying design feature of Java's overloading capability such as the System.out.print() group of methods. Using the same method name, you can print almost anything to the console, because the printing service handles the different data types. This pattern is bigger than that, but overloading illustrates the idea.
Other Related Patterns
• Service Locator Pattern— This pattern provides a common API for any business service lookup and access code.
• Proxy Pattern— Provides a stand-in for objects in the business tier.
• Adapter Pattern— You can use the Adapter pattern to provide coupling for disparate systems.
Previous Chapter: Chapter 54 - DAO Pattern
Next Chapter: Chapter 56 - MVC Pattern
© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.