Leveraging Observers in the Case Study

The Observer pattern is a critical pattern to the success of Web Services and to the usefulness of your application. Making clients rely on the event monitor to determine when important changes of state occur is a recipe for disaster. First, clients will be unable to build applications that have timely, lossless notifications of state changes. Second, as clients start to build applications that rely heavily on timely data, the polling of event monitors increases , forcing your own application to require more resources. You do not want to wait for clients to complain about a lack of functionality or for clients to drive your servers into the ground. Instead, you should use observers on any Web Services that may be interesting to clients.

Like the previous chapter, you can use the application requirements to help determine where to use the Observer pattern. Table 11-1 illustrates a few of the requirements that can lead you to decide to use the Observer pattern.

Table 11-1: Sample Requirements Leading to the Observer Pattern

ID	REQUIREMENT
U2	The application shall allow customers to have access to current order status through a programmatic mechanism and through a user interface.
U3	The application shall enable a customer to access product catalog and sale information through a user interface and programmatically.

In both of these requirements, you could easily imagine clients using an event monitor to determine when their order ships or when your company has a sale on roasted beans. Supplying an Observer interface to the clients may allow you to push current information to them rather than simply acknowledging that your client will have out-of-date information. The previous user requirements are on an asynchronous business process and a business object collection, the two primary types of Web Services in your application (remember that the other types, business object and business process are heavily used from within the Web Services).

The Observer pattern primarily affects the interface to your Web Services. Physical tiers, presented in Chapter 13, "Exploring the Physical Tiers Pattern" affects how efficiently clients can use the Observer pattern. If clients do not get creative with how to leverage the Observer pattern, they may be unhappy with the results. Clients may not like the need to deploy a full Web Service to leverage your notification mechanism, and they may not think you have the right level of granularity of messages. Clients may also find that the complexity of your service environment is gradually increasing.

In addition to the Observer pattern, it is important you also supply an email- based notification mechanism and a usable Web interface that does not require sophisticated application writing styles. It may be some time before clients deploy Web Services or are sophisticated enough to take advantage of Observer pattern implementations .

Identifying Important Classes and Files in the Case Study

Table 11-2 contains the source files for the code listings in this chapter, as well as some of the related code.

Table 11-2: Sample Location

FILE	LOCATION	DESCRIPTION
ConcreteObservable.java	src\com\servicefoundry\ books\ webservices \ simpleexample\observable	Java-based Observable subclass that sends an event notification every second
ConcreteObserver.java	src\com\servicefoundry\ books\webservices\ simpleexample\observable	Java-based Observer implementation that plugs into ConcreteObservable
ObserverDemo.java	src\com\servicefoundry\ books\webservices\ simpleexample\observable	Driver program for simple Java Observer pattern implementation
ProductOrderManager.java	src\com\servicefoundry\books \webservices\processes	Concrete observable implementation in the Web Service paradigm
ProductOrderObserver.java	src\com\servicefoundry\ books\webservices\patterns\ observer	Client-side observer implementation used by ProductOrderManager to deliver event notifications
ProductOrderTest.java	src\com\servicefoundry\books \webservices\tests	Test program that connects ProductOrderObserver to ProductOrderManager

Using Ant Targets to Run the Case Study

Table 11-3 describes the targets to run for the Ant environment to see the programs and chapter samples in operation. Before running any samples, be sure you read and perform all of the install steps in the appendix.

Table 11-3: Ant Targets

TARGET	DESCRIPTION
testjavaobserver	Runs the Java observer program from Listing 11-1.
testwebserviceobserver	Registers the Observer Web Service to the Observable Web Service, as in Listing 11-5. The results display to the Apache Axis console window because the Observer implementation from Listing 11-2 simply uses the System.out facilities.