Transactions Between Services? No, No, No!

I've just read Juval Lowy's article entitled "WCF Transaction Propagation" in the May 2007 issue of MSDN magazine.

Juval opens the article by saying:

Transactions are the key to building robust, high-quality service-oriented applications. Windows^® Communication Foundation provides simple, declarative transaction support for service developers, enabling you to configure parameters such as transaction flow and voting, all outside the scope of your service. In addition, Windows Communication Foundation allows client applications to create transactions and to propagate them across service boundaries. [Emphasis added by me]

So you've spent all that time toiling and sweating to create loosley coupled and autonomous services and there comes a propagated transaction and invalidates all your efforts. I don't think that WCF transaction propagation is necessarily a bad thing in itself. I am sure it has its uses -- but not in the context of SOAs.

Consider, for example, what Don Box said back in 2004:

Boundaries are explicit. A service-oriented application often consists of services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments. The cost of traversing these various boundaries is nontrivial in terms of complexity and performance. Service-oriented designs acknowledge these costs by putting a premium on boundary crossings. Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation. Compared to distributed objects, the service-oriented model views cross-service method invocation as a private implementation technique, not as a primitive construct—the fact that a given interaction may be implemented as a method call is a private implementation detail that is not visible outside the service boundary.

Do you really want to flow transactions between "services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments"? I know I don't. Things get even worse when we consider that service consumers can be from external parties? Do you want to lock resources within your organization on behalf of a request coming from a someone else? As a competitor, I've just found a way to introduce denial of service to all your systems -- I'll just open a transactional call and never close it.

Cross service transactions are a sure way to introduce coupling and performance problems into your SOA.

By the way, using distributed transactions is not something you should use lightly even if your architecture is not SOA. As Martin Fowler said (commenting on Ebay's architecture which is transactionless):

The rationale for not using transactions was that they harm performance at the sort of scale that eBay deals with. This effect is exacerbated by the fact that eBay heavily partitions its data into many, many physical databases. As a result using transactions would mean using distributed transactions, which is a common thing to be wary of.

I guess that making it easy to flow transactions between WCF web services is another perfect example for what I meant when I said "Microsoft has too often given us enough rope to hang ourselves by providing ways for the inexperienced to easily build solutions that will make them suffer down the road".

Finally, note that transactions can be put to a good use within SOA -- only if you use them inside the services as a way to handle a message in a reliable manner (a pattern I call "transactional service").

Posted by Arnon Rotem-Gal-Oz at 05:12 AM  Permalink