Leveraging PublishSubscribe in the Case Study

Leveraging Publish/Subscribe in the Case Study

The P.T. Monday Coffee Company application now has three different event patterns to choose from for helping clients access current and timely data: the Event Monitor pattern, the Observer pattern, and the Publish/Subscribe pattern. Each has advantages and disadvantages. Over the years , I have grown to appreciate the loose coupling and flexibility inherent in a publish/subscribe mechanism. The ability to separate concerns for optimal delivery of events to clients is also a heavy advantage to the publish/subscribe technique of using a generic event service.

On the other hand, the Observer pattern creates better semantics for clients and helps to compartmentalize the application. Basically, someone browsing products and desiring notifications when the product catalog gets updated has to understand only a single Web Service, instead of two plus a set of topics.

Also, keep in mind that you are not limited to a single event pattern for your application. The P.T. Monday Coffee Company will use a combination of the Publish/Subscribe pattern and the Observer pattern throughout the application. The former sends events that are not associated with a particular Web Service, and the latter allows clients to access events on a particular Web Service or business object used by a Web Service.

In your own applications, it is worth weighing the benefits of one pattern against another. In the end, both patterns achieve similar goals but have different advantages and disadvantages. One, the Publish/Subscribe pattern requires a client to know about multiple Web Services; the other, the Observer pattern, is not as flexible with the event originator and requires more code. Both techniques fit well into a Web Service paradigm.

Identifying Important Classes and Files in the Case Study

Table 12-1 shows the primary code discussed in this chapter that you should browse in the downloaded source code.

Table 12-1: Sample Location

FILE	LOCATION	DESCRIPTION
SubscriberTest.java	src\com\ servicefoundry\ books\ webservices \ tests	This is the subscriber service implementation as shown in Listing 12-2. This service implementation gets deployed using Apache Axis and lies dormant . A second registration step must take place to register it after the Web Service is active; this subscription registration is contained in the static main program of this listing.
Publisher.java	src\com\ servicefoundry\ books\webservices\ tests	The program that publishes events to the event service, as shown in Listing 12-3.
EventService.java	src\com\ servicefoundry\ books\webservices\ eventservice	The event service implementation as shown in Listing 12-1.

Using Ant Targets to Run the Case Study

Table 12-2 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. Like the programs themselves , this sample evolves over the next few chapters, so there are some remaining concepts before you understand the whole test program and Web Service implementation.

Table 12-2: Ant Targets

TARGET	DESCRIPTION
registerwitheventservice	This registers the subscribing Web Service, deployed via Apache Axis, with the EventService Web Service. You saw the registration code in Listing 12-2.
publishtoeventservice	This publishes an event to the EventService Web Service. Assuming that a client is running and registered for the proper event topic (hard-coded in the programs), the event will appear in all registered clients.