CEP and SOA: Six Letters Are Better than Three

Michael Havey

February 2009


Around a decade ago, it was possible for a single, precocious developer to build an entire SOA-like platform single-handedly. Granted, it was not an easy task to construct a service container and surround it with robust connection management, application security, transaction management, and reliable messaging, but it was at least an attainable goal. It was a proud achievement to build a toy application server or MOM platform in one’s basement.

Those were simpler times. Today’s SOA suite is far too vast for one person to build, and uses computer science that is more advanced than a basement hacker can contend with. In the first place, today’s services—as I argue in my new book SOA Cookbook (Packt, 2008)—are designed as processes rather than simple method calls. Building an SOA process engine means brushing up on, or learning from scratch, Finite State Automata, Petri Nets, and, perhaps, the Pi Calculus. Additionally, these processes use business rules to decide on next actions. Building the required rules engine presupposes proficiency in forward-chaining rule definitions, the RETE algorithm, and, possibly, genetic algorithms. Toy SOA is a relic of the past; today’s SOA requires a large team of very smart people.

Still, for all its might, today’s SOA is merely reactive. An SOA process provides a business function that reacts to requests. If the function is requested ten thousand times, the process is run ten thousand times. It is not in SOA’s mandate to make sense of trends, or to find suspicious happenings, across those ten thousand invocations. SOA’s job is to be a workhorse, serving the requests. It is not an anomaly watchdog or a slice-and-dice business analysis tool. Still, many enterprises seek just such a capability.

Not surprisingly, SOA vendors are starting to add Complex Event Processing (CEP) to their solution. CEP listens on the bus for the same events that pass in and out of SOA processes, but—unlike SOA—is concerned mainly with the detection of patterns that emerge across events. It does this, as we’ll discuss, by applying event-pattern matching rules to the events. CEP thus relies on both SOA’s event bus and its rules engine. Not only does CEP fit in the SOA architecture, but also provides the watchdog capability that business stakeholders find so valuable.


