Overview

This article contains a brief overview of the IBM® Common Event Infrastructure (CEI). The CEI is a set of modular event processing components that deliver functions such as event transport, event-bus distribution, event persistence, event subscription, event updates, and event queries. The CEI is a technology that you can embed in solutions or products that require these functions.

The CEI uses the IBM Common Base Event specification for its functions. The CBE was submitted to OASIS last year and is under reviews by the Web Services Distributed Management Technical Committee. It also was submitted and accepted by the Eclipse Hyades Open Source Project. The CBE model focuses on consistent quality and content of the data in events. The combination of a shared data representation format for the events and a shared infrastructure for handling the events enables interactions between systems and applications that would be difficult and inefficient otherwise.

Back to top

Architecture

The individual components of the CEI technology have been carefully implemented to leverage the benefits of being hosted in a WebSphere® / J2EE operational environment, and to make those benefits available to the exploiters of the CEI technology.

The CEI Architecture Overview below (Figure 1) illustrates the main building blocks of the CEI and the main interaction points with external applications.

Table 1 contains a simple definition for each of the components seen in Figure 1.

Event selector language

CEI components must be able to classify events in order to process event streams originating from event sources or being delivered to event consumers. Given the XML schema defined in the CBE specification, the syntax of choice for selection expressions across events is XPath, the W3C standard for addressing parts of an XML document. XPath expressions are used in CEI configuration tasks and on API calls, as follows:

• CEI configuration associates XPath expressions with an event group, a key concept in the classification of events in the system. For instance, a system administrator may define an event group called "High severity insurance claims" and define it with an XPath expression. Whenever an event matches the XPath expression associated with an event group, the event is said to be part of that event group.
• The Event Filter plug-in in the Event Emitter uses XPath expressions to determine which events should be transmitted to the Event Bus.
• The Event Access component allows queries by event groups, which are associated with an XPath expression.
• An Event Consumer can use XPath expressions on queries by event groups to further filter the results of the query.
• The Event Distribution component compares event information to the XPath expressions associated with each event groups to determine the JMS destinations for event notifications.
• The Notification Helper component uses XPath expressions to further filter events coming through JMS destinations published by the Event Distribution component. As described in the JMS specification, a destination can be either a topic or a queue.

As an example of relationship between XPath expressions and CBE events, assume that an application must retrieve all critical events for insurance loss claims for the customer, Enterprise ABC. In CBE-speak one must represent: all that have critical severity and an extended data element called customer under the extended data element loss_claim and where the value of the element is Enterprise ABC. The XPath expression, based on CBE model, would be:

CommonBaseEvent[@severity=50 and 
	extendedDataElements[@name=’loss_claim’]/children[@name='customer' and 
	values='Enterprise ABC']]

Any event with the following constituency would match the above expression:

<CommonBaseEvent ... severity="50">
	...
    <extendedDataElements name="loss_claim"> 
	...
        <children name="customer" type="xs:string"> 
            <values>Enterprise ABC</values>
        </children>
        ...
    </extendedDataElements>
    ...
</CommonBaseEvent>

Back to top

Common Event Infrastructure SDK

The easiest way to get started with the CEI in your development environment is to download the CEI SDK and go through its samples and code examples. You will also need WebSphere Application Server 5.1 and can download a trial version.

The SDK contains a detailed Developer's Guide, Javadocs, and code samples; but here is a quick view of the steps required to create an event source or an event consumer for the CEI

Note that the SDK reflects the CEI Technology Preview version shipped in WebSphere Business Integration Server Foundation 5.1. The production version, planned to be shipped in the near future, will incorporate the following additional features not available in the technology preview:

• Queries based on extended data elements of an event
• Distribution of events to JMS topics and queues
• Event catalog
• Service provider API's for Event Filter plug ins
• Service provider API's for Event Data Store plug ins

Creating an event instance

Before an event source submits an event to the CEI, it must first create an event instance and populate its contents with the relevant information.

You will first need an event factory to create empty event instances that can be later populated according to the CBE specification. Listing 1 illustrates how to achieve this task. The complete source code is available under the docs/tutorials/examples directory of the SDK.

// The first step is the lookup for an event factory from a 
// JNDI namespace.
Context jndiContext = new InitialContext();
EventFactory eventFactory =
       (EventFactory) jndiContext.lookup("com/ibm/events/EventFactory");

// Creating an event with an extension name.
CommonBaseEvent event =
     eventFactory.createCommonBaseEvent("Tutorial_Event_Type");
event.setCreationTimeAsLong(System.currentTimeMillis());

// Setting optional fields
event.setSeverity((short) 10); // information
event.setMsg("Common Event Infrastructure Tutorial");

// Setting the mandatory situation description for the event.
Situation situation = eventFactory.createSituation();
situation.setCategoryName(Situation.REPORT_SITUATION_CATEGORY);
situation.setReportSituation("INTERNAL", "Succeeded");
event.setSituation(situation);

