« February 2008 | Main | April 2008 »

March 2008

Monday, March 31, 2008

CEP ACTIONS Part 2: Separation Anxiety vs. Implementation Concerns

Posted by Matt Rothera

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.

Friday, March 21, 2008

CEP and Real-Time Risk – “The Dog Whisperer”

Posted by Chris Martins

This week’s Financial Times published an interesting article by Ross Tieman on technology’s role as a “scapegoat” (his term) for some of the problems in financial markets. With its both evocative and provocative title, “Algo Trading: the dog that bit its master”, you can get a sense of the article theme, though a complete reading of the piece is worthwhile.

One of the challenges noted by the author is in the area of risk management. Too often existing risk processes - and their supporting technology - focus upon performing end-of-day assessments. But when much of the trading activity is quantitative, that can be much too late to detect when positions are careening out of control and risk thresholds have been breached. There seems to be growing recognition for the need for continuous calibration of positions – what amounts to real-time risk management – in order to keep pace. Perhaps the notion of a “daily VAR” may well become an artifact of the 1990’s. 

Just as it powers a number of real-time trading deployments, CEP can be an equally rich technology foundation for building the kind of real-time visibility that is needed by modern risk management systems. The same technology that drives quantitative trading can equally be applied to the task of monitoring that trading and keeping it in check, if necessary.

Now risk management is an extremely complex endeavor, so I would not argue that CEP alone is the answer. But rightly implemented, CEP clearly offers the low latency infrastructure that can help drive the real-time calculations that are needed. Market regulators (e.g. FSA) and trading exchanges (e.g. Turquoise) have begun to recognize the potential of CEP to monitor market behavior. It is likely only a matter of time before trading firms awaken to the possibilities of CEP driving real-time risk systems that monitor behavior within the firms themselves.

So, if you’re concerned about the technology “dog” biting its master, perhaps it’s time to consider CEP as a prospective “dog whisperer” that can help manage the risk. 

Wednesday, March 05, 2008


Posted by Chris Martins

In the world of CEP, attention to rapid application development has tended to take a back seat to the focus on latency and performance.  However, the ability to develop and deploy CEP solutions relatively quickly is important if the applications are to be able to adjust to changing circumstances.  And rapid application development and rapid application execution are certainly not mutually exclusive. For CEP to become more widely adopted – and arguably to fulfill its potential to become a pervasive mode of computing – there must be increased focus on the process of building CEP applications. 

Apama is a longstanding proponent of tools that 1) foster rapid development and 2) make the development of CEP applications more accessible to the business users.  This week we announced some enhancements in this area, in the context of Apama's SmartBlocks.  As a bit of serendipity, this announcement follows some recent data gathered by Forrester Research that speaks to the role of business in the adoption of CEP - "CEP Adoption is Broader, Deeper, and More Business-Driven than IT May Expect", January 31, 2008.  That report is gated, but a summary excerpt is available.