A Comparison of Service Oriented Architecture (SOA) and Event Driven Architecture (EDA)

  • [アーティクル]

I was in a conversation with one of my clients the other day when he casually asked me, “So what are your thoughts on the question of SOA vs. EDA?”.  My blank, uncomprehending stare caused him to continue by explaining that representatives from a large “research and advise” firm that I shall not name had been talking to them about their enterprise architecture and seemed to think that they needed to strive for an EDA capable platform, not “just” SOA.  He referred me to a document that had been written by a couple of fine fellows from this firm, which I read and was the inspiration for this blog.

 

Asking which is better or even which is better under which circumstances, seems to me to be like asking which is better: a) Democracy or b) Capitalism?  Neither has anything to do with the other.  About the only similarities that I could argue that SOA has with EDA are that a) they are both badly named (although I will definitely agree the SOA is a much less informative name than EDA) and b) they are not architectures but rather design paradigms.  They are intended to address totally different parts of the problem space and both, either or neither can be used simultaneously in any given “System”.

 

I have said previously that the purpose of SOA is to enable the Manageability of System Complexity; as far as the definition of SOA I think the closest we can get is the generally accepted “Four Tenets of SOA” as proposed by Don Box:

 

  1. Boundaries are Explicit
  2. Services are Autonomous
  3. Services share Schema and Contract, not Class
  4. Compatibility is based upon Policy

 

You will notice that nothing what so ever in the above refers to RPC, calls out the cardinality of the Message passing nor defines any responsibility for determining message routing at either the client or the “service”.  It says nothing about either the holding of state nor the delivery of messages.  All that we are saying is that the boundaries between sub-parts of the system are clearly defined and loosely coupled, the definition is entirely in terms of the Message that is passed across the boundary.  There is no dependency between components other than compliance with the Message format and Contract that defines the exchange.  Any component (either in existence at the time of the creation of the system or subsequently built) that will supply and/or consume such messages in accordance with the explicit policy will be able to function in the system as a whole.  There is absolutely no requirement here for SOAP, XML, RPC or any “predefined” Message routing – these certainly MAY be defined by the Policies and enforced in the Contracts but they would represent one possible implementation of Service Orientation, not Service Orientation itself.

 

EDA is all about Message routing, part of the system that SOA says nothing what so ever about.  There are basically two methods of defining message routing; it can be predetermined – flow based – such as you might see in a traditional, client server type application, a “new age” BizTalk Orchestration or even a “prehistoric” Mainframe JCL job.  If it is not predetermined then it must be evaluated at runtime based on the content of the message or events that occur during the system operation, you might see this in an Email System, a Pub-Sub architecture or Windows itself.  The later is required in EDA.  You could think of Windows programming as the classic Event Driven Architecture – you have lots of subsystems all sitting around doing “nothing” waiting for messages to get dropped into their message loops after which the spring into action to do “something” and may then post messages to other message loops based on what was in the message they received.  It is of course quite possible (even perhaps quite normal) to see systems that are hybrids of these two.  So flows are predetermined because they can be, where as others are not.

 

If you have a system that respects the above tenets but uses only predefined message flows then you have SOA but do not have EDA.  If you have a system that does not respect the above tenets but “reacts” to messages that are sent in response to “events” and may be routed in different paths depending on their content, then you have EDA but not SOA.  If you have a system that reacts to events in order to send messages in non-predetermined paths in a manner that respects the above Tenets then you have SOA and EDA.  If non-of this applies then you have neither SOA nor EDA.  It really is that simple!

 

I once designed an Order Management System that would was both Event Driven and Service Oriented.  Basically a collection of “Services” sat on the perimeter of a communications hub.  As each Service acted on the Order (perhaps by pre-authorizing the billing, or by checking available Inventory), if it altered the state of the order in any way it would raise an event that would say so.  Any service could subscribe to this event and supply a filter which would be applied against all changed orders.  If an order had changed such that the given filter recognized it as “interesting” to that service, then the service would be notified, it may then act on the order itself and may or may not change the order, repeating the whole process.  Why design a system this way?  Well by respecting the rules of SOA we gain the manageability of what will fast become a very complex system.  Sub-parts can be added, removed, changed or moved quickly and easily.  By making the system Event Driven we completely decouple each “service” from each other – each acts upon the Order(s) when it determines that it needs to.  Thus when the business process changes there is no complex altering of Routing and trying to squeeze in new “services” or eliminate existing ones (perhaps under only certain circumstances).  The system is both Flexible and Manageable.

 

Is there a down side?  Well complying with SOA in this case makes certain efficiencies harder to incorporate.  Because each of the services had distinct and well respected boundaries, one service can not leverage the internal state or another in its decision making except by caching already known results.  Adding the caching provided the performance required, but definitely added to the development complexity (I have said before that SOA does not reduce complexity, it merely strives to make it manageable).  Making it Event Driven made it tremendously flexible, message routing was determined entirely at runtime and could be customized for each individual order.  The downside is that there is no easy way to predict any given message flow so it adds to the testing burden.

 

I really think that the confusion over what is and what is not Service Oriented stems from people’s preconceptions of what is meant by the extremely overloaded term “Service”.  I have said many times in the past that Service Oriented Architecture is an extremely poor name because it is really not at all descriptive of what it really is all about.  I can’t do anything about the flavor, if you don’t like it you won’t like it, but I hope this blog may have made the Alphabet Soup just a little less murky.

Comments

  • Anonymous
    January 24, 2005
    Nice article

    I do feel that the observation on SOA and efficiencies is a bit off ( :-) ) because much of that can be addressed by having the proper granularity of services

    Consider a business that has customers - and customer service, forecasting, billing, and other applications - obviously there are the enterprise 'business' services such as billing - what often is overlooked is that one can argue that there are meta-services in SOA, such as 'customer', which turns a customer key (name/id/etc) into a customer business object for the consumption of other services.

    I agree with Don's tenants, but often find myself arguing that there's another - 'Services are composable'