This scenario shows how the event processing business pattern for event-driven architecture integration described in Chapter 1 can be implemented.
As shown in the following diagram, the event processing business pattern can be implemented using a Complex Event Processing (CEP) engine, which is controlled by an ESB.
Trigger:
- An event occurs and is placed in a queue by the source system.
Primary flow:
- An event-driven consumer building block removes the messages or events from the queues using an appropriate JMS adapter, and forwards them to the CEP engine.
- The CEP engine uses a specific query language to identify the events that are of interest, and enables events to be, for example, filtered, correlated, and aggregated.
- The CEP engine sends the events that it has identified, in the form of messages, to the ESB endpoint. This ensures that the events are forwarded as messages to a web service through SOAP.
- The events that are not of interest are discarded.
- Events are sent via sources other than queues and are linked to the ESB using the appropriate adapters.
- The events identified as interesting by the CEP engine are sent to a message router building block in the mediation layer, which ensures that several potential systems receive the event (in combination with the broker business pattern).
- Events that are not of interest are saved in persistent storage.
The event processing business pattern can be implemented on more than one level with multiple use of a CEP engine, as shown in the following diagram. The CEP engine is seen as a logical entity, but in reality, the multiple engines are often the same physical engine with the complex event processor simply being used more than once.
The output stream from the first CEP engine (in other words, the events that are identified) acts as the input stream for the next CEP engine. This makes the process of identifying complex events simpler, as the first CEP query, for example, establishes causality between the events, and the second CEP query aggregates the two events into a new event (a complex event).
- An event occurs and is placed in a queue by the source system.
Primary flow:
- An event-driven consumer building block removes the messages or events from the queues using an appropriate JMS adapter and forwards them to the CEP engine.
- The first CEP engine (first level) defines the events of interest using the query language and places them in another queue.
- The second CEP engine (second level) uses the second queue as input, and processes the output from the first engine for a second time.
- The second CEP engine sends the events that it has identified to the ESB endpoint, which ensures that the events are forwarded to a web service through SOAP.
- The events that are not of interest are discarded.
Alternative flows:
- For reasons of efficiency, an in-memory queue, or a data grid framework (see next section), can be used for the second queue.
- Further levels of CEP engines can be added to identify more complex events, and their causality.
- The CEP engine for each level can take the form of an independent physical engine in order to allow for the processing of a heavy event load.