// Setting the mandatory component identification for the event source
event.setSourceComponentId("Event Source",
                   "source.EventSource",
                   "createEvent()",
                   "http://www.ibm.com/namespaces/autonomic/Tivoli/Samples",
                   "Sample",
                   "unknown",
                   "hostname");

// Setting Common Base Event version
event.setVersion("1.0.1");

Submitting an event

Once an event instance is populated, an event source should use the Event Emitter library to submit the event to the CEI.

Listing 2 illustrates how to achieve this task. The complete source code is available under the docs/tutorials/examples directory of the SDK.

// The first step is the lookup for an event factory from a JNDI namespace.
Context jndiContext = new InitialContext();
EmitterFactory emitterFactory =
  (EmitterFactory) jndiContext.lookup("com/ibm/events/configuration/emitter/Default");

// The next step is the creation of an event.
CommonBaseEvent event = createEvent();

// Now you use the factory to create an instance of an event emitter.
Emitter emitter = emitterFactory.getEmitter();

// Now you send the event to the CEI server using the emitter session.
String eventId = emitter.sendEvent(event);

// Once the event has been sent, the emitter session can be closed.
// You may reuse the same session to send more events before closing it.
emitter.close();

Querying an event

An event consumer may chose different mechanisms to access event data submitted to the CEI.

The simplest mechanism is to query the event data using the Event Access component. This interaction follows the traditional Enterprise Java Beans (EJB) programming style, and is illustrated on Listing 3.

// The first step is the lookup for a J2EE home interface for the 
// Event Access interface.
Context jndiContext = new InitialContext();
Object objref = jndiContext.lookup("ejb/com/ibm/events/access/EventAccess");
EventAccessHome eventAccessHome = (EventAccessHome)
    PortableRemoteObject.narrow(objref, EventAccessHome.class);

// The second step is the creation of an event access stub
EventAccess eventAccess = eventAccessHome.create();

// Now you can query the events. You'll retrieve all events that are part of
// "All events" event group and that have a severity greater than 30.
CommonBaseEvent event = eventAccess.queryEventByEventGroup("All events",
                                      "CommonBaseEvent[@severity > 30]",
                                      true);   // ascending order

Content completion handlers

As you learned in Creating an event instance, an event source looks up an event factory from a JNDI namespace and uses it to create empty event instances prior to event submission.

CEI allows the association of a Content Handler with an event factory. Using a common Content Handler allows a family of technologies, applications, or middleware to ensure that their CBE events all have standard minimal information content, and that the content is created consistently for all components in that family.

At runtime, the Event Emitter library invokes the completeEvent method of a content handler for all events produced from the event factory linked to the content handler. The content handler receives a reference to the event and gets a chance to modify, augment, or normalize the contents before it is sent to the Event Bus.

Service providers can bind associate their own content handler with an event factory and configure event sources to use a particular event factory to produce events. As an example, one may write a content handler that raises the event severity for insurance claim events associated with special customers.

Back to top

Next steps

This article has provided an architectural overview of the IBM Common Event Infrastructure and shown the development process behind the creation of client applications.

Expect this infrastructure to be used as a key integrating technology for applications and solutions that need to produce and consume Common Base Events and exchange those events across the IBM Enterprise Service Bus.

Resources

• In the "Specification: Common Base Event," read about a new mechanism for managing events in business enterprise applications in the Autonomic computing model (developerWorks, July 2003).
  
  
• Read "Standardize messages with the Common Base Event model" to see how translating log messages into Common Base Events and analyzing the events with an autonomic manager can heal a failing system (developerWorks, February 2004)
  
  
• Check out XPath, a language for addressing parts of an XML document.
  
  
• Explore the Tivoli® Software Web site for additional links to information related to the IBM Common Event Infrastructure.
  
  
• For several links to components that build the IBM Business Performance Management (BPM) strategy, including the IBM Common Event Infrastructure, visit the BPM Web site.
  
  
• Read this article for a brief overview of the Common Event Infrastructure (CEI), a set of modular event processing components.
  
  
• Try the IBM Common Event Infrastructure SDK for run-time libraries, code samples, and a tutorial that helps you get started with the technology.
  
  

About the authors

John Dinger likes to visualize the world through the eyes of his 4-year-old son. He has worked for a number of years designing and developing systems to manage complex communications and information processing environments. He can be reached at dingerj@us.ibm.com.

Denilson Nastacio spent three years in a startup company that creates software development training. He started with IBM in 1997, working in several technical positions in the area of network topology and event management. For the past two years, he has played the role of Chief Designer for the IBM Common Event Infrastructure. He can be reached at dnastaci@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Overview
• Architecture
• Common Event Infrastructure SDK
• Next steps
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Tivoli on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers