Summary
There are two factors that contribute to the variability in complex-event processing architectures. One is the handling of reference data and the extent to which the stream of events modifies the reference data used to interpret subsequent events. The other is the myriad ways in which the necessary sense, analyze, and respond activities can be partitioned and assigned to components. There is no one-size-fits-all architecture for complex event processing.
The simplest architectures are those in which the reference data is not impacted by the stream of events. The Threshold Detection and Condition Detection patterns are examples of these.
When the event stream can alter the reference data, the architecture gets a bit more complicated. The reference data now contains some historical information. If this information is essential for analysis, the solution must now become a system of record for this information. This requires persisting the information.
The Situation Recognition pattern uses historical data in its analysis. Some of the events that arrive simply result in updates to the historical data. Others, when analyzed, signify the recognition of a business-significant condition that must be announced. Track-and-Trace is a specialization of this pattern that does milestone-level tracking of a process. The Business Process Timeliness Monitor extends Track-and-Trace to determine whether the milestones are achieved on time.
Some applications require more than simply announcing that a condition exists. The Situational Response pattern applies contextual analysis to determine the actions that are required in a specific situation. The Decision-as-a-Service pattern makes these analytical capabilities available to non-CEP components. Sometimes the requirement extends beyond simply identifying the required actions to include the management of their execution. The result is the Orchestrated Response pattern.
Building a solution in which the situations to be recognized, the desired responses, and the analytical techniques to be used are all well defined is a straightforward (though sometimes complex) engineering exercise. Building a solution when any of these is not well defined has a significant degree of uncertainty. In these situations, before a commitment is made to produce a solution, preliminary work should be undertaken to clarify the approach to recognition and response. Once this preliminary work has been completed, an estimate of the effort required to implement the solution should be made to ensure that it is warranted by the expected business benefit.