Wilfred Thinking Aloud

The Seven Stages of SOA Asceticism

If there is one severe risk in the SOA space, then it is probably the chance that people expect SOA to be a free ride. They assume that your architecture will transmogrify into a Service Oriented Architecture, as long as they have the right middelware and tools.

That, of course, sounds too good to be true. And it isn't. SOA doesn't come for free. SOA does not automatically fit into the existing architectures, and getting it right requires dedication and a contemplating lifestyle in which you refrain from some of the worldly pleasures introduced to the Software Development community in the past.

(Uh, well, I'm not sure there are exactly 7 stages of course - there are probably more - but 7 just sounded right.)

1. Refrain From I in ACID

If you have been working in a distributed object computing world, then you probably already know the meaning of the ACID acronym; it means Atomic, Consistent, Isolated, Durable. Those are the properties of the transacation model that most of us have gotten used to in the past. In database terms, it effectively means you can't screw up your database consistency if you have multiple clients trying to access the database at the same time.

The cool thing about these kind of transactions is that you basically don't have to do a lot to get this working. In fact, it is the de facto standard in the RDBMS world. And it's the standard in J2EE environments. So even if you didn't know the acronym, then - my friend - you have have been doing it without being aware of it.

So my first message to all of you is that you should get used to refrain from it. You wonder why? Well, the problem is "I". (What do you know; I'm starting to sound more like a guru with every line.) I don't mean you, I mean "I", not me.

In a SOA world, a business process might take some time to complete. And "some time" can be anything between a couple of seconds between a couple of weeks or more. Even if you would rely on some kind of optimistic locking mechanism, then you would still need the explicit consent of all services participating in the transaction. And during this time, all of your data sources would need to be locked in order to guarantee "Isolation" semantics.

The Isolation property of ACID transactions guarantees that the transation does not affect or is affected by other transactions. This basically implies locking the resources involved for a short period, but you can't do that if the short period expands to a couple of minutes or more. It would effectively lock up your data source forever.

Another problem is the transaction manager. If you decide to open up your services to the outer world, then there must be something coordinating the transactions between your services and your client's services. In the end, you want a consistent state in all of your databases, right? The question is: which transaction manager. Your customer probably doesn't trust yours and you don't trust your customer's. There is no third party out there on the Internet that you could trust. (Not entirely true in all cases, but let's keep things simple.)

So how do we compensate for missing ACID semantics? It may sound silly, but the answer is: with compensation. It means designing your services in such a way that you can always "roll back" manually. The archetypical example is compensation in a flight booking business process. If I book a flight, then the seat will be reserved for me. But if I don't confirm the reservation in time, then the flight booking system will simply "undo" the reservation. It didn't have a transaction that spanned the entire time that I needed to figure out if I wanted to fly or not. It simply defined a "compensating" message allowing them to get rid of my reservation.

WS-BPEL recognizes the need for compensation scenarios and has it built into the language.