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.
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.
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.
Table 10-3 identifies the primary code discussed in this chapter, as well as related files of interest to you from the downloaded samples.
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. |
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.
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. |