Transactions, SOA and Asynchrony

Gregor Hohpe is currently thinking about conversation patterns, this is excellent news. His book Enterprise Integration Patterns is really a excellent work on categorizing the different ways we have been connecting systems together. It is one of those books that you go, "of course, why hasn't someone done that already?". EIP is reallly about the kind of ways that we pass messages between systems (message-oriented processing), for example router-patterns, queuing patterns, etc. Conversation patterns are a higher-level and represent sets of exchanged messages.

From this point of view, they should be entirely specifiable in BPEL, since BPEL can be used to specify a sequence of exchanged messages. Now BPEL is normal used to implement a Business Process which just happens to exchange messages between peer systems, but it can also be used to verify that a set of exchanged messages between peers conforms to its specification - e.g. that message A was received before message B. In fact, this is how we test our own BPEL engine, we use BPEL to implement the conformance tests for the BPEL 2.0 specification.

The conversation patterns emerge from work on "Your Coffee Shop Doesn't Use Two-phase Commit". Which makes the point that most human systems don't use two-phase commit, possibly because humans don't support a XA-Resource API :-). We should remember that ACIDity and 2-phase commit are artificial inventions which stem from a centralised planning viewpoint. The real world doesn't use them. The internet mostly doesn't use them for peer-to-peer interactions. Of course, this isn't really news, BPEL as a language is built around the notion of compensating actions, effectively dropping transactions as a concept for loosely-coupled SOA systems. And BPEL is on version 2.0.

So what kind of conversation patterns could we dream up? Well Intelligent Agents came up with quite a few:

• Dutch Auction
• Contract Net protocol

Though these are quite complex protocols, so maybe too much. Some simpler ones are:

• Subscribe to Events (subscribe, receive event, ...., eventually unsubscribe or go missing).
• Submit Job ( submit job, get job ID, poll job ID, or recieve notification or job, cancel job, etc).
  
• Submit Task (submit task, transfer task, take task, relinquish task, complete task, abandon task).
• etc, pick your favourite peer-to-peer protocol and generify it, e.g. Ask a question, expect an answer -protocol

So what do we hope to get for this. Well if we can generify some of these protocols, we can make them interoperable. Does this mean they have to be SOAP-based. Nope it doesn't. But notice that they are all services (i.e. realisable by a single entity), for example the event service, the jobs service, the task service. So they are specifiable in BPEL.

However, there are a range of conversation patterns that cannot be specified in BPEL. These are true peer-to-peer protoocols. BPEL can only specify the message exchange semantics for one peer (typically the service provider), but if we have true, peers and there is no central authority, or entity realising the service, then it cannot be specified in BPEL.