CEP as the EDA Application Server?

Reading Time: 2 minutes

One of the common questions for Technical Architects today is whether any particular application should be implemented as conventional, orchestrated, BPM-SOA , or as a (relatively and disputably) new EDA. At TIBCO we feel the world is a little more “grey” than the terminology suggests: for example:

  • is an EDA event that invokes directly some behavior just acting like an SOA service?
  • is an SOA invocation event just a somewhat special type of event?
  • is a CEP application that devours events not just a particular type of service?
  • etc etc.
    .

In the SOA world (and indeed before the term “SOA” became fashionable), application servers become the Good Thing to use (with the usual caveats about complexities of languages like J2EE) – allowing normal single-user applications to be redeployed (or per usual, redeveloped) for multi-user client-server / n-tier use. Indeed, the pre-SOA world was pretty much awash with 3-tier (GUI – app server – DB) applications. And all was well, except that the app server applications could benefit from other componentization such as for their business logic, and of course the database is really just another type of service (i.e. for persistence). So SOA was born.

In a parallel world, companies like TIBCO have long been preaching about the benefits of distributed applications, based on the early work on the TIBCO Rendezvous (RV) high performance middleware, where applications have survived pretty well without the complexities of application servers. True value for application containers comes from added value concepts like virtualization, fail-over, policy management enforcement etc etc (and thence technologies like TIBCO ActiveMatrix). At the other end of the scale, some of the events required too much correlation for conventional database-transactional processing, and the concept of CEP was born (with tools like TIBCO BusinessEvents).

Consider that general CEP tools are designed to take a wide variety of event types, ascertain patterns in the events by type, attribute, time (or any other dimension you can compute), derive from these more business oriented events, and thereby take appropriate actions (including invocation of any BPM processes or SOA application services) [*1]. You can add new event channels, filter (rules), situation assessment rules, track and trace states, and sense-and-respond rules as required. In effect, the CEP tool plays the role of an event-feed / EDA “application server” – except you share the object model / ontology and can simply deploy new rules / states as required [*2].

But perhaps the term “application server” is old-hat nowadays. We need to simply use the appropriate service container for the service we want to execute. Tasks like workflow, transactional services, and complex event processing all benefit from the bespoke characteristics of their servers.

Notes:

[1] You could also view (/use) this as a sophisticated “event router” for driving your processes or services.

[2] Although a better term might be “Event Decision Server“.

Previous articleCEP vs the hype cycle
Next articleForthcoming CEP content
Paul Vincent is the former CTO for Business Rules and Complex Events Processing at TIBCO. He has been applying rule engine technologies for over 20 years in financial services, government, defense, and manufacturing. He is a contributor to the OMG and W3C standards on rule and decision modeling and interchange, and to the Event Processing Technical Society.