35.2. Failover to Local Services; Performance with Local Caching
One of the NextGen requirements is some degree of recovery from remote service failure, such as a (temporarily) unavailable product database.Access to product information is the first case used to explore the recovery and failover design strategy. Afterwards, access to the accounting service is explored, which has a slightly different solution.To review part of the technical memo:
Technical Memo: Issue: ReliabilityRecovery from Remote Service FailureSolution Summary: Location transparency using service lookup, failover from remote to local, and local service partial replication. Factors
Solution Achieve protected variation with respect to location of services using the Adapter served up from a ServicesFactory. Where possible, offer local implementations of remote services, usually with simplified or constrained behavior. For example, the local tax calculator will use constant tax rates. The local product information database will be a small cache of the most common products. Inventory updates will be stored and forwarded at reconnection.See also the AdaptabilityThird-Party Services technical memo for the adaptability aspects of this solutions, because remote service implementations will vary at each installation.To satisfy the quality scenarios of reconnection with the remote services, use smart Proxy objects for the services, that on each service call test for remote service reactivation, and redirect to them when possible.Motivation Retailers really don't want to stop making sales! Therefore, if the NextGen POS offers this level of reliability and recovery, it will be a very attractive product, as none of our competitors provide this capability. |
- The ServicesFactory will always return an adapter to a local product information service.
- The local products "adapter" is not really an adapter to another component. It will itself implement the responsibilities of the local service.
- The local service is initialized to a reference to a second adapter to the true remote product service.
- If the local service finds the data in its cache, it returns it; otherwise, it forwards the request to the adapter for the external service.
- The in-memory ProductCatalog object will maintain an in-memory collection (such as a Java HashMap ) of some (for example, 1,000) ProductDescription objects that have been retrieved from the product information service. The size of this collection can be adjusted depending on local memory availability.
- The local products service will maintain a larger persistent (hard disk based) cache that maintains some quantity of product information (such as 1 or 100MB of file space). Again, it can be adjusted depending on the local configuration. This persistent cache is important for fault tolerance, so that even if the POS application crashes and the in-memory cache of the ProductCatalog object is lost, the persistent cache remains.
Figure 35.1. Adapters for product information.
[View full size image]
Figure 35.2. Initialization of the product information service.
[View full size image]
Figure 35.3. Starting the collaboration with the products service.
[View full size image]
Figure 35.4. Continuing the collaboration for product information.
[View full size image]
Figure 35.5. New external services do not affect the design.
[View full size image]
Figure 35.6. Collaboration with the persistence subsystem.
[View full size image]
Caching Strategies
Consider the alternatives for loading the in-memory ProductCatalog cache and the LocalProducts file-based cache: One approach is lazy initialization, in which the caches fill slowly as external product information is retrieved; another approach is eager initialization, in which the caches are loaded during the StartUp use case. If the designer is unsure which approach to use and wants to experiment with alternatives, a family of different CacheStrategy objects based on the Strategy pattern can neatly solve the problem.
Stale Cache
Since product prices change quickly, and perhaps at the whim of the store manager, caching the product price creates a problemthe cache contains stale data; this is always a concern when data is replicated. One solution is to add a remote service operation that answers today's current changes; the LocalProducts object queries it every n minutes and updates its cache.
Threads in the UML
If the LocalProducts object is going to solve the stale cache problem with a query for updates every n minutes, one approach to the design is to make it an active object that owns a thread of control. The thread will sleep for n minutes, wake up, the object will get the data, and the thread will go back to sleep. The UML provides notation to illustrate threads and asynchronous calls, as shown in Figure 35.7 and Figure 35.8.
Figure 35.7. Threads and asynchronous messages in the UML.
[View full size image]