![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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 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 every entity you want to monitor. Monitored entities can be tangible, such as a device, server, or vehicle, or abstract, such as a process execution, a package delivery, or a sales cycle. 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 observer object used by Monitor is called a monitoring context or MC because the information it collects provides the context for monitoring an observed entity. The data fields in an MC are called metrics because they typically represent measurements of business-relevant information about this entity.
For example, let's say a limo company wants to monitor its fleet of cars. The company might want Monitor to create a monitoring contextf for each trip when it begins. This context can be updated with information about the trip, such as passenger pick-up time, traffic jams, and passenger drop-off time, based on events received from limos on the road. It might contain metrics for trip duration, pick-up and drop-off delays, a customer satisfaction index derived from these, average driving speed, and so on.
Extending their monitoring capabilities, the limo company might define MCs for their drivers with metrics for punctuality, trips per month, average customer satisfaction, and so on, or for their cars, with metrics like gas mileage, next scheduled service, and so on. These MCs would be 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 the kinds of events that pertain to the entity it monitors.
In the limo company example, 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 have 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 among the variety of expected events.
For example, if an event contains an xsi:type
attribute identifying its payload, and different kinds of events have
different types, testing this attribute may be all that's needed. But if
a single generic type of event is used to report occurrences of
different kinds, which can only be determined by examining the event
content, the filter must test additional fields.
In the limousine example, if the cars always report trip status using an event
whose payload type is limo:TripStatus (where
limo represents a namespace) and dispatch,
pick-up, and drop-off events are distinguished through an
event nature field, the
event nature field will have 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, its correlation predicate is evaluated for existing MC. 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 an MC for the same trip is found, this would be unexpected and indicates an error. Again, you would want to raise an error, and not deliver the duplicate dispatch event to the already existing context.
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 following table shows those 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 MCs for event delivery, their state is updated from the content of the event.
To understand how that works, you can think of an MC as a spreadsheet, whose cells are the metrics. For each metric, the MC definition defines one or more maps that set its value. The maps are like spreadsheet formulas. A map may depend on an event subscription.
When an event is delivered to an MC, all maps that depend on the receiving subscription are run, 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 update their targets, and so forth. The cascade will always 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 cannot depend on metric B.
If you found this walk-through somewhat dry, or you'd simply like an entertaining visual review of what you've learned, 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.
| 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.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
