Event Driven Architecture
Event Driven Architecture (EDA) is a style of software architecture based on real time flows of (you guessed it) events. EDA is a buzzword was being pushed by Gartner as far back as 2003. At the time, Roy Schulte of Gartner went so far as to say that in SOA, connecting services occurs in a linear, predictable sequence, whereas an event-driven architecture allows for multiple, less predictable, asynchronous events to happen in parallel and trigger a single action.
Not that many folks got excited about EDA as a buzzword (most seem to think it's just part of SOA), so Gartner Analyst Yefim Natis teamed up with Oracle to coin the phrase SOA 2.0 (which appears to be another way of reintroducing EDA) another term which got a few folks excited, but not in a good way. Despite the criticism (Mark Little of JBoss posted a notable criticism), EDA enthusiasts continue to develop architecture.
Whatever it is ultimately called, dynamic real-time systems involving the integration of services will continue to be of interest to SOA practitioners. An excellent article about Event-Stream-Processing tools (ESP)is provided here. This article states:
ESP enables an event-driven SOA to decipher causal (if A is followed by B followed by C), temporal (within four seconds), and spatial (within 10 feet) relationships among events - and can do so in real-time. This kind of "enterprise wiretap" lets a business continuously analyse key performance indicators in real-time, identify threat and opportunity in real-time, and act instantly. These capabilities require a new style of computing - stream computing - that can deliver the missing link between an event-driven SOA and real-time business insight.
The introduction to the article is savvy enough to point out that existing terms such as SOA and Enterprise Service Bus (ESB) are capable to answer these needs, but the article goes on to describe a well researched set of concepts that are in application at some large companies. Another article details how to implement EDA using Mule, an open source ESB.
EDA is part of SOA...
Going beyond EDA to agent and goal driven systems is just another implementation option for SOA, what doesn't change is the Service in its abstract sense or the need for services to communicate or distribute information.
The question is whether SOA = RPC and technology or whether SOA is a bigger shift at the true architectural level (pre-sofware). I'll go for the later. Taking the OASIS SOA Reference Model as a base definition there is nothing that procludes agent, EDA, RPC or winged monkey implementations at the software level.
eda vs soa
Joost de Vries
A service can have input, output, preconditions and effect and is between clients and a provider. Some services have effects and thus when executed cause a state transition. Messaging is on a logical level between designated parties.
At the moment an event is visible in the integration space it is the effect of a state transition. This notification can be input or output from a service. An event is not related to it's provider or it's handler. Messaging can be multiplied to many handlers.
If a problem space is more about things that happen and taking action the matching architecture can be called EDA, if it's more about business goals and clients and a provider the matching architecture can be called SOA.
EDA, yes, but not for everything
Tangosol Coherence: Clustered Shared Memory for Java
SOA enables EDA just like it enables BPM
Enterprise Decision Management Blog
Re: EDA is part of SOA...
However SOA is an architectural style that aims to think of business and technology as services and enable the right selection of the implementation mechanisms. Which could be events, messages, RPC, winged monkeys, shouting or anything you want.
I want shouting winged monkeys, please.
Re: EDA, yes, but not for everything
Joost de Vries
If I understand correctly SEDA is a form of pipes-and-filters architecture with load-balancing routing. I can imagine this is an interesting approach for workitem- or order-oriented functionality. Every stage delivers products of a certain status and it does not matter which unit consumes the 'half-fabricate'. I'm not sure wether this really equates to an event since only one party consumes the item, while event notifications seems to me to be inherently to be noticed by possibly many parties....
You mention EDA as a solution for transactions that are too long-running or too big. What does EDA offer (and how?) that orchestration does not?
I wonder wether EDA and transactions are really related; transactions are about the steps that should take place as parts of a larger step, it's imperative and quite procedural. Events are loosely coupled and the step that causes an event does not care about which step takes place as a result. Aren't events and transactions orthogonal....?
EDA and SOA are complements...
The Final Layer
Jack van Hoof
See my thoughts here...