1 / 20

Chapter 36

Chapter 36. More Object Design with GoF Patterns. NextGen POS Requirements. Failover to a local service when a remote service fails Local caching Support for third-party POS devices Handling credit, debit, and check payments (and cash). Local Caching.

saul
Download Presentation

Chapter 36

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 36 More Object Design with GoF Patterns CS6359 Fall 2011 John Cole

  2. NextGen POS Requirements • Failover to a local service when a remote service fails • Local caching • Support for third-party POS devices • Handling credit, debit, and check payments (and cash) CS6359 Fall 2011 John Cole

  3. Local Caching • Some database elements and other data can be persisted locally such that if the service that provides them isn’t available, you have some (limited) functionality • For example, if the ProductDescription database is offline, the most frequently-purchased products can be found in a file on a local disk CS6359 Fall 2011 John Cole

  4. Levels of Cache • In-memory caching can keep some fixed number of elements. Sometimes this may be then entire list. • Local hard-drive caching could limit by file size rather than number. (How would you organize this?) • Which patterns does this use so far? • Adapter and Factory CS6359 Fall 2011 John Cole

  5. Caching Strategies • Lazy initialization: Fill the in-memory cache and LocalProducts file as external product info is retrieved • Eager initialization loads them during start-up • Cache can go stale quickly; it should be refreshed occasionally if possible. Prices can change quickly CS6359 Fall 2011 John Cole

  6. Caching and Threads • One way to solve the stale cache problem is to have a thread wake up and check for updates. • (What is another way, using a GoF pattern?) CS6359 Fall 2011 John Cole

  7. Dealing With Failure • In the example, suppose an item is not in the local cache and the external service is offline. • You could ask for a description and price, or cancel the entry. CS6359 Fall 2011 John Cole

  8. Terminology • Fault: The ultimate origin or cause of misbehavior • Error: Manifestation of the fault in the running system • Failure: Denial of services caused by an error CS6359 Fall 2011 John Cole

  9. Throwing Exceptions • Exceptions are appropriate when dealing with resource failures and other external services • Where to handle the exception? CS6359 Fall 2011 John Cole

  10. Pattern: Convert Exception • Avoid showing lower-level exceptions coming from lower-level services • Convert a lower-level exception to one that is meaningful at the level of the subsystem. Higher level exception usually wraps the lower-level exception and adds information to make it meaningful to the higher level • No one but a programmer wants to see a stack trace CS6359 Fall 2011 John Cole

  11. Pattern: Name the Problem • Assign a name that describes why the exception is being thrown, not the thrower. • For example, “File not found” or “Duplicate key” CS6359 Fall 2011 John Cole

  12. Exceptions in UML • UML allows the operation syntax to be in any language, such as Java: • Object get(key, class) throws DBUnavailableException, FatalException • Default syntax allows exceptions to be defined in a property string • Exception is a specialization of Signal, which is the specification of asynchronous communication between objects. • Exception handling in UML is rarely used. CS6359 Fall 2011 John Cole

  13. Exceptions in UML CS6359 Fall 2011 John Cole

  14. Error Handling Pattern: Centralized Logging • Use a Singleton-accessed central error logging object and report all exceptions to it. In a distributed system, each local singleton will collaborate with a central error logger • Gives consistency in reporting • Flexible definition of output strams and formats • Also known as Diagnostic Logger CS6359 Fall 2011 John Cole

  15. Pattern: Error Dialog • Standard Singleton-accessed application-independent, non-UI object to notify users of errors. It wraps one or more UI “dialog” objects and delegates notification to them. This lets you generalize and output errors as a modal dialog, sound, calling a cell phone, etc. CS6359 Fall 2011 John Cole

  16. Benefits of Error Dialog • Protected Variations with respect to output mechanism • Consistent style of reporting • Centralized control of common strategy for error notification • Minor performance gain • In simple programs, you probably don’t need to use this CS6359 Fall 2011 John Cole

  17. Failover with a Proxy • Sometimes the remote service should be tried first, then the local service (why?) • In Java RMI and CORBA, a local client-side object is called to access a remote object’s services. This “stub” is a local proxy or representative for a remote object CS6359 Fall 2011 John Cole

  18. Proxy • Problem: Direct access to a real subject object is not possible • Solution: add a level of indirection, as described below • Proxy is an object that implements the same interface as the subject object, holds a reference to the real subject, and controls access to it CS6359 Fall 2011 John Cole

  19. Proxy in NextGen • Send a postSale message to the proxy, as though it were the actual accounting interface • If the proxy cannot connect to the service (via its adapter) it redirects the message to a local service, which stores it locally until the remote service is available • Diagram on P. 594 CS6359 Fall 2011 John Cole

  20. CS6359 Fall 2011 John Cole

More Related