Friday, September 26, 2008

SOA and EDA

So far I've posted a large amount of material on SOA, pushing very heavily for an event driven approach - with specific attention to business services, where business-relevant events are surfaced as event messages published over a service bus.

There has been an ongoing discussion in the public forum around the relationship between SOA and EDA (Event Driven Architecture). Are they in fact separate architectural styles? Are they separate concerns? Do they complement each other? Does SOA subsume EDA?

SOA and EDA are in fact separate architectural styles. However they describe different concerns of an architecture. They each bring their own benefits. As such, it is possible (and in fact good practice) for the two styles to overlap. An architecture can indeed both be service oriented and event driven. Likewise it is possible for an architecture to be service oriented but not event driven, or event driven and not service oriented. This is illustrated below.


An architecture consisting of services with no endpoints with a publish-subscribe binding conforms to the service oriented style of architecture, but is not event driven. An architecture consisting of messages published over topics, but where there is no notion of services is event driven, but not service oriented. For example, EAI can be achieved by having a number of applications publishing and subscribing over a set of topics, without explicitly defining any services, endpoints or service contracts.

Where SOA and EDA come together, a topic corresponds to a specific endpoint of a specific service. A topic cannot be shared between endpoints or services, and messages published onto a topic must conform to an explicitly defined service contract. SOA brings benefits to EDA and vice versa. Therefore we get the best result when the two architectural styles are combined.

7 comments:

miguel said...

Hi Bill,

Hope I'm not annoying you being the only person who posts comments.

I've been reading furiously trying to get some clarity on this issue and I don't seem to be getting it so I thought I'd post the question to you and all the readers in the hope that a consesus position or better argumentation may result from it.

Is EDA really an architectural style, like SOA, or is it an implementational style? More like a counterpart to REST over HTTP?

I think it could be the latter as I envision EDA being/requiring a more dynamic implementation, but both essentially trying to guarantee the same sorts of properties (deterministic/atomic/facilitates activity monitoring...)

Any thoughts? Am i way off the mark, err, again.

http://www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html?page=1

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

http://soa-eda.blogspot.com/2006/11/esb-as-global-dataspace.html

Bill said...

Hi Miguel,

EDA is indeed an architectural style. It refers to a style of architecture where distributed components communicate by way of publishing and subscribing to events.

A service oriented architecture is event driven as well if it has services with endpoints leveraging bindings with publish-subscribe channels.

Where the SOA and EDA styles combine, you would have either event driven SOA or service oriented EDA I guess. :-)

There are many different transports that support publish-subscribe message exchanges. So in that sense it isn't like REST over HTTP.

REST (like SOA and EDA) is an architectural style. Indeed HTTP is an implementation choice for REST. EDA however doesn't mandate a specific transport. A good comparison might be EDA over MQ Series.

Since EDA is not a transport, it wouldn't make sense to say SOA over EDA.

Furthermore, there are certainly event driven architectures around that are not service oriented. And in that sense, EDA is not simply an implementation style of SOA.

Cheers,
Bill

miguel said...

Thanks for the reply dude,

I may well still be confused! It goes like this --> I have a service that is called explicitily from the ether (as opposed to listening to an event on bus x/y/z) but to then perform its little business functionality the implementation of the service logic leverages MPI.NET, which calls do get placed on a bus/broadcast by MPI and is therefore Event Driven. So when the call on one processor gets broadcast all listening processes on all participating processors wake up and do something.

So is this SOA not involving EDA AND EDA not involving SOA sitting together? I.E. in this case are both architectural styles being employed, but not bridged? So not SOEDA?

The reason for labouring on this point is that having written a largish MPI application before I am fairly confident on EDA but SOA gets me everytime! I swear I can't get a straight answer on SOA as an architectural style but only get vague representations about delivery outcomes/ agility promotion/ business unit atomicity. I'm pretty sure none of those things are Architecture! Maybe my brain is stuck on engineer.

Please help :)

nickysam said...

Companies face large numbers of complex events daily, and responses are expected in real time, so building a communication model to exploit the power and flexibility of an event-driven SOA is a high priority for software development and IT professionals.An ESB is generally the way service requests move on an SOA as messages. An ESB guarantees that the message, whatever it may be gets delivered from consumer to service.
-------------
Nickysam

viral marketing

Bill said...

Hi Miguel,

Another awesome question! I've posted my response here.

Cheers,
Bill

Bill said...

Hi Nickysam,

I completely agree with your comments, except your last statement...

Published messages are delivered from service provider to consumer, not the other way around.

Cheers,
Bill

Anonymous said...

Can I left a comment ? Thanks



thiet ke nha
nha xinh
duong vat gia da nang