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“.