The Unfrozen Caveman Engineer

Ramblings and Pontifications from the world of MBF

Transaction Processing in an SOA World

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!   

 

Published Friday, February 13, 2004 2:34 PM by timbrookins

Comments

 

Mehran Nikoo said:

I agree with what you said. However, I would argue that SOA is just about transaction processing (in most cases it is but they don't have a statis realtion)

The reason I am mentioning this is that if you say SOA is related to Transaction Processing systems, then you expect the same features e.g. ACID characteristics. You cannot expect ACID characteristing when your application spans multiple applications/platforms. Although you could be lucky for using compatible components e.g. MSMQ and SQL Server, which both sopport DTC and 2PC.

In most of distributed and long-running processes, you cannot expect the "I" which stands for Isolation. This is not a technology problem, this is the defnition of "Isolation". So when coming to an SOA world, we are changing the way we look at applications. We are also setting new expectation levels (e.g. we can't guarantee to keep this record locked until you come back from holiday!). That's why we should differentiate between a traditional transaction processing system and a system based on SOA.

Trying to use more advanced technology may help, but that defeats the purpose of SOA.
February 28, 2004 9:52 AM
 

Tim Brookins said:

Yes, I agree. That is what I was trying to communicate. We've been building applications for many years with an assumption that we can rely on ACID. Now moving to SOA our traditional ACID tools are gone.

Some things (like isolation) just have to be reduced, and the application needs to be built with that in mind. Other things (like Atomic) still need to be there for an SOA application. We can't rely on SQL Server transactions, so we need other mechanisms to ensure atomic behavior (reliable messages with perhaps some compensation code).

Loosing ACID is a "big deal" for business applications. It is going to take alot of architecture and design work to come up with new techniques for building applications in the new SOA world.
March 2, 2004 1:54 PM
 

BrianG. said:

People have been building SOA applications for years... Years ago these were called mainframes and jobs were essentially submitted for processing using a message based architecture using JCL.

XML is just the lastest version of JCL and SOA is the latest batch processing technique. The primary difference between yesterday and today is scale and complexity.
March 29, 2004 6:18 PM
 

Jeff Talley said:

It is trite to say that XML is just the latest version of JCL or that SOA is just the latest batch processing technique. While these things may build on such technologies and while professionals from mainframe environments certainly have a lot to contribute, these are not the same things. JCL is not platform independent and SOA enables an entire "ecosystem" of disparate systems that work together as a whole - something much more highly evolved than any batch process one might imagine.
March 30, 2004 6:06 PM
 

Nikhil Kumar said:

I tend to disagree with the proposals placed here. SOA involves the usage of Transaction Processing to provide guaranteed delivery/execution of a semantic request, but it is a lot more than just the guaranteed delivery of data. SOA is a remote invocation of a service, accompanied with all the components associated with it. It is more a realization of the old Component concept, with the use of asynchronous mechanisms underneath.
April 27, 2004 9:59 PM
 

Jeff Talley said:

Nikhil: I like your description and think it is consistent with many of the "proposals placed here". With what, exactly, do you tend to disagree?
May 6, 2004 8:29 PM
Anonymous comments are disabled

This Blog

Syndication

Tags

No tags have been created or used yet.

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker