Seeing Service Factory in Practice

In business, applications must be able to fulfill business process responsibilities, or the activities that make up a business process, in multiple and varying ways. Business processes change because of the following reasons:

Business needs change over time: Obviously, business needs change over time, yet historically architects and requirements engineers do not always account for this scenario when they design an application. Further, given a set of requirements, the programmers often meet the requirements yet fail to predict points of flexibility that the architects miss . For example, a company focused on shirts may quickly move into accessories such as ties. Even when compiling the requirements for the P.T. Monday Coffee Company, you determined that the application will evolve from a direct sales model to a coffee bean supplier for restaurants . In this case, you caught the point of variability when gathering the requirements, but this will not always be the case.

Business activities carried out by a business process change in their ability to fulfill requirements: This relates to the previous point, but in a bottom-up manner. For example, your shipper of choice could raise its prices and, thus, drive your customer base to move to a company that provides lower shipping rates. Environmental factors could also influence a supplier's abilities , which is the case with raw coffee bean supplies . A farmer in a drought will simply be unable to fulfill the needs of your growing coffee company.

Inputs to a business process change: Finally, the requirements placed on your business process may change over time, which is the case with the growing P.T. Monday Coffee Company. A perfect example of this is the business requirement B1: The application shall have the ability to integrate into the reseller's value chain. When your company leverages this requirement by having a large restaurant chain use you as a supplier, the demand for raw coffee beans from your own suppliers will explode. The suppliers that fulfilled the demands of 1,000 direct sales will not be able to fulfill the demands of 100,000 cups of coffee a day from even a moderately sized restaurant chain.

In all of these cases, your application must add to or modify the services you implement. You must also change the services from other companies that you depend on or actually change the company that fulfills a part of your business process. The ability to create a fully dynamic application that can rapidly change with the evolving needs of your company is difficult, but not impossible . The evolving interface standards in Web Services are a prerequisite to having a fully dynamic business. You also need a common registry where you can locate new, trusted business partners at a moment's notice. The former requirement is happening slowly through standards bodies, and the latter requirement is evolving more quickly through the UDDI implementation.

Introducing Common Interfaces for Web Services

The idea of a common interface in a Web Service environment is similar to the concept in the Java programming language. In a Web Service environment, two service implementations that derive from the same technical model (tModel) ” not including the service binding information ” adhere to the same interface. Consider the power of interface-based programming from the previous two chapters. In Chapter 13, "Exploring the Physical Tiers Pattern," you used an interface that represented a business object in both the Web tier and the logic tier. In the logic tier, this interface represented a concrete implementation with business logic. In the Web tier, the interface represented a proxy that talks across process boundaries to the logic tier 's concrete implementation. Both tiers used the same interface, but the behavior was remarkably different. This remote/local implementation dichotomy under a single interface is, in essence, the Connector pattern.

In Chapter 14, "Exploring the Faux Implementation Pattern," the interface represented sometimes radically different implementations of the same outward semantic interface and behavior. Using the interface in this chapter allowed you to replace a hardware implementation with a software implementation; the practice is known as emulation . The interface also allowed you to replace what was expected to be a first-class Web Service with a simple socket listener.

The versatility of interface-based programming does not stop with these scenarios. You can also use common interfaces in a scenario that allows you to use business process implementations from different partners without affecting your own business process programming. You do this by programming your own business process to use the interface of a Web Service rather than a particular partner's Web Service implementation. At runtime, you can then dynamically choose any partner's implementation to fulfill the needs of your application.

A more complex problem is how to get businesses to agree on a common interface. Once businesses agree on a common interface, how do you enforce consistency in the implementation and behavior of the common interface? There are many efforts, generally led by industry experts, to create consistent interfaces; some of the working groups within ebXML (http://www.ebxml.org) and Oasis (http://www.oasisopen.org) are among the furthest along. Oasis contains committees to standardize many government and legal interactions.

Once the interfaces to business processes are standardized, they must be enforced. One of the common practices in the high-tech industry is to "innovate" beyond the standardized services. Although innovation is good, the problem is that this innovation drives vendors to create exceptions to a standardized model. Exceptions in how companies implement a business activity hurt your ability to create a single application that supports all of the vendors you want to participate in your business process fulfillment strategies.

Fortunately, the small P.T. Monday Coffee Company can likely avoid large standards bodies and work with suppliers directly to create simple, common Web Service interfaces. On the other hand, by adopting Web Services early, you will end up modifying your application several times. The large companies you depend on will iterate their interfaces as standards evolve. Further, they may modify the interfaces to their own needs as they become more sophisticated in using and building Web Services. Your only hope is to isolate the code that interacts with the companies and hope the changes do not incur a large penalty on you in terms of maintenance.

An existing pattern in the pure object-oriented world can help you create Java applications that absorb the changes from other companies and, even, further isolate company-specific handling. Specifically, the Mediator pattern shows you that you can create your own common interface and create custom implementations for each company on which you depend. Your own code would then handle the differences in each company's service implementation so that your primary path can adhere to a common set of code for handling a particular business activity.

This book does not go into depth on the Mediator pattern because the pattern is an extension to the Service Factory pattern, which relies more on the Java architecture than the Web Service architecture. This chapter assumes that all of your partners implement a single interface directly. You can use the interface that you expect your business partners to implement as input to locating potential business partners in a service directory, such as UDDI.

Understanding the Importance of the Service Directory

The Service Directory pattern implemented with UDDI serves a pivotal role in the Service Factory pattern. One of the base assumptions in the case study application is that you will have an ever-expanding number of coffee bean suppliers to choose from when you need to order more coffee beans. However, you will not know all of the bean suppliers that you could use when you program the P.T. Monday Coffee Company application. Instead, you will occasionally search for potential new partners in UDDI. When you find potential new partners, you will hope that they implement the common interface that you planned for when you built the application. If the bean supplier does implement the common interface, you can talk to its Web Service immediately, without modifying your application code.

UDDI facilitates this ability to search for and understand the interface to a Web Service. The traditional Abstract Factory pattern does not have the benefit of such a robust mechanism for locating classes that fulfill a particular need. Typically, class factories implement custom logic to locate a suitable implementation of a class. The Web Service's directory abstracts this custom location logic out of your own application in favor of a centralized directory of all available Web Services. Perhaps the downside of UDDI is the relatively sharp learning curve of implementing a Service Factory pattern that recognizes the broad scope of any service available on the Internet.

The service factory structure and collaborations give more insight as to how you leverage UDDI as a first-class component of a service factory implementation. When you move to the more-specific Web Service implementation, you will need to revisit the interface to UDDI that you started to examine in Chapter 5, "Exploring the Service Directory Pattern."