Outside CEP: the infrastructure stack

Reading Time: 2 minutes

One of the interesting options for CEP customers is “how much of the stack” do you “already have in place” versus “need to purchase” to feed the CEP engine? Although it is well known that any form of Event Processing will require a number of supporting technologies (middleware to deliver and consume events or messages, services or processes to enact the results of CEP-derived decisions, state management and persistence for time-based event patterns [*1]), it is not necessarily obvious whether or not an existing IT infrastructure will need upgrading to take best exploit the capabilities of CEP.

Factors to consider for the middleware selection include:

  • -performance (throughput, latency)
  • -reliability and resilience (including security)
  • -compatibility with existing applications and users (although any lock-in from an existing vendor should be discouraged!)
  • -headroom for future needs
  • -ROI

One interesting corollory of this question is that many of the other CEP vendors have naturally concentrated on areas where the supporting technology load is minimized: industries with existing event structures such as financial services and algorithmic trading applications using relatively standardized event streams to be processed, and consequently minimizing the investment required in supporting integration infrastructure. After all, every $ a CEP vendor spends on middleware integration is a $ less on interesting CEP functionality.

At TIBCO, of course, we have access to the full SOA and BPM stack, with best-in-breed publish-and-subscribe messaging underpinning the infrastructure stack. Quite a few TIBCO BusinessEvents customers, for example, are either already enhancing their middleware with TIBCO BusinessWorks, or are already deployed with TIBCO middleware, adapters, etc. Others will be quite content (!) to be utilizing competitor’s middleware stacks, and may want to use a CEP engine standalone without any other TIBCO infrastructure. For example, a blue-rinse IBM user, deploying the MQSeries message stack, or a red-rinse Oracle user, deploying Fusion, but both still wanting to deploy a best-of-breed JMS message-based rule-driven CEP engine would be quite happy to plug-in TIBCO BusinessEvents. After all, its a heterogeneous world out there, and we always make sure that any middleware user can access CEP technology from TIBCO!

Notes:

[1] Of course, many CEP engines (including BusinessEvents) include out-of-the-box persistence mechanisms.