Seeing the Observer Pattern in Practice | Web Services Patterns: Java Edition

There are many examples of the Observer pattern in practice. Java programs rely heavily on the pattern and Web Service implementations are beginning to use it to create more dynamic and timely interactions between services.

In Java, data objects are frequently implemented with the Observer pattern to facilitate user interfaces. As data changes, the data objects fire events to interested listeners, the observers. The observer then refreshes client user interfaces to stay in sync with the underlying data. Without the Observer pattern, or a similar event mechanism, a user must manually refresh a data view, much as an event monitor polls a data object looking for changes.

The Universal Description, Data, and Discovery (UDDI) version 3 specification recognizes the usefulness of the Observer pattern as well. In the specification, clients register to receive event notifications based on changes to particular business entities, services, templates, or models. Without the event pattern, users of UDDI data must occasionally check the UDDI registry for changes to elements on which they rely.

In the case study, the P.T. Monday Coffee Company application, you want to do everything you can to ensure customers have the latest information. Consider a restaurant that uses two separate coffee bean suppliers. In the case that both suppliers can fulfill a large order, the restaurant may purchase coffee beans based on price. You may have harvested this price from your Web Service earlier in the week, depending on the polling cycle of the event monitor. By allowing your partners to use an observer rather than an event monitor, they could possess the latest price data, an invaluable tool to a dynamic business. Further, managers at the restaurant can be constantly apprised of the progress of their order if the restaurant application programmers choose to use your Observer pattern implementation.

Understanding Data Models in Java and the Observer Pattern

The Java class libraries contain an implementation of the Observer pattern used as the basis for simple event models in Java classes and components often associated with data objects. This pattern implementation is useful in single-process Java programs. Objects that want to implement a mechanism for delivering notifications to observers extend the java.util.Observable class. Clients who want to register for events from the Observable class implement the java.util.Observer interface. The addObserver method on the Observable class, inherited by the concrete observable implementation, takes registrations for notifications using a reference to an Observer implementation as a target to call when an update occurs. Figure 11-1 shows the Java classes that implement the Observer pattern: the Observer and the Observable classes. Also in the diagram are examples of extensions; ConcreteObserver implements the Observer interface, and ConcreteObservable extends the Observable class.

Figure 11-1: Java observer implementation class diagram

In the Java implementation, the Observable class handles maintenance of observers that register with the Observable class. Further, the Observable class handles notification of the observers when a subclass changes the class and properly uses the setChanged method to indicate that a change occurred in the concrete implementation class.

An observer that wants to receive event notifications from a subclass of an Observable must implement the Observer interface. This implementation must provide a concrete update method that the observable calls when an update occurs to the target object.

Note that the ConcreteObservable class implements the Runnable interface, as the class must run in its own thread to deliver notifications. The implementation of the class pauses for a second and then delivers a notification to all registered observers. The ObserverDemo class is a simple driver program that registers the observer, an instance of ConcreteObserver , with the observable, an instance of ConcreteObservable . Listing 11-1 shows the ObserverDemo driver program.

Listing 11-1: Java-Based Observer Pattern Driver Program

 public class ObserverDemo {     public static void main(String args[]) {         ConcreteObservable observable = new ConcreteObservable();         ConcreteObserver observer = new ConcreteObserver();         observable.addObserver(observer);         Thread t1 = new Thread(observable);         t1.start();         Object o = new Object();         try {             synchronized(o) {                 o.wait();             }         } catch(Exception e) {             e.printStackTrace();         }     } }

You will see similar code to Listing 11-1 in the "Implementing the Observer Pattern Using Web Services" section. Listing 11-1 simply instantiates the ConcreteObserver and ConcreteObservable classes and creates and starts a thread with the observable object instance running in it. The program registers the observer with the observable and then waits for notifications to arrive .

The Java Observer pattern implementation has a few limitations. One is that the pattern is strictly a single-process implementation. Another problem is that the Observable implementation is a class, not an interface. With the Java single-inheritance model, this implementation is extremely limiting. Often, programmers end up implementing their own Observable interface rather than tying their class to the Observable class at the root.

Using UDDI Version 3

Version 3 of the UDDI specification introduces the Observer pattern to UDDI directory implementations. The pattern supports the ability to notify interested parties of changes that occur to various directory entries. This feature allows clients to easily track a variety of registry activities, such as the following:

Periodic updates of technical models (tModels) that represent service interfaces: The effect of a change to a tModel may be a required change to a program owned by your company.
Information updates about contacts at a company: This type of notification is for helping maintain current contact information for individuals at a company or up-to-date mailing information.
The availability of registered companies for particular industries: In this case, your application could monitor a UDDI registry to find growers and roasters that automate their supply chain.

Before the introduction of the pattern to UDDI, you had to locate changes to directory entries through a manual process or through ”you guessed it ”an implementation of the Event Monitor pattern.

Several pieces of the UDDI observer implementation make it particularly interesting. One such trait is its ability to send change notifications to an email address rather than an HTTP location. For many entities, UDDI entries will not change frequently, so email is a reasonable solution for change notification. With this mechanism, clients can monitor interface changes or business information changes without having to leave a Hypertext Transfer Protocol (HTTP) port open .

Another interesting trait of the UDDI subscription is the registration mechanism itself. A subscriber gives UDDI a binding key that can identify either Web Service binding information or an email address for notifications. Although Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP) inherently support multiple transport protocols, the UDDI event specification is an interesting application of the binding information to allow single subscription methods to service both HTTP interfaces and the Simple Mail Transport Protocol (SMTP) interfaces.

At the time of writing, no version 3 UDDI implementations were available. The versatility of the approach may prove to be an exceptional model for implementing state-based notifications. Reading the UDDI version 3 specification and understanding the new notification mechanism is well worth your time because it is one of the first Web Services “based, standardized event notification mechanisms.