Chapter 10: Exploring the Event Monitor Pattern

The previous seven patterns were studies in the Web Service architecture and the basic patterns of components that leverage the Web Service architecture. The remainder of the book, starting with this chapter, focuses on patterns for using Web Services and for enhancing the basic patterns to fulfill broader needs. The first pattern in the usage category, the Event Monitor pattern, has broader application than Web Services. As companies integrate systems, it is commonplace to use monitoring as a mechanism to determine whether a data- or process-centric event occurred in a system.

An event monitor is, essentially , an event mechanism that relies on client implementation without server-side component participation. This makes the Event Monitor pattern an effective way to integrate applications without interfering with existing components. The Event Monitor pattern is one of the most basic patterns in this book. It is a client-side pattern designed to leverage existing server-side components rather than a pattern for designing new server-side components.

Seeing Event Monitors in Practice

Programmers often construct applications that contain business information but give no efficient way for a client to monitor changes in the information. Further, in cases where you implement the Publish/Subscribe design pattern (discussed in Chapter 12, "Implementing the Publish/Subscribe Pattern") or a related event mechanism, it is frequently the case that the following is true:

• The architecture of a client interested in the changes is a different architecture than the publish/subscribe mechanism supports.

• The granularity of the published events relating to the business information does not meet the client's needs.

An event monitor is a client-side design pattern that programmers implement outside of the scope of the server-side component. The event monitor polls the information in a business object, collection, or process for particular state changes and then notifies any components that registered with the event monitor.

Integrating Enterprise Applications

The most common scenario illustrating the usefulness of an event monitor is an Enterprise Application Integration (EAI) scenario. In EAI scenarios, heterogeneous applications get integrated to appear as seamless as possible. For example, if a user enters data for a customer using one application, that data should appear in other applications that the company uses. Even better, a user should be able to access all applications and data with a single user experience. Basically, integrating heterogeneous applications involves making more than one application work together as a single, cohesive implementation.

Often, the first task in making applications appear seamless is to integrate their databases. For example, two applications contain customer information that should be coordinated between the integrated systems. After the integration process, users will be able to enter customer information in one application and have the data in the second application automatically update. In a system that is not integrated, users must enter customer information in two separate applications.

Databases rarely have effective publish/subscribe mechanisms attached to them. Using the Event Monitor pattern, you can produce a mechanism that moves data from one database to the other as changes occur; this is termed near-real-time data transfer, as shown in Figure 10-1. The event monitor watches both databases, and when a change occurs in one, the event monitor inserts a similar change into the second database.

Figure 10-1: Polling databases for change

Scenarios like those in Figure 10-1 occur frequently in complex integration strategies. Often, rather than using a single component, the event monitor posts the change onto an event bus that, in turn , allows any number of listeners to receive the change and convert it to the format necessary for their own components.

Using Web Services and Event Monitors

Clients of Web Services have many opportunities to leverage an event monitor. Event monitors are popular in Web Services for several reasons:

Standardization (or lack thereof): Because there is no standardized event mechanism in Web Services, clients of Web Services must construct their own way to determine when data changes. An event monitor is a simple mechanism that a client controls for detecting events.

Appropriate level of granularity: Client architectures, the data that clients expect to monitor, and the level of event granularity for Web Services are extremely unpredictable when deployed for general usage on the Internet. As a result, the server component creator cannot easily predict what type of events clients require. For these reasons, a client will often have to construct their own mechanism for detecting the appropriate events.

Easy integration: Businesses often deploy Web Services into EAI scenarios as mechanisms to access data and processes in an existing application. In these cases, the Web Service serves as a conduit to one or more database table or process. Despite the Web Service interface, clients still require a mechanism to determine when particular events occur in the data residing in the application. Event monitors are easy to add without intruding on code already deployed into a client environment.

In a Web Service environment, a client is the most likely user of an event monitor. You will likely find many scenarios where a partner gives you a Web Service interface or you find an available Web Service with data or processes that you require, and you build a client around that Web Service. Consider the case of a bank that wants to provide partners with a mechanism for checking home mortgage rates. Rather than architecting a full-blown event strategy, the bank's first version of the Web Service will likely contain an interface for entering the term and type of mortgage and capabilities for returning a rate for the mortgage. It would be difficult for you to tell the bank to modify its Web Service. As a result, you would poll the mortgage service on a regular interval so that you can track the rate changes.

With Web Services, you would write the client-side event monitor in the native client architecture, such as the object-oriented Java environment, and continuously poll and retrieve updates from the target Web Service, as shown in Figure 10-2. In the figure, the event monitor implements a client-side notification mechanism so that multiple clients can use the same event monitor.

Figure 10-2: Web Service polling structure

This pattern applies to just about any Web Service domain. For example, you could use the event monitor to determine when changes occur to customer data in a Customer Relationship Management (CRM) application. The application with the event monitor could then synchronize its own data with the external CRM application's data.