Business Delegate
Problem:
You want to hide clients from the complexity of remote communication with business service components. Business components are exposed to clients leading to coupling and fine-grained access.
Forces:
Clients need access to business services.
Complexity of remote objects. You want to avoid unnecessary invocation of remote services.
Clients and business components become tightly coupled. You want to minimize coupling between clients and the business services, thus hiding the underlying implementation details of the service, such as lookup and access.
Business services APIs may change. You want to hide the details of service creation, reconfiguration, and invocation retries from the clients.
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. Use a Business Delegate to reduce coupling between presentation-tier clients and business services:
Consequences:
Reduces coupling, increases maintainability.
Implements failure recovery: Retry or Synchronize.
Translates network (System) Exceptions to Business service Exceptions.
Exposes simpler, uniform Interface to the business tier.
Performance enhancing cache.
Hides complexities of remote services.
Service Locator
Problem:
Clients want to transparently locate business components and services in a uniform manner.
Forces:
Vendor dependencies are exposed to the clients, we want to encapsulate vendor dependencies for registry implementations, and hide the dependency and complexity from the clients.
Complexity and duplication of lookup and creation. Clients want to centralize and reuse the implementation of lookup mechanisms.
Clients may need to reestablish connection to a previously accessed business object.
Clients want to avoid performance overhead related to initial context creation and service lookups.
Solution:
Use a Service Locator to implement and encapsulate service and component lookup. A Service Locator hides the complexities of Initial Context creation, lookup, and object re-creation:
Consequences:
Abstracts complexity of lookups.
Uniform lookup for all clients.
Improves network performance.
Improves client performance by caching.
Proxy
Problem:
Provide a stand-in or placeholder to another object, in order to control access to it.
Forces:
The desired object may be inaccessible (if it exists in a different address space).
The desired object may be expensive to instantiate and you want to delay its creation until absolutely necessary.
The desired object may need to be protected from unauthorized access.
You may need to perform special actions upon accessing the desired object.
Solution:
Use a Proxy to provide a separate implementation of interface and working code for location transparency:
Consequences:
Decouples interface and implementation by providing two objects.
Proxy handles all incoming requests to the object, it knows how to contact the object if it is remotely located.
Proxy passes along all authorized communication to the object (and prevents unauthorized communication).
If the Implementation class changes, the Proxy remains the same.
An example is the EJB's Remote Interface.
Session Façade
Problem:
Tight coupling between clients and business tier; fine-grained access.
Forces:
You want to avoid giving clients direct access to business-tier components, to prevent tight coupling with the clients.
Numerous business objects are exposed over the network.
No uniform access to business tier. You want to centralize and aggregate all business logic that needs to be exposed to remote clients.
Clients are exposed to complex interactions and interdependencies of business objects. You want to hide the complex interactions and interdependencies between business components and services to improve manageability, centralize logic, increase flexibility, and improve ability to cope with changes.
Solution:
Use a Session Façade to encapsulate business-tier components and expose a coarse-grained service to remote clients. Clients access a Session Façade instead of accessing business components directly. Use a Session Façade to encapsulate the complexity of interactions:
Consequences:
Controller layer for business tier.
Uniform exposure of business components.
Reduces coupling between the tiers.
Provides a uniform coarse-grained access.
Centralizes business logic.
Centralizes security management.
Centralizes transaction control.
Exposes fewer remote interfaces to clients.
Improves performance, reduces fine-grained remote methods.
Adapter (Wrapper)
Problem:
Convert the interface of a class into another interface clients expect.
Forces:
A potentially reusable class may not have the appropriate interface required by the particular application domain.
Solution:
Adapter lets classes work together that could not otherwise because of incompatible interfaces. Use an Adapter pattern to adapt one interface to another:
Consequences:
Adapter pattern maps the interface of one class onto another so that they can work together. These incompatible classes may come from different libraries or frameworks.
Adapter pattern can be used to expose existing component as Web Service.
Adapter pattern helps resolve integration issues.
Command
Problem:
There are a lot of similar methods, and the interface to implement that kind of object is becoming heavy.
Forces:
Too many public methods for other objects to call. An interface that is unworkable and always changing. You feel that a method name must include prose describing the exact action, and this is preventing layering your code.
Solution:
Encapsulate a request as a Command object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Consequences:
Command pattern is an example of pluggable behavior that enforce client access to Web Services.
The Command pattern is commonly used for gathering requests from client objects and packaging them into a single object for processing.
The Command pattern allows for having well defined command interfaces that are implemented by the object that provides the processing for the client requests packaged as commands.
Command design pattern provides a convenient way to store and execute an "Undo" function.
Command decouples the object that invokes the operation from the one that knows how to perform it.
Commands can be manipulated and extended like any other object.
Commands can be made into a composite command.
Commands can be stored. Since a command encapsulates all the data for a given request, it can be created and initialized at one point and applied at another.
Web Service Broker
Problem:
You want to provide access to one or more services using XML and web protocols.
Forces:
You want to reuse and expose existing services to clients.
You want to monitor and potentially limit the usage of exposed services, based on your business requirements and system resource usage.
Your services must be exposed using open standards to enable integration of heterogeneous applications.
You want to bridge the gap between business requirements and existing service capabilities.
Solution:
Use a Web Service Broker to expose and broker one or more services in your application to external clients as a Web Service using XML and standard web protocols:
Consequences:
Introduces a layer between client and service.
Existing remote Session Façades need be refactored to support local access.
Network performance may be impacted due to web protocols.
Coordinates interactions among one or more services, aggregates responses and may demarcate and compensate transactions.
