Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Miko Matsumura on Aug 16, 2006
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.
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
EDA is an implementation style (software architecture) in the same way as REST or RPC are implementation styles (software architecture). 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.
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.
In my mind services and events are related but not alternatives and I do not think that mentioning one as a better form of the other (which is subliminally implied since it's in the famous upper right corner) is helpful.
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 is going to become much more prevalent in the coming years, but only for certain types of applications. It is a great way to support state machines, particularly in distributed architectures (SEDA). It is also handy for breaking up problems that have been traditionally impossible to implement transactionally, just due to the overall scope of the transactions (too big, too long). I for one am very excited about the EDA field, and some of the related fields (AI, agent-based programming, etc.)
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
This discussion reminds me of the debate about SOA and BPM. Clearly taking an SOA approach makes it easier/more effective to use BPM to build process automation and composite applications. Equally SOA provides a great platform for EDA or Complex Event Processing. Making functionality availble as services and thinking about how to manage them, control them, version them etc etc will make it much easier to use that functionality to handle events or to be part of a process.
JT
Enterprise Decision Management Blog
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.
Cameron, would you care to elaborate?
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....?
It's actually quite difficult to compare the 2 approaches without specific use cases in mind. I spent a few years on BPM systems (mostly BPML/BPEL engines), and for 2 years I've been working for investment banks, with a very high volume requirement (we're talking between 2K and 10K messages per seconds).
Usually the case is: a stream of events is flowing, you need to filter them, then extract the relevant information and store it somewhere (usually in memory as databases don't provide enough throughput, I actually used Cameron's tool - Tangosol Coherence - to distribute the cache with amazing performance). Based on the events coming in, you apply a set of rules that changes the overall state of the system, and trigger other rules (until you reach a stable state - after a complete inference). Usually, CEP engines (Complex Event Processing) have the concept of state machines - unlike a process, the graph is not "driving" the actions, the transition between nodes is a reaction to the outside world.
There are 2 programming styles:
- Process: procedural
- Events: inference (?)
Basically, in the programming world, it would be equivalent to traditional programming versus AOP. When the overall system is impossible to describe, that you need to correlate event together (lots of synchronization points between many processes), and you can think in terms of simple units of work that can be prioritized, then EDA is usually a good fit.
I worked in 3 projects using CEP platforms. In finance for example, you can apply EDA concepts for:
- Program trading: the system receives thousands of price tickers per second, and maintains a portfolio of positions. As the tickers flow, algorithms can decide whether a buy or sell action should happen. Based on the result of this action, other positions in your portfolio might be impacted.
- fraud detection: thousands of transactions per second, and an unusual pattern is detected - similar transactions in australia and the US for 2 different credit cards owned by the same person
- Non intrusive monitoring of high volume systems, by wire-tapping
- etc.
Cheers,
Tanguy
event-driven architecture is broader than its relationship with SOA, including real-time information flow and analysis, and complex event processing. Here's an excerpt of my event-driven architecture overview paper.
I recognize a huge business potential of asynchronous, event oriented design. And I believe that EDA by its nature will be the paradigm to realize the ultimate alignment of business processes and the supporting IT-systems. I think that the ultimate layer between our real world events and artificial application constructs will be an EDA. And I recognize the possibilities offered by the current IT-technology evolutions to support this paradigm.
See my thoughts here...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
9 comments
Watch Thread Reply