Users of WebSphere Business Monitor (Monitor) sometimes tell us that its event processing algorithm is difficult to grasp. Mostly they seem puzzled by the purpose of filter expressions and correlation predicates, by the various event delivery options, and by the way in which updates are driven in a monitoring context.
In this article, I'll give you a behind the scenes look at these concepts. I won't go over many of the finer points of the Monitor programming model like triggers, timers, and nested monitoring contexts, but will focus simply on the basics of event processing.
I've also provided a simple slide show for download that shows, through a simple storyline, the path an event takes as it's processed by Monitor.
At the core of Monitor are observer objects. One observer object is created for each entity you want to monitor. Monitored entities can be tangible, such as a device, server, or vehicle, or abstract, such as process execution or sales performance. The observer object subscribes to events that report any state changes in the monitored entity, and then updates its own state based on information in those events.
An Monitor observer object is called a monitoring context or MC because the information it collects provides the context for monitoring a specific entity. The data fields in an MC are called metrics because they typically represent measurements of business-relevant information.
For example, let's say a limo company wants to monitor its fleet of cars. The company might allocate an MC for each trip when it begins. This context can be updated with information, such as passenger pick-up time, traffic jams, and passenger drop-off time, based on events received from limos on the road. An MC for a trip might contain metrics for trip duration, pick-up and drop-off delays, a customer satisfaction index derived from these metrics, average driving speed, and so on.
Extending their monitoring capabilities, the limo company might create MCs for their drivers with metrics for things like punctuality, trips per month, average customer satisfaction, or create MCs for the cars, with metrics like gas mileage, next scheduled service, and so on. These MCs would be the observer objects for the drivers and the vehicles..
The metrics and event subscriptions of an MC are defined by monitoring context definitions. Just as an MC is a special-purpose object, its definition is a special-purpose class which defines the structure and behavior of its instances.
Now that you understand the basic concepts and terminology, let's see how it all works.
There are three steps to processing an event:
- Filtering - What kind of event is this?
- Correlation - Which MCs are interested in this event?
- Updating the MC - Which metrics are updated by the event, and how?
Each MC subscribes only to certain kinds of events.
For example, in the limo company, the trip MCs might subscribe to events that report trip dispatching, passenger pick-up, passenger drop-off, heavy traffic, and car incidents. The trip MC definition would need to define five event subscriptions, one for each kind of event.
An event subscription contains a filter, which is a Boolean expression that evaluates to true for events it subscribes to and to false for all other events. The only rule for defining a filter is that it must let events of the desired kind pass and block all others. For performance reasons, filters should be kept as small as possible, in other words, they should be just complex enough to identify a particular kind of event reliably among the variety of expected events.
If a subscribed event contains an xsi:type
attribute identifying its payload, and events for different occurrences
have different types, testing this attribute may be all that's needed. If,
on the other hand, a generic event is used to report occurrences of
different kinds, which can only be determined by examining further event
content, the filter must test additional fields.
In the limousine example, if the cars report trip status using an event
whose payload type is always limo:Trip (where
limo represents a namespace) and dispatch,
pick-up, and drop-off events are distinguished using an
event nature field, the
event nature field will need to be tested along
with the xsi:type attribute to determine what
kind of event has arrived.
After an event has passed a subscription's filter, the subscription's correlation predicate is evaluated for each instance of the MC definition. Correlation predicates typically compare some key value in the event , such as a unique trip identifier, with a metric containing the same key. If a matching MC is found, that MC may receive the event for further processing. If not, a new MC context may be created.
But what if that's not what you want? Say, for example, a passenger pick-up event arrives and no matching MC is found. In this case, you might not want to create a new MC, but instead raise an error condition indicating that the "car dispatched" event (which should have occurred first and created the MC) was not received. Similarly, if a "car dispatched" event arrives and correlation processing finds a matching MC, this indicates that a "car dispatched" event for the same trip has already been received. Again this represents an error, and delivering the duplicate dispatch event to the already existing context would not be what you'd want.
As you can see, it's important to be able control the event correlation algorithm. You can do this by configuring event delivery settings. Each event subscription has three settings, which cover the cases of zero, one, and multiple MCs fulfilling the correlation predicate.
The table below shows all possible event delivery settings.
Event delivery settings
| Zero matches | One match | Multiple matches |
|---|---|---|
| Ignore | Ignore | Ignore |
| Treat as error | Treat as error | Treat as error |
| Create new MC | Deliver to the (single) matching MC | Deliver to any matching MC |
| Roll back all changes and retry processing this event later | Deliver to all matching MCs |
After correlation processing has identified the MCs for event delivery, the event updates those MCs.
To understand how that works, you can think of an MC as a spreadsheet, whose cells represent the metrics. For each metric, the MC definition defines one or more maps that update its value. The maps are like spreadsheet formulas. A map may depend on no more than one vent subscription, and potentially on other metrics
When an event is delivered to an MC, all maps that depend on that event are run automatically, and their target metrics are updated with the results. Further updates are then processed in a cascading fashion, just like in a spreadsheet: maps that depend on the updated metrics are run, then maps that depend on their targets, and so forth. The cascade must terminate because the dependency graph defined by the maps is not allowed to have cycles. For example, if metric B depends on metric A, then metric A must not depend on metric B.
If you're still having a little trouble with some of the concepts, or you'd simply like an entertaining visual review of how the process works, take a look at the "Event processing" slide show provided with this article. This slide show steps you through the process I described in this article using simple graphics and an easy-to-understand story line.
I hope this article and the accompanying slides have given you a better understanding of the concepts behind event processing in WebSphere Business Monitor, as well as a clearer picture of how events are actually processed in a real-world scenario.
| Description | Name | Size | Download method |
|---|---|---|---|
| Slide show demo | epdemo.pdf | 299KB | HTTP |
Information about download methods Get Adobe® Reader®
-
WebSphere
Business Monitor product information:
Get complete product information, including features and benefits, system
requirements, and more.
-
WebSphere
Business Monitor Information Center:
Get complete product documentation.
-
developerWorks BPM zone:
Get the latest technical resources on IBM BPM solutions, including
downloads, demos, articles, tutorials, events, webcasts, and more.
Joachim (Jim) H. Frank is a Senior Software Architect with IBM. He provided technical leadership for the design and development of WebSphere Business Modeler and WebSphere Business Monitor. You can reach Jim at jhfrank@us.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
