Preparing to Implement Event Monitors

Implementations of the event monitor vary widely. The following are a few guidelines for building an effective event monitor:

Apply the Observer pattern to the event monitor so that more than one observer can use a single event monitor: This is perhaps the biggest performance boost you can achieve in terms of network bandwidth and processor performance. Often, many parts of an application will be interested in changes to a set of data from the original business entity. Allowing a single event monitor to query the business entity will substantially reduce the amount of overhead on both the system with the event monitor as well as the system in which the business entity resides.

Allow control of polling frequency: It is difficult to predict how a component programmer may use a component such as an EventMonitor class beyond its original conceived purpose. Further, it is difficult to predict an application's requirements in terms of desired event frequency balanced with performance. For these reasons, you will want to allow configuration of the EventMonitor class's polling frequency. Consider the case where a piece of data changes once every second. Over the course of a day, observer-based systems would process 86,400 data transactions in each system. This is useful if the client requires the data immediately upon change. However, clients require only periodic updates in many scenarios. For example, rather than getting individual event notifications for stock that is depleted, why not receive out-of-stock events once per day before the application places the daily replenishment order? In this case, 86,399 more event notifications took place than were necessary. Changing the monitoring frequency to once every 24 hours avoids overhead.

Minimize the amount of data transferred: Creating a minimal set of data to be queried and returned during a polling operation can save network bandwidth and create better performance for the event monitor. For example, rather than requesting the entire state of an object, the application should simply request the properties on which you rely. Consider the example of an order with several line items. In some cases, each line item ships to a customer separately, in which case the customer wants notification on each shipped line item. This is a fine- grained mechanism that says that each time an order line switches to Shipped , you send a notification. On the other hand, clients also want a final ship notice when all order lines have shipped. For this second event, you need a custom granularity that waits to fire until all lines are marked Shipped . This second mechanism could also be used to mark the overall order as Shipped and do any additional processing that must occur to close the order and put it in the books.

It is worth talking about some of the dangers of using an event monitor as well. There are many cases where clients must use an event monitor but they do not consider all of the potential consequences of using an event monitor. The following are some of the dangers:

Potential for missed changes: There is a real danger of "missing" changes that occur in the BusinessObject class that is being observed by the EventMonitor class. No matter what frequency an event monitor uses to poll a process or object, multiple changes can occur to the data within the BusinessObject during the given polling period. The creator of an event monitor needs to consider this possibility. If missing a data change is catastrophic to the observer, an event monitor is not a good option. The only exception is if the event monitor can guarantee that the frequency of the polling is higher than the frequency with which updates can occur to the data.

Near-real-time mode is not real-time mode: A system implemented using event monitoring can appear to perform and operate quickly and in near-real-time mode. It is important to remember that this near-real-time operation is not the same as real-time operation. Event monitoring is simply not useful for systems that require real-time operation and reaction, such as medical devices. Fortunately, near- real-time event detection is more than adequate for most business systems.

Processor consumption: Architects and designers often overlook the topic of performance and processor consumption with respect to event monitoring. The practice of deferring these topics can be catastrophic when you consider the impact of deploying event monitors. Consider the case of a single event monitor polling each second and consuming a processor for five milliseconds . Consider a system where you deploy 200 of these event monitors and you will quickly learn what it means to have a system halt from overutilization. Further, this simple analysis only took into account the processor where the event monitors reside. To be complete, you would have to consider the processor utilization on the target system to fulfill the requests . A good strategy to mitigate the processor impact would be to consolidate event monitors using observer mechanisms for events that occur over the same data. This way a single event monitor could facilitate more than one client component, easing the burden of polling and comparing data. There is simply no substitute for thinking about performance up front.

Bandwidth consumption: Just as event monitors consume processor and cause performance bottlenecks, event monitors also chew up network bandwidth as they move state changes around a network. To consider the ramifications on network bandwidth, consider data requests that pass 1 kilobyte (KB) of data in an Extensible Markup Language (XML) document back and forth on each request. Now consider 200 of these requests occurring in a second, passing 200KB of data each second. This does not completely swamp today's 1 Megabyte (MB) or 10MB connections, but it certainly puts a dent in them, especially a 1MB network. In other words, attempt to minimize the amount of data transferred across the network on each polling cycle.