My previous post asserted:

Don’t get me wrong… SOA doesn’t exist today.  The current “state of the art” is exactly duct tape and bailing wire.  But SOA <will> exist in the future, and when it does it will drive a tidal wave of change through the “I built my own client\server toolset” crowd.

This assertion generated some good discussion around the maturity level of SOA.  Some folks argued that they've been building SOA applications for many years, while others agreed that SOA is more of a vision at this time.

It all depends on your problem space.  SOA is about decomposing large monolithic applications into fine-grained, autonomous applications which communicate via an open protocol.  Someone could probably argue that they built DOS-based SOA architectures 20 years ago by splitting their single application into multiple TSR's (Terminate and Stay Resident) modules which used interrupts to communicate!

This blog is focused on business applications.  Business applications live and die in the transaction processing world.  In this context, any judgment on the suitability of an SOA architecture must be in terms of its support for transaction processing.

I certainly don't have space to give a full backgrounder on transaction processing (Jim Gray's classic transaction processing tome is >1000 pages!).  But the essence of transaction processing is the ability to accomplish a unit of work in a multi-user environment.  The fathers of relational processing created a set of principals labeled “ACID“:  Atomic, Consistent, Isolated, and Durable which together form the foundation for modern transaction processing systems.

Relational systems implement ACID semantics with several key pieces of infrastructure.  The lock manager provides Isolation.  The log provides Durability and Atomic behavior.  Referential Integrity, along with locks, assure Consistency.  The sophistication of these facilities has grown over time.  For example, lock managers have moved from simplistic page locking algorithms to row locking with sophisticated escalation heuristics. 

So now we want to take our monolithic business applications and split them into fine-grained autonomous services.  How do I coordinate a unit of work across several services?  My tried and true relational ACID capabilities are now gone, and they are replaced by....  XML and Webservices?

I'm sorry... I love XML and think WebServices are great.  But they are not even close to a replacement for ACID semantics.  This isn't a damnation of SOA, it's just a recognition that we've got a ton of work to do! 

This work is happening across Microsoft.  The Indigo team is hard at work implementing reliable messaging.  This is a key piece of infrastructure for “D“urability.  They are also working on WS-Transactions, which goes a long way to providing Atomic semantics.  The BizTalk team has a role to play as well.  Processes will be a key player for providing Isolation and Consistency in the absence of low-level data locks.

And last, the MBF team has a role to play as well.  Application developers spent the last decade developing best practices and proven approaches for building client\server applications.  The shift to SOA will require a totally new set of approaches.  For example, in the client\server world I could enforce referential integrity between order and customer by writing one line of declarative RI.  Now order and customer are in different services... you either have to implement an asynchronous “is it OK if I delete this record“ protocol, or you have to change the application to simply never delete records.  Either one is a profound change to how business applications are built.

The Microsoft Business Framework will build upon the work from the Indigo and BizTalk teams, just as historical client\server toolsets built upon core relational ACID semantics.  Let's get going, we've got a lot of work ahead of us to make SOA-based transaction processing a reality!