Messaging Saga

Well, me and Arnon seem to be going round and round on the issue of messaging. All this sparked up from his original post "Queues are databases", and the latest installment is here. The current item is "Saga":

"a series of messages that goes back and forth between two (or more) services in a long running session"

I don't like the term "Saga". I prefer a term that reflects a different perspective: Long-running workflow.

The main difference being that a workflow has a clear initiator and purpose. Furthermore, workflow has state.

In fact, I like this term so much that I think I'll give a presentation about it at TechEd Developers Europe in a couple of weeks:

Adding Value to Message-based SOAs with Workflow (ARC307)
In large-scale, loosely-coupled distributed systems, services communicate with each other using asynchronous messaging patterns. However, this event-based publish/subscribe communication is often incapable of expressing high-value, cross service, business processes. In this session, we will see exactly how a service is structured and examine the various layers that support the top-level SOA concepts as well as those needed for long-running workflows. Don't write off SOA just yet; now that the hype's dying down, we can finally get back to work.

Anyway, back to the workflow-saga thing. Once you realize that a service that runs on multiple servers is involved in a long-running workflow, you will probably manage the state of that workflow in a database. Furthermore, the appropriate distribution of work by the workflow will ultimately express itself in low-coupling between multiple messages that are sent at the same time.

For example, sending a message to N partners for a price quote - N messages, that is. The order in which you receive responses doesn't matter. You could easily add rules like: "you must have at least M responses to continue the workflow", and "the maximum time to wait for a response is Y minutes". None of this creates a need for only-once and in-order handling of messages within the workflow.

Let's see what Arnon has to say about that!

Posted by Udi Dahan at 06:20 PM  Permalink