Browse Prior Art Database

Externalizing the WebSphere Business Monitor Programming Model Disclosure Number: IPCOM000166793D
Original Publication Date: 2008-Jan-23
Included in the Prior Art Database: 2008-Jan-23
Document File: 2 page(s) / 43K

Publishing Venue



This disclosure describes the programming model for defining monitor models. It describes the elements that made up a monitor model and how these elements are implemented in EJBs that receive incoming events, process the events, calculate metrics base on rules that are defined in the monitor model, and then persist the metric values in the database. In the current 6.0.1 release of WebSphere Business Modeler and WebSphere Business Monitor, the programming model for defining the monitor model is a close one. This has introduced a large number of semantic problems as to how to interpret this black box that is captured in a non-readable XMI format. In addition, it is also impossible to support external tools or other ISVs that want to enable their applications for monitoring. By externalizing the monitor model as XML with a well-defined schema and semantics, we lay the ground work for future standard work in the emerging BPM/BAM market.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Externalizing the WebSphere Business Monitor Programming Model

At a high level, a monitor model can contain 1 to N number of Monitor Contexts (MC). One can define a Monitor Context for each entity that you want to monitor. For example, in the process scenario in picture 1, you can define a Monitor Context MC1 for the process SimpleClaim and one Monitor Context for each task (e.g. MC2 for ReceiveClaim).

In the BAM scenario, you can define a Monitor Context for each of the sub-system that you want to monitor as shown in the 2nd picture
(e.g MC4 for the Finance System).

Within a Monitor Context, you can define the following elements: Inbound Events, Outbound Events, Metrics, Triggers, Counters and Stopwatches. Here we give an example and a short description of each of the monitor elements. We then explain how these elements are realized in the EJB implementation.

Inbound Events

The inboundEvent tag defines an event that will be processed by this Monitor Context. The attributes define the semantics associated with the inbound event, for example, to create a new MC instance if there is no existing MC instance for this particular event.

<inboundEvent displayName="ClaimEvent" id="ClaimEvent"


oneCorrelationMatch="raiseException" type="ClaimEvent">

<correlationPredicate expression="ClaimEvent/exte...