Loose coupling versus decoupling ...

Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog.  He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related.  In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations."  I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects. 

There is a great book on this topic entitled "Software Fortresses" by Roger Sessions.  Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging.  In the book, one of the golden rules is "never let transactions cross software fortresses."  I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion.  This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture.  Aren't we to just make a Web Service call when we want to leverage components in other systems?  Roger says - just because you can doesn't mean you should.  Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA.  The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model.  The former decouples the applications and the latter couples them - albeit loosely through Web services. 

Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily.   Progress chose this decoupled model for the design of our integration backbone, Sonic ESB.   As a result, applications integrated with Sonic ESB are naturally decoupled.  This means you can shut down any application without impact to the overall operation of the other applications.  Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online.  Now this is very different from other ESBs on the market or available through open source today.  These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding.  I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects.   If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example.