Leveraging Event Monitors in the Case Study


Leveraging Event Monitors in the Case Study

The P.T. Monday Coffee Company application is interesting in that you are defining the end-to-end interfaces and implementations for all parties involved. With this type of leverage, it is unlikely that you will use an event monitor in the application. The primary location for the event monitor will come either when outside applications attempt to use your services or when you attempt to integrate your business with a company over which you do not have leverage.

In the first case, it is difficult to predict all of the places where explicit registration and notification are necessary for every potential customer. For example, a future customer may be interested every time your company updates the product catalog or individual prices for products. Rather than trying to overdesign your Web Service for these infrequent uses, you have to rely on exposing enough information to allow clients to locate their own interesting data and data changes. It is safe to say that if you build a popular set of Web Services, you will not be able to predict every way that someone wants to leverage your information. One way to determine locations that client may use event monitors on your services is to look at your requirements, as shown in Table 10-1. Any time there is information that changes, a customer may poll this information regularly, perhaps several times in a day.

Table 10-1: Requirements Identifying Places That Clients May Use Event Monitors

ID

REQUIREMENT

B1

The application shall have the ability to integrate into the reseller's value chain.

U2

The application shall allow customers to access the 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.

F3

The application shall provide programmatic access to submit orders, observe the fulfillment process, and pay invoices.

The second case when you may use the event monitor in your own application is to monitor the Web Services from another company. It is highly likely that you will eventually integrate with a company that does not adhere to your own technical model definitions and that does not surface all of the interfaces you need. When you reach this point, you will have to employ an event monitor to look for changes in the Web Services you leverage. Again, you can look at your own requirements to determine locations in your applications that you may have to employ an event monitor. Table 10-2 identifies a few of these requirements that should raise a red flag. For example, for requirement B2, you may want to have an event monitor that watches for changes in prices of your bean suppliers' catalogs, thus always maintaining a low price for your supply.

Table 10-2: Requirements Identifying Places That You May Use Event Monitors on External Services

ID

REQUIREMENT

B2

The application shall have the ability to integrate bean suppliers into the company's value chain.

F9

The inventory management system shall automatically request additional beans from suppliers based on management-configured parameters for the definition of low supplies and grower preferences.

Just as all of the requirements in Table 10-2 identify places where you may employ an event monitor in your application; they also identify places where you may create or use more robust, server-side event mechanisms. The next two chapters ”Chapter 11, "Implementing the Observer Pattern," and Chapter 12, "Implementing the Publish/Subscribe Pattern" ”go into more details on planned event mechanisms.

Identifying Important Classes and Files in the Case Study

Table 10-3 identifies the primary code discussed in this chapter, as well as related files of interest to you from the downloaded samples.

Table 10-3: Sample Location

FILE

LOCATION

DESCRIPTION

ProductOrderEventMonitor.java

src\com\servicefoundry\books\ webservices \patterns\eventmonitor

The code from Listing 10-3 that monitors a remote Web Service from within a thread.

OrderStatusInfoSnapshot.java

src\com\servicefoundry\books\webservices\patterns\eventmonitor

Code to compare data between two snapshots of order information. The ProductOrderEvent Monitor class uses this class to determine if any significant data changed between order snapshots.

Using Ant Targets to Run the Case Study

Table 10-4 gives 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 10-4: Ant Targets

TARGET

DESCRIPTION

testeventmonitor

Runs the client-side event monitor code.

changeorderstatus

A mechanism to change the order status. The event monitor that started using the testeventmonitor Ant target will react appropriately to the changed status.




Web Service Patterns
Web Services Patterns: Java Edition
ISBN: 1590590848
EAN: 2147483647
Year: 2003
Pages: 190

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net