CEP ACTIONS Part 2: Separation Anxiety vs. Implementation Concerns

As a follow-on to a prior post on "CEP: What about the Action", as well as a few other related posts on this subject, I thought I would continue the discussion on this topic. Several blogs suggest that separation of action is an architectural goal when addressing the issue of whether actions should be performed from within a CEP system.  I agree that In theory this might be a worthy architectural goal, but in the real-world, things are never that simple.

In a recent discussion with an organization, the subject arose as to how CEP could detect impending exception conditions, and handle them in a variety of ways. For example, if the action required some type of process requiring human intervention, it might be that the CEP engine could kick -off a long-running workflow controlled by a BPM tool. Clearly this action would not be handled by the CEP platform, but the platform should make it easy to call out to these types of facilities and correlate responses with the original event.

But what if a real-time response is required? For example, if monitoring flight operations, CEP could dynamically re-adjust flight routes in response to an impending collision. One might recoil from delegating the action to an external component – and risking chance to adjust flight paths - purely for the need of "architectural separation". Or should the "head of desk" in a bank’s proprietary trading group be content to absorb trade execution latency in deference to the architectural notion that CEP doesn’t do action?

In addition to latency considerations, one must also consider the accessibility of the programming model. Speed is not simply a matter of how fast something executes; speed of deployment is equally important. Having a CEP development model that allows the developer to model the application holistically as opposed to "piece parts” some of which one designs within CEP and others of which are handled elsewhere can be an important consideration. A holistic approach does not preclude exposing "actions" as callable services that might be delivered elsewhere. CEP infrastructures should provide the ability to build event-driven applications within its own confines, and then selectively expose actionable components as services or events as needs arise. 

For a similar, non-CEP, example consider J2EE application servers that are used to build traditional portal applications. Strictly speaking, every service in a portal would be implemented as a service, either as a pure web service or as an exposed service on an ESB. However, we know that real-world portal implementations do not strictly adhere to these principles, due to the ease of use of the portal programming model (and to some extent speed of execution). However, most J2EE applications do offer the ability to expose EJB's as web services, which negate any risk to the overall reusability of the services in a SOA environment.

Actions are fundamental to CEP systems. I believe the decision as to whether the CEP system executes the action or hands it off to another system is not a matter of architectural abstraction, but rather a matter driven by the requirements of the business, with recognition of the systems already in place.