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:

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


See Also: EventDrivenProgramming, StaleEvents
CategorySoa

EditText of this page (last edited November 27, 2005) or FindPage with title or text search