"How do we embed your Coral8 library into our application?" The question sounds simple enough, and we occasionally get it from customers evaluating Coral8. The answer, however, is a bit more complex.

Yes, it is possible to link the Coral8 server into another applications. But I want to make a bold claim here. The future of CEP is not about being a cool event processing library embedded into individual applications. The future of CEP is a shared, scalable, and reliable enterprise-wide server infrastructure.

This should not be a bold claim. Think back to my favorite analogy, databases. It's true that there exists a market for embedded database libraries. For example, SQLite is a nice simple library that can be easily linked into C applications. There are many others. But this market is dwarfed by the market for database servers. Oracle, DB/2, SQL Server, Sybase - all the common databases are typically not embedded into an application, but rather run on a separate server or cluster of servers.

Why is this the case? Let's come back to the CEP world, where the advantages of an infrastructure over a library are even more obvious.

Sharing

Let's start with sharing. Even though people typically start with one application, they quickly start deploying more and more. We have customers that have deployed dozens of applications by now! These applications all talk to each other via event streams. Moreover, these applications may dynamically deploy queries to each other. Rapidly integrating new applications is very hard if each application has to link in its own standalone CEP engine.

Scalability

What if the demands on a CEP applications grow, and a single server does not have enough CPU power to satisfy them? If the CEP engine is linked in as a library, there is not much one can do in this situation! On the other hand, a good CEP infrastructure can distribute event processing to multiple servers, balance the load, and satisfy the most stringent scalability demands.

Reliability

What happens if a CEP engine is linked in as a library, and the machine on which it runs dies a sudden death? Well, you've got a problem. You don't have another server standing by ready to take over. You can, of course, replicate both the application and the CEP engine on two machines, but you'll have to figure out how to synchronize the two copies, how to share state, etc. All these problems are already solved by a good server infrastructure product such as Coral8.

But wait...

So why do people even consider linking a CEP engine as a library? There are a few reasons, but they are somewhat misguided:

First, some people don't like the idea of starting a new process for a CEP server. While I sympathize with this sentiment, the price of starting a new process is usually not that high. Complex applications these days have many parts, and always never reside in one process anyway.

The second reason sounds more serious: latency! People think that if their application has to send events to a separate server, and then receive results back, the total processing latency will be a lot higher. Thus, they want to link the CEP server into their application.

This sort of makes sense, except for where do the events come from? In most cases, they don't come from the app, but from some third place: from a financial exchange, a web site, a sensor network, a message bus, etc. The right solution is not to send these events to the application, but directly to the CEP engine! Good CEP engines come with highly optimized adapters, some of them running in the process of the CEP engine itself. These adapters can process incoming events much faster than whatever an application can do! We have seen how some Coral8 adapters can process events in well under 100 microseconds! Why would an application want to re-implement these adapters? It makes little sense.

Finally, the third reason may be more emotional than anything else: Control. Some developers feel that if the engine is "just a library", they have more control over such things as threading model, memory management, and so on. Well, again, why would somebody want to worry about these issues, when CEP vendors spend years and years optimizing the performance of the CEP engines?

The CEP Cloud

I hope I've convinced you that the future of CEP belong to server-based infrastructure rather than CEP libraries. In fact, we have customers today who don't even care about our performance on a single server. They have a vision of running a cloud of CEP servers, and deploying hundreds and thousands of applications on this cloud. Of course, the cloud of these servers has to be completely self-managing. One does not need to worry about which server or servers are running a given app at any given moment, what happens when demand changes, what happens when servers go down, etc. We like this vision a lot. This is our vision, too. You just can't realize this vision via a simple library.

Mark Tsimelzon
President & CTO, Coral8