I love Pat Helland. The guy is a luminary. He explains the issue of latency in service-oriented architectures with an analogy of light traveling from the sun to the earth. By the time the sunlight shines on us, it is eight minutes old. So it might not reflect the current state of the sun (the sun might've blown up during this time, for example).

Likewise, by the time we receive a piece of data from a service, it might have changed at the source. But unlike sunlight, messaging in service-oriented architectures is often two-way. If the data we requested was changed before our response gets processed, our response is probably invalid. And that's life; our system has to deal with it. Of course, this problem is not new. It's a common side effect of optimistic-concurrency.

But making the pronouncement that "SOA is like the Night Sky…" is sure way to stoke your critics. And old Pat takes a bit of heat in his comments for re-branding old ideas. SOA is currently going through the negative hype phase common to any paradigm shift in software development.

Since I'm currently enamoured with SOA, I pulled my copy of Principles of Transaction Processing off the shelf to check how much of SOA was actually covered in 1997. It comes down to this: many (but not all) principles of service-oriented architectures are a subset of transaction processing principles. Specifically, they are the principles of queued transaction processing.

In an SOA, transactions do not span services. That is, there are no distributed transactions. But for a system comprised of a collection of services, a logical unit of work will often use more than one service. So how do we perform a logical unit of work in two or more services without using a distributed transaction? The answer is queuing. Queues allow us to perform a unit of work that includes more than one transaction (a multi-transaction workflow).

With queues, an SOA forgoes atomicity and isolation (two of the ACID properties) to gain scalability and reliability.

So it's a tradeoff. In Pat's defense, these concepts are not entirely new, but this is not a tradeoff many of us would have considered as we designed our systems and made the obligatory genuflection to the altar of ACID transactions. But as he says, "it's the only possible computing model in a loosely-coupled and distributed world."