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
architectsand requirements engineersdo 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 evolvefrom 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
relatesto 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
leveragesthis 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 sizedrestaurant 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
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
In Chapter 14, "Exploring the Faux Implementation Pattern," the interface represented sometimes
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
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,
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
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
An existing pattern in the pure object-oriented world can help you create Java applications that
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.
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