33.3. Failover to Local Services with a Proxy (GoF)
Failover to a local service for the product information was achieved by inserting the local service in front of the external service; the local service is always tried first. However, this design is not appropriate for all services; sometimes the external service should be tried first, and a local version second. For example, consider the posting of sales to the accounting service. Business wants them posted as soon as possible, for real-time tracking of store and register activity.
In this case, another GoF pattern can solve the problem: Proxy. Proxy is a simple pattern, and widely used in its Remote Proxy variant. For example, in Java's RMI and in CORBA, a local client-side object (called a “stub”) is called upon to access a remote object's services. The client-side stub is a local proxy, or a representative for a remote object.
This NextGen example use of Proxy is not the Remote Proxy variant, but rather the Redirection Proxy (also known as a Failover Proxy) variant.
Regardless of the variant, the structure of Proxy is always the same; the variations are related to what the proxy does once called.
A proxy is simply an object that implements the same interface as the subject object, holds a reference to the real subject, and is used to control access to it. For the general structure, see Figure 33.12.
Figure 33.12. General structure of the Proxy pattern.
|
Proxy Context/Problem Direct access to a real subject object is not desired or possible. What to do? Solution Add a level of indirection with a surrogate proxy object that implements the same interface as the subject object, and is responsibility for controlling or enhancing access to it. |
Applied to the NextGen case study for external accounting service access, a redirection proxy is used as follows:
Send a postSale message to the redirection proxy, treating it as though it was the actual external accounting service.
If the redirection proxy fails to make contact with the external service (via its adapter), then it redirects the postSale message to a local service, which locally stores the sales for forwarding to the accounting service, when it is active.
Figure 33.13 illustrates a class diagram of the interesting elements.
Figure 33.13. NextGen use of a redirection proxy.
UML notation:
To avoid creating an interaction diagram to show the dynamic behavior, observe how this static diagram uses numbering to convey the sequence of interaction. An interaction diagram is usually preferred, but this style is presented to illustrate an alternative style.
Observe the public and private ( +, - ) visibility markers beside Register methods. If absent, they are unspecified, rather than defaulting to public or private. However, by common convention, unspecified visibility is interpreted by most readers (and code generating CASE tools) as meaning private attributes and public methods. However, in this diagram, I especially want to convey the fact that makePayment is public, and by contrast, completeSaleHandling is private. Visual noise and information overload are always concerns in communication, so it is desirable to exploit conventional interpretation to keep the diagrams simple.
To summarize, a proxy is an outer object that wraps an inner object, and both implement the same interface. A client object (such as a Register) does not know that it references a proxy—it is designed as though it is collaborating with the real subject (for example, the SAPAccountingAdapter). The Proxy intercepts calls in order to enhance access to the real subject, in this case by redirecting the operation to a local service (LocalAccounting) if the external service is not accessible.