CEP isn’t a new technology but is only now gaining traction in the marketplace. David Luckham wrote the definitive book on CEP (The Power of Events, Addison Wesley), which was published in 2002. Over the years several academic implementations have been developed, notably Stanford’s Rapide and Cornell’s Cayuga. Numerous CEP startups failed in the early days of CEP, during the rise and fall of dotcom in the late 1990s. It was to help market one of these companies, ePatterns, that Luckham started work on his book. The company didn’t pan out, as Luckham reminisces in his article “A Short History of Complex Event Processing Part 3: The Formative Years.” (http://complexevents.com/?p=553), but the book lived on, becoming the bible of events.

Until recent years, the most established commercial implementations came from small vendors, such as Coral8 and Streambase. But within the past few years the major SOA vendors—who had previously kept arms-length from CEP, doubtful of its market potential— have started to incorporate CEP into their stacks. IBM, for instance, recently acquired Coral8. TIBCO aggressively sells its CEP tool, BusinessEvents, in its SOA and BPM deals. Oracle, thanks to its BEA acquisition, offers a product called “Oracle” CEP.

The combined SOA/CEP offering is encouraging, because CEP’s value comes not from its intrinsic value but from its contribution to an overall solution. SOA vendors, in a sense, have been in the “overall solution” business for years. They promote the idea that business architecture should be built on services, and they provide a platform on which to build those services. But what’s always been missing was a tool to watch the services, to make sense of what’s happening operationally.

What CEP and SOA have in common is events. Both technologies use events, but for different purposes. SOA processes use events to drive control flow. An SOA process is started by an event, and during the course of its execution waits for further events to propel it forward. Events in SOA, in effect, force process transitions. Most SOA processes not only receive events but also send events. When a process sends an event, another process receives it. Elaborate choreographies arise when the processes of multiple organizations engage in conversations of events.

CEP, by contrast, is a rules engine that uses events to trigger rule evaluations. CEP is constantly listening on the SOA bus for events. As we explore in more detail below, by using event pattern matching rules, CEP is able to infer causal connections between seemingly disparate events. CEP can also aggregate a set of inconsequential low-level events into a single, business-meaningful complex event. In stock trading, for example, a customer’s purchase of shares is the combination of four events (keeping it simple):

  1. The customer’s request to the broker to buy the shares
  2. The broker’s placement of the order
  3. The result of the order, including the price at which the shares were bought
  4. The broker’s response back to the customer.

When CEP detects these four events, it publishes a complex event—BuyOrderCompleted, let’s call it—back to the bus, where interested listeners may pick it up. The following figure illustrates the sequence of steps; this design is discussed in more detail below.

SOA Cookbook

CEP can also detect breakdowns in the buy order. For example, if the broker fails to respond back to the customer in a timely fashion, CEP can easily spot this and publish a BuyOrderBrokerResponseLate event. CEP can also spot anomalies that span multiple orders. For example, it can detect suspicious broker activities like a buy-ahead, in which the broker, when directed by a customer to buy shares, buys his own lot of shares first, and sells them after placing the customer’s order. (The broker makes a nice profit from this furtive trade; the customer’s order, when large enough, drives the price up, so when the broker sells, he comes out ahead.) It would be fiendishly difficult to build a detection mechanism for buy-aheads into SOA processes; CEP, as a watchdog off to the side, is much better equipped.

This trade monitoring example is one of many CEP use cases. CEP use cases arise naturally from SOA use cases. If events move through the bus to drive services and processes, there is bound to be some important business reason to infer complex events from them. Indeed, many CEP use cases require SOA. Fraud detection, for example, which checks for anomalies in transactions on an account, must reside on an SOA platform with processes in place to perform transactions on accounts. The fraud detection rules must understand the structure of the account events and the protocol governing how they are exchanged.

CEP in the SOA Stack

The following figure shows where CEP fits in the stack offered by major SOA vendors.

SOA Cookbook

The three layers of the operational stack, shown on the right side of the diagram, are the Enterprise Service Bus (ESB), the Orchestration/Service Engine, and the BPM engine. The Orchestration Engine runs SOA processes, and it uses the ESB, which acts as a full-featured message broker, to send and receive events to its partner systems. Processes that involve both system and human work are split between the Orchestration Engine and the BPM Engine. A workflow process running on the BPM Engine invokes SOA processes in the Orchestration Engine to perform system actions; an SOA process running on the Orchestration Engine uses processes in the BPM Engine to delegate human work. You can refer SOA Cookbook (Packt, 2008) for an expanded discussion of the stack.

CEP and its cousin Business Activity Monitoring (BAM) are shown as pieces off to the side. They are the not part of the core operational SOA platform, but rather provide an important business monitoring capability. BAM, in most implementations, is a summary view of business processes in the system. Like CEP, it observes the progress of operational processes, though it handles this data somewhat differently. BAM’s purpose is to create a rolled-up, read-only data view. CEP, in contrast, tries to infer complex events that can trigger follow-on actions. Both CEP and BAM funnel (as the figure shows) have large volume of events from the operational stack, reducing all that chatter to a smaller set.

The following table maps this stack to vendors. We consider the four major SOA vendors: IBM, Oracle, BEA, and TIBCO. BAM is omitted from the table; CEP is our focus.









ActiveMatrix Service Grid/Bus



AquaLogic BPM

Weblogic Integration

AquaLogic Service Bus

Oracle CEP


"Fusion" BPA Suite

"Fusion" BPEL Process Manager

"Fusion" Enterprise Service Bus

Oracle CEP (acquired from BEA)


Websphere Process Server, FileNet

Websphere Process Server, Websphere Interchange Server

Websphere Enterprise Service Bus, Websphere Message Broker

Coral8 (recent acquisition)

The operational stack supports a distributed architecture in which the activities of client applications and partner services, both internal and external to the organization, are coordinated by orchestration processes. Clients and partners communicate with these processes through the ESB. Internal connections typically use MOM queues to access the bus; external connections use SOAP over HTTP. The orchestration processes, besides coordinating partner activities, also interface with backend systems (databases, mainframes, and so on) and use BPM to delegate manual work to human actors. The following figure illustrates this architecture.

SOA Cookbook

CEP consists of a set of rules that listen for events from the bus. (A publish-subscribe messaging infrastructure allows CEP to get these events without disrupting the operational processes.) CEP rules, as we discussed above, infer complex events from these operational events. They send complex events back on the bus on orchestration queues, where, as we discuss further below, they are picked up and handled by CEP-aware orchestration processes.

CEP must be sufficiently scalable to handle the high volume of events on the bus. There is more to this than sheer processing speed. CEP, like most rule-based systems, is stateful. It keeps its state (i.e., its current set of asserted facts) in a datastore called Working Memory. For performance reasons, Working Memory should be kept in physical memory, and paged out to disk when necessary.

Using an RDBMS instead of memory would prove to be simply too slow and only a few commercial databases can handle updates at the volumes of events on a bus anyway.

This memory should be fault-tolerant, given the business criticality of CEP. Such an implementation is full of the sort of thorny performance design issues in which SOA vendors have the greatest expertise.

BAM works somewhat differently from CEP. Orchestration and BPM processes have state, and BAM uses this state, combined with business data from backend systems, to present a consolidated view of the state of the processes. For example, rather than tracking just order processes, BAM might also track the orders themselves, as they appear in the backend order system. In the previous figure, we labeled this piece as BAM/BI (for business intelligence), because most BAM implementations by themselves lack the ability to incorporate application data. Combining process state with application data often requires the combination of BAM and some sort of BI or analytics tool.

Whereas BAM merely presents a view of the system, CEP, by creating events that it has inferred from its observations, serves as an active participant. SOA platforms with CEP are self-healing; CEP watches what’s happening operationally and sounds up when it detects a significant occurrence.

The dotted line in the previous figure from CEP to BAM suggests that complex events created by CEP could be incorporated into the BAM dashboard. Thus, the BAM dashboard for the trading application could show statistics on completed orders or buy-aheads per broker. The mechanism by which CEP notifies BAM of complex events is implementation-specific.

The Contrasting Coding Styles of CEP and SOA

Today’s SOA application is developed as a set of event-driven processes. A process is driven by two types of events:

  • A start event, which creates a new instance of the process.
  • An intermediate event, which wakes up a pending instance.

In the BPMN process definition shown in the following figure (from the trade example we considered above), Broker Buy Request, shown with a circle with thin border, is the start event. A new instance of the process starts when this event arrives. Get Buy Order Response, shown with a circle with a double-lined border, is an intermediate event. After executing the step Submit Buy Order, the process waits to continue until the intermediate event arrives, and then runs Send Response. While waiting for the intermediate event, the instance is in a wait state. If the event fails to arrive, the instance remains in that state. (Our example is simple, so there’s no error-handling logic for this scenario.)

SOA Cookbook

A process also sends events. The steps Submit Buy Order and Send Response are known, in BPMN jargon, as send tasks. As we described above, these events are sent to, and trigger actions in, processes for the market and the customer respectively.

In SOA, the emphasis is on using events to drive control flow. The developer pays attention to the events themselves—which represent service interactions with partner processes—as well as to the overall flow of control (conditional paths, parallelism, error paths, and so on). Although most SOA developers were trained to write procedural-style code in a third-generation language like Java or C, when they started with SOA, they discovered that the required coding style was closer to that of workflow. Primary concerns to SOA developers are common workflow patterns for splits, joins, loops, and event choice.

With CEP, the key skill is business rules. The rule language of CEP is known as an event pattern language (EPL). An EPL rule consists of two parts: a conditional test to check whether a particular arrangement of events has occurred, and a series of actions to perform if the condition is met. The conditional test typically checks whether two or more events that have been received by the CEP system have a causal relationship, have they occurred in a particular time range, or they share specific message content. The most prevalent action is to create and send off a complex event. (State, including the current set of observed events, is held in Working Memory. In many implementations, the RETE algorithm is used to efficiently manage the conditional test. In this regard, CEP resembles most expert systems.)

Here is an example of the CEP rule to check for completed buy orders. In Luckham’s book, the rule is coded in the Rapide language, but here it is presented in informal pseudo-code:

BrokerBuyRequest(Security=S, NumShares=N, CustomerID=C, BrokerID=B)
BuyStock(Security=S, NumShares=N, CustomerID=C, BrokerID=B)
BuyConfirmation (Security=S, NumShares=N, BuyPrice=P, CustomerID=C, BrokerID=B)
BrokerBuyConfirmation (Security=S, BuyPrice=P, NumShares=N, CustomerID=C, BrokerID=B)

Generate BuyOrderCompleted(Security=S, NumShares=N, BuyPrice=P, CustomerID=C, BrokerID=B)

The test checks for a causal chain of four events:

  • BrokerBuyRequest: The customer’s request to the broker to buy N shares of the specified security S. The customer is identified by her ID C. The broker’s ID is B.
  • BuyStock: The broker’s placement of that order.
  • BuyConfirmation: The outcome of the order, including its buy price (the price per share of the purchase) P.
  • BrokerBuyConfirmation: The broker’s confirmation of the purchase back to the customer.

If and when this chain occurs, the rule generates the complex event BuyOrderCompleted, which specifies the details of the order (the security, the number of shares, the customer, and broker IDs) as well as the buy price. BuyOrderCompleted is an aggregation of four events referenced in the conditional test. The notion of “complex” in the term “complex event” is that of aggregation. BuyOrderCompleted is, in a sense, made up of the four events.

Testing for cause is a fundamental step in most CEP rules. In general, if event A causes event B, then B could not have happened had A not happened. Event A therefore occurred earlier than B, and A and B belong to the same overarching process. In trading, for example, A’s timestamp must be earlier than B’s, and A and B must refer to the same transaction (for example, they must reference the same transactionID).

In Luckham’s design, a special rule known as a causal map is what determines if two events are causally related. Every event has a special field known as the causal vector, which is a list of events that causally precede the event. When a CEP rule tests if A causes B, under the covers the CEP system checks if B’s causal vector contains a reference to A.

Initially the vector is empty. The task of the causal map is to populate the vector. The logic of the causal map is often rather intricate, considering that the map must handle events for different transactions simultaneously, perhaps in a different order than they occurred. We won’t study causal maps in this article, but suffice it say they must be fastidious in their housekeeping (particularly, they must use temporary data structures to keep a recent event history) in order to sort out everything cleanly.

As the following figure shows, a causal map picks trading events off the bus and populates their causal vectors before letting rules such as the one we just considered to test them.

SOA Cookbook

The next rules checks for a buy-ahead.

(BrokerBuyRequest(Security=S, NumShares=N1, CustomerID=C, BrokerID=B)
at t1
BrokerBuyConfirmation (Security=S, BuyPrice=P, NumShares=N1, CustomerID=C, BrokerID=B) at t2)
(BuyStock(Security=S, NumShares=N2, CustomerID=B, BrokerID=B) at t3
SellStock(Security=S, SellPrice=P2, NumShares=N2, CustomerID=B, BrokerID=B) at t4)
And t1 < t3 < t4 < t2 < t1 + 30 minutes

Generate BrokerBuyAhead(Security=S, BuyPrice=P, SellPrice=P2,
CustomerID=C, BrokerID=B, StartTime=t1, EndTime=t2)

The test considers four events:

  1. BrokerBuyRequest: Customer C’s request to broker B to buy N1 shares of a security. This event occurs at time t1.
  2. BrokerBuyConfirmation: The broker’s confirmation to the customer that the shares were purchased at the specified buy price P. This event occurs at time t2 and is caused by the first event.
  3. BuyStock: The broker’s placement of a buy order for the same security on his own account (CustomerID=B). The number of shares bought is N2, which needn’t be the same as, and is likely less than, the number of shares, N1, bought by the customer. This event occurs at time t3.
  4. SellStock: The broker’s sale of the N2 shares to his own account. This event occurs at time t4 and is caused by the previous event.

The final clause in the check (t1 < t3 < t4 < t2 < t1 + 30 minutes) specifies that all this activity occurred within 30 minutes of the customer’s initial order, and that the events occurred in the following sequence:

  • The customer’s request (BrokerBuyRequest).
  • The broker’s buy order for his own account (BuyStock).
  • The broker’s sale to his own account (SellStock).
  • The broker’s confirmation to the customer (BrokerBuyConfirmation).
  • If the condition is satisfied, the rule generates the complex event BrokerBuyAhead with details of two trades.

Notice the compactness of this rule. First, it considers two independent trades—the one the customer requested, and the other that the broker made surreptitiously on his own—simply by conjoining two causal tests with an “And”. Second, it does not need to consider all four events that make up the completion of the customer’s order; the rule is content to know that the customer requested the trade and that the broker confirmed it. The rule tests, in effect, whether a broker interleaved a trade for a customer with his own trade. It is able to accomplish this with a surprisingly small amount of code.


When CEP creates a complex event, the event is sent onto the bus. There’s no reason why an SOA process can’t pick up the event and process it. We’re tempted to think that SOA processes, through their event exchanges, bring about complex events, but there’s no reason why they cannot consume complex events as well. We might refer to such processes as being CEP-aware.

The following figure shows an SOA process that is triggered by a buy-ahead broker event. When it receives the event, which is generated from a CEP rule, it adds this occurrence to the broker’s employment record and checks how many previous buy-aheads are on the broker’s file. If the number exceeds a specific threshold, an investigation is started.

SOA Cookbook

The process shown above is designed specifically to handle a complex event. However there is another type of CEP-aware process - an existing process, which was not originally designed to handle complex events, but is later enhanced to do so. The process shown in the next figure is an example of this. It performs a performance review of a broker, but watches for a buy-ahead complex event during the review. If a buy-ahead comes, it stops the review and launches a separate investigation.

SOA Cookbook


CEP is not another of those pointless three-letter acronyms. On the contrary, CEP is a natural fit for SOA’s event-driven architecture. CEP’s ability to infer complex events has business value that makes the effort of adopting this complex technology a smart investment.

You've been reading an excerpt of:

SOA Cookbook

Explore Title