Understanding the Event Monitor Structure

An event monitor can take on a variety of structures. The one discussed in this section assumes that the event monitor is a component within a larger architecture. The event monitor serves other components within the architecture through the Observer pattern implemented in the Java language. The Observer pattern, as implemented in Java, gives a mechanism for allowing clients to register with a target object and thereafter receive events from the target when data changes. Chapter 11, "Implementing the Observer Pattern" discusses the Observer pattern and how it relates to Web Services in greater depth. For this chapter, you will look at the Observer pattern merely as a mechanism for allowing a client to have multiple interested components use a single instance of the event monitor.

Figure 10-3 illustrates the structure of the Event Monitor pattern. Event monitors are rarely generic enough to service any business object, business object collection, or business process. Instead, you create as much isolation as possible by creating an information snapshot that is replaceable at compile time. By doing so you can change quickly to service other targets or facilitate more rapid change if you become interested in different data.

Figure 10-3: Event monitor structure

Unfortunately, without the participation of the component designer for the target object ”in this case, the target Web Service (the business object, collection, or process) ”a high amount of customization goes into creating each event monitor. Companies that eliminate and ease the burden of creating customized event monitors make substantial profit from their tools. Typically, the event monitor is part of an end-to-end solution for integrating two applications, but event monitoring certainly is useful beyond this relatively limited tool domain. An example is a monitoring framework that scrutinizes device status. It is highly unlikely that hardware devices expose events for the exact needs of your software, especially in the event that the hardware device goes offline. For this scenario, an event monitor fits your needs to determine when a particular device goes offline.

Understanding the Components of an Event Monitor

The Event Monitor pattern employs several components spread across processes and physical computer systems. On one system, the target of the event monitor makes important information available that clients must monitor. The event monitor, residing in another process space, uses a proxy (in this case, an architecture adapter) to the target for contacting and retrieving information. The following interfaces and classes are typical in an event monitoring scenario:

EventMonitor: The EventMonitor class contains logic that interacts with one or more business objects to determine when an event of interest occurred in the business objects. This logic is typically custom built for each type of event that can occur in the target business objects. A copy of the latest data must be stored internally to the event monitor, in the InfoSnapshot , to determine what data, if any, changed from the last query of the target object. The EventMonitor class typically runs within its own thread, freeing it up to look for changes in the target object independent of the primary application thread. The EventMonitor class implements the Runnable interface required by Java to run in its own thread. The EventMonitor can facilitate multiple listeners to the events that it is watching for from the target business object. The Observable interface that the EventMonitor class extends is merely the Java language “supplied interface for the Observer pattern.

Observer: Components interested in changes to the target object implement the Observer interface. A class implementing the Observer interface can register with the event monitor through the observable interface that it implements.

InfoSnapshot: The InfoSnapshot class encapsulates the exact changes that a particular event monitor is looking for in a data set made available from the business object. An information snapshot is highly dependent and tightly coupled to the event monitor; however, it does slightly partition responsibilities to allow easier modification of the application. Because of this separation of code, the author of an EventMonitor class can just worry about interacting with and gathering data, and the logic for determining interesting changes can be programmed and changed separately.

BusinessObject: The BusinessObject is entirely out of the sphere of control for the event monitor. The target of the event monitor does not have to be a business object; it could just as well be a business object collection or a business process. In this book, the business object is a Web Service, but this pattern applies generically with the business object being a class or service in a different architecture.

Many of these classes are optional. For example, an event monitor used by a single component may not implement the observer/observable relationship and instead implement a proprietary interface between the event monitor and the interested component in the event monitor's architecture.

Understanding Event Monitor Collaborations

Collaborations between the involved components are relatively straight-forward. The EventMonitor class uses custom logic to interact with the BusinessObject Web Service or another basic object or process pattern. This interaction connects to the target business object and retrieves all of the necessary information to determine if a useful event occurred in the business object. The EventMonitor class takes the new information and gives it to the information snapshot that encapsulates the actual comparison logic. This separation of responsibility simplifies the coding of the event monitor and can help extend the event monitor to allow different policies for determining when an event occurred.

Clients in the EventMonitor class's architecture register with the event monitor through the event monitor's Observable interface. When significant events occur, the event monitor is responsible for delivering the events to the interested parties. Figure 10-4 shows the entire sequence.

Figure 10-4: Collaborations between design components

The application responsible for instantiating the event monitor uses the Runnable interface to dispatch the event monitor into its own thread. An event monitor does not have to have its own thread of control, but it typically does, allowing the application programmer independence from the wide performance variance that the target business objects may have. Figure 10-4 does not show this startup portion of the sequence diagram.