Applications that are appropriate for CEP are event-driven, which implies some aspect of real-time behavior. To be more specific, the typical CEP application area can be identified as having some aspect of “situation awareness,” “sense and respond,” or “track and trace,” aspects which overlap in actual business situations.
Situation awareness is about "knowing" the state of the product, person, document, or entity of interest at any point in time. Achieving this knowledge requires continuous monitoring of events to do with the entity, events that indicate what situation or state the entity is in, or about to be in. As an example, a dashboard indicates all performance indicators for a runtime production process. All the production plant events are monitored and the situation, or health, of the production process is determined via some performance indicators that are shown in real-time to one or more operators.
Sense and respond is about detecting some significant fact about the product, person, document or entity of interest, and responding accordingly. To achieve this result the software does the following:
Track and trace is about tracking the product, person, document or entity of interest over time and tracing pertinent facts like location, owner, or general status. An example would be tracking events from an RFID-enabled inventory control system where at any point in time you need to know how many widgets are in what location.
“Situation awareness,” “sense and respond,” and “track and trace” can all be classified as types of activity monitoring, for which the continuous evaluation of incoming events is suitable. For this reason, CEP is often described as a generalization of Business Activity Monitoring (BAM), although the event processing task may be only indirectly related to business, as in the case of an engine monitoring application or process routing task.
Event model The event model describes the inputs into TIBCO BusinessEvents. Events provide information through their properties and (optionally) through an XML payload. The event model provides the primary interface between TIBCO BusinessEvents and the outside world, for input as well as output. Typical event sources (or channels) are messages from TIBCO Rendezvous and TIBCO Enterprise Message Service middleware, events generated explicitly by TIBCO BusinessEvents, and other sources such as SOAP messages. Events can be used to trigger rules.
Concept model The concept model describes the data concepts used in TIBCO BusinessEvents, which may be mapped from events or their payloads, or loaded by some other mechanism into TIBCO BusinessEvents. The concept model is based on standard UML Class and Class Diagram principles.
Rule model Rules provide one of the main behavioral mechanisms in TIBCO BusinessEvents. Rules are defined in terms of
declarations (events and concepts of interest),
conditions (filters and joins on and between the attributes of the events and concepts), and
actions. The underlying rule engine is based on an algorithm called the Rete algorithm, which mixes all rules together into a type of look-up tree, so that any additional concept instance or event can near-instantly cause the appropriate rule or rules to fire and invoke the appropriate actions. Rules are almost always defined in general terms (concepts or classes and events), so they apply to however many combinations of those events and classes exist in memory at any one time. The combination of rule declaration and condition defines the
event pattern required for CEP operation. Rule actions that update other concepts may cause other rules to become available for firing, a process called
inferencing or
forward chaining. These types of rules are generally called
Production Rules. The appropriate UML Production Rule Representation is still under development.
Rule functions Algorithms, procedures or functions may be usefully defined as parameterized rule functions and re-used as required in rule actions and other areas where a behavior can be specified.
State model An important item of metadata for a concept or object is its state. Typically a state model describes the states that an entity can hold, and the transitions between states that are allowed, and the conditions for such transitions. Internally the state model is just additional metadata, but it is more useful to describe the state model as a visual model of states and transitions. The state transition rules can be viewed as special customizations of standard rules. The state model is based on the standard UML State Model principles. Requires TIBCO BusinessEvents Data Modeling add-on software.
Query model Queries can provide both snapshot and continuous views of the data in a TIBCO BusinessEvents cache. Queries can also provide continuous views of data arriving through channels. They are constructed and executed from rule functions in a specialized agent (called a query agent). Queries provide event stream processing or set operations to derive information that can then be used in rule functions, or shared (via events or the cache). Requires TIBCO BusinessEvents Event Stream Processing add-on software.
TIBCO BusinessEvents offers an In Memory object management type, but for most use cases, persistence of data is required. To provide TIBCO BusinessEvents with its enterprise and extreme transaction processing capabilities and to ensure resilience, TIBCO BusinessEvents provides a high performance distributed cache. The cache allows data to be persisted in memory and removed from the Rete network or returned to the Rete network, as required, to handle extremely large problem domains (domains that would not typically fit into a runtime memory model). A backing store can be added to provide additional reliability, and other functionality. Just as data can be moved between the Rete network and the cache, so can less used data be moved between the backing store and the cache, to balance storage, memory, and performance requirements.