There were some customer discussions recently on the conceptual relationships between the CEP and BPM and SOA “software stacks”. This coincided with the announcement of the OMG-backed Event Processing Consortium being set up (alongside the merger of the SOA and BPM consortia), events which themselves can be interpreted as that event processing has some special role to play alongside BPM and SOA.
[Disclosure: TIBCO is not a member of these consortia as they are focused on end-user organisation participation. In particular the EPTS is the main advocacy group across both vendors and end-users, as far as I can tell].
So here are a few simplistic patterns on how CEP (event processing) relates to BPM (processes) and SOA (services)…
This is a bit of a misnomer - you don’t identify event patterns without some intent to use them, and at the very least such a use would be in a BAM type role displaying interesting correlations for some business person - who of course is engaged in some kind of business process, which may or may not be managed by BPM…
Example: monitor a production process to provide an “additional view” or dashboard for the process control manager.
This is the conventional view of CEP, detecting the complex events that are of interest to, and useful in, appropriate processes and services.
Complex events in these cases can be as straightforward as deducing that a deliverable has been completed, or some process truly initiated. Typically the CEP system is transforming source events into business events, for onward use in (the) business processes.
Example: identifying exception events in a business that need to handed to a workflow or case management system for resolution.
2a. CEP monitoring processes and services
This is where the sources of events are the managed processes and services themselves. This process and service monitoring is used to detect exceptions, disparities across systems, and system performance…
Note that effectively this pattern is a combination of patterns 1a and 1b above.
Example: detect when response times exceed some metrics and suggest corrective actions such as reallocating resources.
This is where I need to make intelligent decisions for the process and service layers, using the CEP layer as a monitoring, shared decision management component.
Note that effectively this is a slight extension of pattern 2a above.
Example: BPMN “rule activities” sends a decision request to the CEP engine to get a valid decision for a process decision point.
3a. Dynamic process and service control
This is where the events from processes and services, and external services, are combined to select which processes and services are relevant to use for the current context.
In effect, the CEP engine becomes the controlling agent for the business processes and service engine, handling for example dynamic process selection.
Note that this pattern is a further evolution of patterns 2a and 2b.
Example: in a complex business process for ever-changing fulfillment problems, CEP-based rules determine which sub-processes are valid based on incoming information.
The final evolution of the above is when you argue that the functions of the BPM and SOA stacks can be subsumed into the CEP layer.
In reality this is usually only a partial subsumption, as otherwise the centralization of services into just 1 layer could be perceived as contrary to the very idea of SOA! Hence this is almost always only a partial subsumption, with things like event-based policy implementations being embedded as CEP rules alongside existing services such as an operational database service. Indeed, one could argue that in this case the CEP event processing agents are themselves really part of the SOA layer, not the other way round!
Example: a service gateway controlling access to existing services, but embedding decisions, service policies, and business rules.
So, did I miss anything?