In most Complex Event Processing platform technologies, the Processor Event Node , or a similarly-defined construct (event engine), will execute the language of choice for the analysis of the events in an event stream.
For example, a car rental company might use the following business rule:
Offerings in the industry currently include; State-oriented, Inference rule, Script-orientated, and Agent-orientated SQL-idioms. Some people are familiar with the business rules approach and so decide to use the traditional "what-if-then" kind of analysis. Most others decide to leverage their SQL database skills and extend that knowledge to encompass the handling of streaming data in a way that is familiar to how they interact with data that is stored and processed in a database.
The benefits of a SQL-based event continuous query language extends the rigor of the relational model to event stream processing that can result in a more robust implementation with broader application.
These types of CEP language implementations can incorporate the well-known SQL '99 plus standards and relatively easily introduce the language extensions for the temporal and event count windowing requirements. For many, using this type of event handling approach provides now, and for the future, a single consistent language that can be used for all database and middleware application analysis processing.
The processor event node provides the direct analysis on the events and uses a number of various techniques.
Event filtering is applicable when thousands or even millions of events flow into an application and there is a need to ensure a time effective handling of the more important information. This can involve either removing or sending the events of no concern to another channel or path, where it can be handled separately. In this way only the events that indicate a relevance to the current application requirement are passed for further "heavy lifting" complex analysis. By using this capability the event load is more evenly spread through the application, making it far more efficient.
Event correlation and aggregation is generally employed after any event filtering has been performed and is a methodology to understand the relationship between different events and then join or merge these events together. For example, when thousands of events from a temperature sensor arrive providing individual values for each room in microseconds, one approach is to determine which rooms are of interest, then identify the sensors only in these rooms and finally calculate the maximum, minimum, and average temperatures over a one minute time period.
Event pattern matching enables the identification of a certain distinct occurrence in either a specific time window, that is, the last five minutes, or in the last number of events. For example, this can be an event pattern where one can identify an "order" event, followed by a "completed packaging" event, followed by a "truck loaded" event, followed by a "arrived at customer house" event, all for a specific item, in three hours. This could trigger a SMS message to the customer stating "your order has arrived". Event patterns can be without limit but are generally dependent on the semantics of the specific industry. They can incorporate "not events", where you can define an event pattern that expects event A, followed by event B, but not a C event, followed by a D event.
A synthetic or business event often represents the dynamic construction of an event from a collection of events or elements of events (fragmented events). In many cases, an event may arrive that has little meaning alone but when joined with contextual or reference data, it has significant meaning. Let's take again, for example, the temperature sensor in a room. This sensor may send an event that provides an ID of 005 and a value of 60. Now if we had previously saved information that indicates and ID of 005 refers to a sensor on the tenth floor of a building at San Pedro Square, in the kitchen, attached to the ceiling at the right corner, then by joining this information with the current sensor temperature value of 60 degrees Fahrenheit, we now have a much more concrete (business) event that can be passed to another piece of business logic or system for action.
With the implementation flexibility offered by the Event Processing Network, it is important not to restrict the event processor with a limiting language implementation which does not support specialized language extensions. These extensions are driven by the changing analysis demands from the advances in the various related technologies of the future, but are also focused on enabling additional industry and domain-specific capabilities that are required by specific users.
Some event processor implementations provide the ability for easy extensibility using a capability called data cartridges .
A data cartridge concept provides the notion of directly adding or plugging in new functionality to a Complex Event Processing system, so that event analysis can be added for any type of circumstance.
It would typically define a set of new object types and their behavior, and/or provide implementations for various extensibility interfaces. The purpose of data cartridges is to enable users to capture business logic and processes associated with specialized or domain-specific data in user-defined data types. It constitutes one or more of the following components: user-defined data types, implementation for these types, new operators and aggregate functions, and implementation of certain extensibility interfaces.
An example of data cartridge extensibility is to integrate specialized spatial or Java language analysis directly as part of the CEP engine service.
Another topic to briefly cover in this section is the ability for event processors to be dynamically updated or changed with the rules or queries "on the fly" while the application continues to execute.
When events change in real life, your brain does not need to "reboot" in order to reassess the situation, it simply continues with the additional "event pattern" information to make a more informed decision. It may be implemented in different ways depending on the Complex Event Processing platform but most now, can provide this capability, and as these types of implementations evolve in the future, Event-driven systems potentially will have a self-awareness, self-learning, and a self-determination allowing them to adapt far more effectively to the changing dynamics of the world that surrounds us.