Brenda Michelson announced that the OMG EPCS webinars are up on the web: register here for access links. Presentations included:

• Gartner’s Roy Schulte on “The Time for Event Processing is Now” (a pun on the fact that the time for event processing is always now, otherwise we are doing historic (data) processing…)
  • Roy introduced the concept of being “event-driven”, and CEP leading to “situation awareness”. Roy’s version of what we call the “event - decision - action” model is the “event - compute+analyse+decide - response” model - of course these are equivalent with some fuzziness between the event and the decision…
  • Conventional (transactional system) reports and BI are not event driven, and suffer from too much “business latency” - problems are detected after they occur rather than as they occur, leading to fewer opportunities for intervention.
  • Roy’s CEP patterns included:
    • the “operations or process monitor” (a.k.a situation awareness in the business operations and processes)
    • the “supply chain management monitoring” (a subclass of the above)
    • the “enterprise nervous systems” such as monitoring airline operations or large railroads
  • The EP Market viewed “continuous intelligence” applications often using custom CEP apps is >$10B in 2009, with the BAM and CEP tool market being $189M in 2009 with likely growth of 30-40% pa.
• Chris Bird at SABRE showed an “Event Distribution Architecture” case study, referencing the book and analyst methodology “Lost in Translation” that is based on policies, events and content.
  • Events are not necessarily about “real time” behavior, but responding as required. The “content” is the information related to the event, and issues include “how to avoid gumming up the works”… so the “enterprise pattern” is to define events, interested parties, information and security models… leading to a “policy event content” framework.
  • On events, Chris assumes separate content and control channel to coordinate (transactional?) event processing, with a “policy engine” monitoring the control channel.
  • Chris’ explanation of his view on event processing seemed definitely about coordinating “event transactions”, talking about “message failures” and the suchlike.
  • Content structures could be XML, legacy formats, or some canonical form - Chris proposed sending both old formats and new canonical forms, or possibly transforming the event in a “staging processor” and republishing for other processing agents, giving much flexibility.
  • Chris’ key points were to concentrate on event distribution, not event processing, and loose coupling was better than tight schemas…
• Opher Etzion of IBM Research presented on the next 7 years in event processing
  • Trend 1 was from narrow to wide focus applications, beyond the current domains to robotics, home automation etc… although to be fair most of the embedded systems guys already do lots of event-driven state modelling in their systems.
  • Trend 2 is from monolithic to diversified systems.
  • Trend 3 is from proprietary to standardised, for example in languages allowing for interoperability.
  • Trend 4 is programmer-centric to semi-technical centric - hence modelling, high level languages like event pattern languages, and so on.
  • Trend 5 is from standalone packaged applications to embedded components.
  • Trend 6 is from reactive to proactive.
  • Directions are that multiple types of platform are moving to a virtual event processing platform, a movement to tailor-made optimisations within event processing,and  event processing software engineering.

Overall some interesting points made in these presentations, and the event was an interesting alternative to the more academic DEBS and Dagstuhls this year.

[Disclaimer: TIBCO presented too. I'll leave the commentary on that to other folks!]

[Update: removed one review due to author objections!]

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: note TIBCO is not a member of either the OMG's EP or BPMSOA consortia - they seem to be focused on end-user rather than vendor participation - but is an OMG member and participant in standards development. We currently see the EPTS as the main advocacy group across vendors, academics, analysts and end-users, but will be monitoring the progress of the EP Consortium].

So here are a few simplistic patterns on how CEP (event processing) relates to BPM (processes) and SOA (services)…

CEP Pattern	Example	Diagram
1a. Standalone CEP 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…	Monitor a production process to provide an “additional view” or dashboard for the process control manager.
1b. CEP enriching BPM processes and/or  SOA services. 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.	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.	Detect when response times exceed some metrics and suggest corrective actions such as reallocating resources.
2b. CEP-based decisions for processes and services 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.	A BPMN “rule activity” sends a decision request to the CEP engine to get a valid decision for a process decision point; the CEP engine monitors the decisions made.
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.	In a complex business process for ever-changing fulfillment problems, CEP-based rules determine which sub-processes are valid based on incoming information.
3b. Embedded processes and services within CEP 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! So this covers things like event-based policy implementations being embedded as CEP rules rather than as external services, but alongside some external services such as an operational database. 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!	A service gateway controlling access to existing services, but embedding decisions, service policies, and business rules.

So, did I miss anything?