Abstract:
An invention is disclosed for improved computer system management by allowing complex computer-monitored events to be handled in different formats for correlation, analysis and action. Specifically, a method and system are disclosed for processing multiple heterogeneous event types in a complex event processing (CEP) engine.

Description:
TECHNICAL FIELD  
       [0001]     This invention relates generally to computer system management, and in particular to an improved means for handling complex computer-monitored events by allowing them to be expressed in different formats for correlation, analysis and action. Specifically, a method and system are disclosed for processing multiple heterogeneous event types in a complex event processing (CEP) engine by permitting it to access and/or manipulate events having different formats in order to perform correlations between them that can be acted upon to produce a desired result.  
       BACKGROUND  
       [0002]     Currently, many network data processing systems employ correlation and automation solutions to aid in acting within complex environments, conditions and situations. These solutions are employed to consolidate, correlate and analyze information arising from computer-monitored user or system activities (or “events”) occurring within or across network systems to quickly and accurately identify and take action in response to a condition or problem. Processes or actions may be taken to adjust, fix, reconfigure or provision resources to solve the problem when the cause is determined. These correlation and automation solutions are also referred to as complex event processing (CEP) solutions.  
         [0003]     Complex event processing (CEP) is the derivation of high-level events from the analysis, correlation, and summarization of low-level events in event-driven systems. These high-level events (called “complex events”) are suitable for notifying people of conditions, opportunities or problems in easy-to-understand terms (or for triggering automated processes) so that action can be taken to produce a desired result. The term “event-driven architecture” refers to any applications that react intelligently to changes in conditions, such as the impending failure of a hard drive or a sudden change in stock price. One of the emerging styles of service interactions is the event-driven style. Event-Driven Architecture (EDA) is emerging as a variant of Service Oriented Architecture (SOA) that is being supported by multiple vendors. EDA systems are widely used in enterprise integration applications; including for example time-critical systems, agile process integration systems, managements of services and processes, delivery of information services, and awareness to business situations. There is a range of event processing middleware capabilities (i.e., software that mediates between an application program and a network); including publish-subscribe services (which have been incorporated into standards such as JMS—Java Message Service), commercial systems, mediation services (such as event transformation, aggregation, split and composition) and event pattern detection (complex event processing). The CEP software program must be prepared to respond to a variety of events in unpredictable sequences and combinations.  
         [0004]     In a CEP environment there are many different applications that produce and/or utilize “events”. Each application that either generates or acts upon events may require a different “event format” for specifying and organizing the characteristics and properties (or “attributes”) of the data and instructions (such as their types, sequences and relationships, etc.) that are utilized in processing the event. Applications that must process events from multiple sources, such as a CEP software component (or “engine”), must be capable of accessing and acting upon these different event formats in a standard manner. In addition, the software user or programmer must have access to the “metadata” globally defining the attributes of these events (and their formats), when a graphical user programming interface (GUI) is employed to build operational rules (or “artifacts”) that enable the CEP engine to act upon the events. Usually multiple event types with different associated attributes exist within each format that all must be easily accessible using the GUI, so the user can select those attributes of a given event and define logical expressions upon this event to determine if it should be selected by the CEP “rules” in producing a desired result.  
         [0005]     Existing programming solutions, such as those described in U.S. Pat. Nos. 6,549,956; 6,253,367; 6,145,009 &amp; 6,138,121 and in U.S. Patent Publication Nos. 2005/0160134; 2004/0073566 &amp; 2002/0010804 (the disclosures of which are all incorporated by reference as if fully set forth herein), either require all events to be converted to a common format or do not permit different event formats to be processed by the same CEP engine. In the first instance, there is a disadvantage in requiring the program user to translate (or “map”) the original format to the common format. A degradation in system processing performance also occurs when converting all of the attributes of the original event to the common format. In the second instance, important “cross-correlation” features existing between different events may be lost for those event formats that cannot be processed.  
       SUMMARY OF THE INVENTION  
       [0006]     This invention discloses an improved means for handling complex computer-monitored events in system management, by allowing the events to be expressed in different formats for correlation, analysis and action. Specifically, a method and system are disclosed for processing multiple heterogeneous event types in a complex event processing (CEP) engine by permitting it to access and/or manipulate lower-level events having different formats, in order to perform correlations between them that can be acted upon to generate a higher-level event or otherwise produce a desired result. In this way, the invention improves system performance by handling heterogeneous complex events through their real-time utilization which only occurs during actual system processing of an event.  
         [0007]     The invention consists of a CEP engine comprised of a “runtime event wrapper” component for capturing the original event format, along with an “event definition provider” component for handling the “metadata” defining the attributes of that event format and any specific event types associated to it when the rules are being authored. The “runtime event wrapper” component is used to access the original event attributes in a uniform manner, by capturing (or “wrapping”) an event in its original format instead of requiring conversion of its attributes to a common format. The “event definition provider” component is used to represent the metadata for an event format and its specific event types in terms of its set of attributes and associated constraints, in order to allow flexible and easy “rule building” capability in selecting those attributes of a given event (and defining logical expressions upon this event) to determine if it should be selected by a given rule. These logical expressions are used to create “CEP rules” that act upon different events expressed in different formats to produce a desired result, when common attributes (as defined by the rules) are encountered in processing the events.  
         [0008]     It is therefore an object of the present invention to overcome the disadvantages of the prior art by providing an improved means for handling complex computer-monitored events in system management, using complex event processing (CEP) correlation rules acting upon different events expressed in different formats to produce a desired result when common attributes defined by the rules are encountered as an event is processed.  
         [0009]     It is another object of the present invention to overcome the disadvantages of the prior art by providing a method and system for processing multiple heterogeneous event types, using a complex event processing (CEP) engine to access and/or manipulate lower-level events having different formats in performing correlations between events that may generate a higher-level event to produce a desired result.  
         [0010]     It is another object of the present invention to overcome the disadvantages of the prior art by providing a complex event processing (CEP) engine comprised of a “runtime event wrapper” component for capturing the original format of an event, used in cooperation with an “event definition provider” component for handling “metadata” defining the attributes of event types in a specific event format at rule authoring time.  
         [0011]     It is another object of the present invention to overcome the disadvantages of the prior art by providing a complex event processing (CEP) engine “runtime event wrapper” component used to access original event attributes by capturing an event in its original format instead of converting event attributes to a common format.  
         [0012]     It is another object of the present invention to overcome the disadvantages of the prior art by providing a complex event processing (CEP) “event definition provider” component used to represent metadata for an event format and event types in terms of a preferred set of attributes and associated constraints for an event format and its event types, so as to select attributes that form the logical expressions that are part of the CEP rules.  
         [0013]     The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, together with further objects and advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings. 
     
    
     BRIEF DESCRIPTION OF THE DETAILED DRAWINGS  
       [0014]      FIGS. 1 &amp; 4  are flowcharts illustrating the complex event processing (CEP) environment where the invention is applied.  
         [0015]      FIGS. 2 &amp; 3  are diagrams illustrating a graphical user interface (GUI) that can be employed with the invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0016]      FIGS. 1 &amp; 4  are flowcharts that illustrate the complex event processing (CEP) environment where the invention is applied. It includes a graphical user interface (GUI) CEP Rule Builder  30  that can be employed with the invention to build (or edit) “correlation rules”  20  that enable a complex event processing (CEP) engine  10  to process multiple heterogeneous events  100  in a complex event environment. Each of the computer system management application products that utilize (or “embed”) the illustrated CEP environment may require that the CEP engine  10  accept a different event format  110  for processing. (Examples of known formats include: events that conform to the Common Base Event Specification, Financial Market Messages, Symptoms, Situations, SNMP traps, etc.) In addition, some system management products may require the CEP engine  10  to perform correlations between events of different formats. For this reason, the CEP engine  10  must provide a means of allowing different event formats  110  to be processed by the correlation rules  20  without requiring changes to the internal program structure and operation of the engine. This is done through the “runtime event wrapper” components  40 . The CEP Rule Builder  30  must provide a means for accessing those different event formats  110  to build the correlation rules  20  using the programming interface provided by the “event definition provider” components  50 .  
         [0017]     As shown in  FIGS. 2 &amp; 3 , the CEP Rule Builder  30  is an installable GUI that allows the user (or “rule writer”) to select specific event types  1   20  having different formats  110 , in order to specify those of its attributes  130  to be used in forming logical operations that make up the CEP correlation rules  20  used to process events  100 . The “event definition provider” interface  50  contains a set of programming techniques (or “methods”) that can be implemented or “plugged in” for each event format  110  to enable the CEP Rule Builder  30  to acquire the metadata defining the event types  120  available within each event format. These methods return the event type hierarchy instituted by a given event definition provider  50  as well as detailed information about the attributes  130  that compose a given event type  120 . Information about each attribute  130  is displayed (such as its name, type, default values and allowed values) and its location (or “path”) is stored for use by the “runtime event wrapper”  40  when a rule  20  utilizing that attribute  130  is being executed and the attribute must be accessed to complete operation of the rule. The attributes  130  can also be organized in a hierarchy that can be visualized in a “tree structure” when shown in the GUI.  
         [0018]     The “runtime event wrapper” component  40  of the CEP engine  10  is also a “pluggable” interface that allows the access of the original event format  110  while events are being processed by the rule engine. This interface provides an “abstraction” (i.e., a logical representation) of events  100  that allows them to be processed in a generic fashion. The “runtime event wrapper”  40  contains a set of methods for allowing specific attributes  130  of an event  100  to be retrieved and used in their original form. The “runtime event wrapper”  40  also supports the hierarchical arrangement of complex attributes  130  with a dotted notation that allows a user to access (or “walk”) through their different organizational levels. The “runtime event wrapper”  40  also contains a method for allowing the user to access and/or manipulate an event  100  in its original form using the methods available in the underlying implementation of that event.  
         [0019]     As shown in  FIG. 3 , an event provider implements the methods in the “event definition provider” interface  50  in order to provide metadata information about a specific event format  110 , including the different event types  120  available within that format (which can be organized in a hierarchy) and the attributes  130  contained by each event type (as well as any constraints on the values those attributes can assume). This metadata information is presented to the rule writer and then used to create CEP correlation rules  20  by selecting those event types  120  (e.g., ServerStatusUpdate) to be used by a rule. Attributes  130  of these event types  120  to be used in logical expressions of the rules (e.g., cpuUsage&gt;0.95) are also selected. These steps are part of the creation of rules  20  that perform correlations between different events  100  expressed in different formats  110 .  
         [0020]     The CEP engine  10  which processes these rules  20  utilizes the “runtime event wrapper”  40  such that different event types  120  of different formats  110  are correlated with each other to detect common attributes (as defined by the rules  20 ) when they are encountered. An event  100  maintains its own original format  110  and a specific event attribute  130  is checked by requesting its value from the “runtime event wrapper”  40 . In this way, the invention handles heterogeneously formatted complex events “on the fly” to improve system performance through a real-time utilization (or “late binding”) of a specific event format which only occurs during “runtime” (or actual system processing of the event).  
         [0021]      FIG. 4  provides an example of a CEP “workflow” (or processing sequence) that occurs during runtime. At this stage, the rules  20  (which in this example provide root cause determination between information technology (IT) and business events) are already deployed in the CEP engine  10  (which is embedded in a system management application). Three events (ATMTransactionFailure, DBConnectionFailure and RouterDown) of three different event formats  110  occur in the processing environment and are forwarded to the CEP engine  10 , which is capable of handling these different event formats and correlating them together to determine the root cause (in this case, RouterDown). As a result of this action taken by the CEP engine, the operator is alerted to restart the router as a corrective action.  
         [0022]     While certain preferred features of the invention have been shown by way of illustration, many modifications and changes can be made that fall within the true spirit of the invention as embodied in the following claims, which are to be interpreted as broadly as the law permits to cover the full scope of the invention, including all equivalents thereto.