Using a faux implementation as a solution to your heavyweight client for subscribing to event services
Physical Tiers: The Physical Tiers pattern and the Connector pattern from the previous chapter give you an alternate mechanism for solving your application subscription problem. Although the Physical Tiers and Connector patterns embrace the heavyweight client solution, it is still a worthy solution to building a Web Service Subscriber implementation.
Fowler, Martin et. al. Patterns of Enterprise Application Architecture . Addison-Wesley, 2002.
Gamma, Erich et. al. Design Patterns: Elements of Reusable Object-Oriented Software . Addison-Wesley, 1995.
The service factory pattern has its roots in classic object-oriented design patterns such as the Abstract Factory pattern from the Gang of Four's book,
Design Patterns: Elements of Reusable Object-Oriented Software
(Addison-Wesley, 1995). The idea is simple: You should isolate points of variability into contained, easily manageable blocks of code. For example, the P.T. Monday Coffee Company application can use one of several different bean suppliers to provide raw beans that it subsequently roasts and sends to customers. Deciding which supplier to use is a point of variability and should therefore be isolated to its own module of code. However, the interface to any supplier's ordering Web Service should not be a point of variability and should
The Service Factory pattern is a critical pattern to use as you move the P.T. Monday Coffee Company application from a simple, monolithic application to a truly dynamic application. The Service Factory pattern facilitates your ability to choose the best business partner for a particular transaction at runtime rather than at implementation time. For example, rather than having a single bean supplier, the service factory isolates code that chooses which bean supplier to use at runtime. The choice criteria could be as simple as choosing from a predefined list or as complex as searching a Universal Description, Data, and Discovery (UDDI) directory for a potential business partner for each transaction.
In this chapter, you will use the Service Factory pattern to abstract your application away from the details of choosing a partner's Web Service. Before using the Service Factory pattern to the desired effect, you must understand some aspects of your environment. Specifically, you will re-examine the importance of common interfaces in Web Services as well as the importance of UDDI to facilitate your searches for business