Reliable Messaging, Transactions, and Messages – oh my!

We’re going to keep steering clear of the SOA hype and FUD that’s been hitting the fan all over and deal with some real issues.

We’ve all heard about WS-Reliable Messaging, some of us have even read the spec. I’m pretty sure that the same goes for WS-Atomic Transaction. I’d say that most of us that build systems today pretty much ignore these specs and use what our tools give us today. The problem is that today’s tools don’t really point us in the right direction.

First let’s start with reliable messaging. There are really two kinds of messages in the world, those that we need to get to their destination (or know if they don’t), and those that we don’t really care either way. An example of a message type that would probably require reliable messaging would be something like a “ProcessOrderMessage”. An example of a message type without any reliability requirements would be something like “StockPriceUpdated”.

Let’s just ignore WS-Atomic Transaction for now (for ever wouldn’t be that bad either) and continue the discussion above in the context of transactions.

One of the purposes of reliable messaging is to ease the handling of failure scenarios. It’s so much easier to just send a recoverable message than code up retry logic to handle hardware failures. However, it’s obviously not enough for the message to reach its destination safely – we need to make sure that the message is also handled safely. This means that the entire process of retrieving the message from the queue, handling it (writing to the database), and sending other messages out occurs all together, and succeeds or fails as a whole. And if the process does fail, then the message needs to go back to the queue.

So, how does this connect with the higher-level concepts of SOA?

Well, consider this: If we define message types as either reliable or not, and we can only tell if we need to handle a message reliably (in a transaction) after we’ve already taken it out of the queue, and handling a non-reliable message in a transaction is a waste, we’d get the best performance by separating reliable and non-reliable messages into different queues/channels. We’d also like to be able to tell the infrastructure that retrieves these messages (the bus) which kind of behavior we want.

The final result is that we have identified a technological fracture line within services that enables us to distribute a given service over multiple servers without breaking its cohesion. Clients don’t need to know anything about the transactional nature of the message handling. They DO need to know if a message type needs to be reliable. If I was using WSDL, I would bemoan the fact that there is no easy way for me to do this.

Reliability is not an aspect you overlay or not on various instances of a given message type or different message types – it’s part of the contract. Transactions on the other hand, have no place in the contract – or between services for that matter. WSDL limits us by tying messages in the same contract to the same endpoint, although the runtime characteristics of those different message types should be different.

Vendors! Stop adding new, useless features to your products and fix the ones that are already there!

Posted by Udi Dahan at 03:06 PM  Permalink