Event Driven Architecture

EventDrivenArchitecture (EDA) is a distributed information systems architectural style complementary to ServiceOrientedArchitecture (SOA). It was arguably coined by the GartnerGroup?'s RoySchulte? in the late 1990's.

EDA has the following characteristics:

events consist of data associated with a business-relevant incident.events have a well-known representation and shared meaning across software processes. (e.g. they can be XML-based and have an associated schema).
software processes are completely decoupled from each other.processes only depend upon events.
Events are published in a standard, consistent manner to a well-known destination. Software processes then, autonomously, can observe or subscribe and react to different types of these events, or different contents of events, etc.
Interactions among software processes are predominantly asynchronous; events are published without exepectation of immediate response.

EDA is similar to ServiceOrientedArchitecture (SOA), in that they both apply PrinciplesOfObjectOrientedDesign that remain relevant to a broader set of distributed information systems. In particular, the DependencyInversionPrinciple (aka InversionOfControl) is paramount. SOA defaults to a request/reply, or synchronous interaction model, and thus tends to have a higher degree of coupling than EDA, though the lines can get blurry once you start considering one-way and/or callback MessageExchangePatterns?. Both approaches (SOA and EDA) are considered complementary, and often one architecture is considered a subset of the other, depending on the point of view of the architect!

It's important not to split hairs about what is EDA vs. SOA, except to realize that they both evolved from different cultures and infrastructural disciplines, but have come to embrace similar principles. EDA evolved from the MessageOrientedMiddleware (MOM) culture) with implementations such as TIBCO/Rendezvous or MQSeries, whereas SOA evolved from the DistributedObjects culture with implementations such as CORBA or COM. Both seemed to learn a lot from each other.

Articles

See "Event-Driven Architeture: Event Web Building Block" at http://www.developer.com/design/print.php/3499031

Terminology for the two frameworks are

It was said in traditional SOA implementations, subscriber (the decision maker) ask for relevant information, whereas EDA implementations the publisher seeks the attention of the subscriber for taking actions on relevant information.

According to the same authors, who went on to comment in "Event-Driven Architecture vs. Publish-Subscribe Systems" (ref http://www.developer.com/design/print.php/10925_3499031_3), there are four considerations that current day push technology implementations are lacking:

sophisticated subscriptions (e.g. no "model based" subscriptions)
evolving networks (current networks do not have a "mind of its own")
structured events (lack structure in information)
ubiquitous standard (current implementations are proprietary)

It could be possible that BusinessProcessManagement type initiatives (e.g. BPEL) have shown SOA infrastructures are by themselves insufficient to provide business agility. There need to be additional orchestration mechanisms. Events in that sense are closer to transactions than the "autonomous services" in an SOA implementation, and can be better understood by BigIron clients with CiCs expertise.

I cleaned up the EDA definition above and made some general edits to the comments.Feel free to critique, but please, no whinging about the Gartner group usurping normal terminology. It happens all the time, live with it. -- StuCharlton.

CategorySoa