- From: Mark Jones <jones@research.att.com>
- Date: Mon, 21 Oct 2002 15:03:53 -0400 (EDT)
- To: www-ws-arch@w3.org
Hi gang, I'd like to jump into the choreography discussion with a little different approach. In the telcon last week, I mentioned the possibility of having usage scenarios help focus discussion. I tend to view choreography as a technology which would describe the relationships among basic messages (essentially operations in the WSDL sense). Maybe we can start with a list of simple types of relationships and then organize our discussion around such a list. Here are some real life examples that require more than WSDL to state the relationships among a set of related messages: 1) asynchronous single request-response: The requestor is able to correlate a response received in a separate message (and protocol invocation) with the original requesting message. 2) asynchronous multiple request-response: The requestor is able to correlate multiple responses received in separate messages with an original requesting message. The multiple response messages also have an ordering among themselves (message 1/N?, 2/N?, ... N/N). (But they need not be received in that order and N need not be determined in advance.) 3) synchronous multiple request-response: A sequence of request-response messages is exchanged between the same pair of client/server nodes. Each request-response message in the sequence is a part of a coherent "conversation", so we have correlation of a set of messages with respect to another construct (a conversation). Fancier versions of this may also constrain the ordering of messages in the sequence. Even fancier versions could have conditional constraints on the messages in a conversation. Each conversational turn does not have to be initiated by the "client", also. Important variations can be teased apart in other scenarios. 4) publish-subcribe: A set of subscriber nodes send their subscription messages to a pubsub service node that records the subscriptions. A set of publisher nodes send their publication messages to the same pubsub service. For each publication message, the pubsub service sends notification messages to the matching subscribers. The notifications can include information from (and are related to) the publication and the matching subscription messages. 5) gateway synchronous single request-response: A synchronous request-response message is intiated from an external client node and terminated at a gateway. A separate, but related, synchronous request-response message is transmitted from the gateway to an internal back-end system. When the gateway receives a response from the back-end, it returns a related message in its response to the client. and a slightly more complex example just to ensure that these kinds of relationships can be composed in various interesting ways... 6) gateway synchronous multiple request-response: Combine scenarios 3 and 5 so that the conversation can properly flow through the gateway. (Another variation might have the gateway retain the conversational relationship without passing it along to the back-end.) It seems that the layer(s?) above WSDL must capture these kinds of relationships in a form that can be reasoned about. Laying aside the questions for a moment about partitioning these cases based on other criteria (hiding, etc.), is there a reason why a single choreographic framework cannot (or should not) handle these scenarios? Is it helpful to elaborate a set of such scenarios to sharpen further distinctions? --mark PS I tried to focus on the relationships among messages and not so much on the mechanisms used to determine those relationships. I'd like to see a characterization that can remain relatively neutral with respect to architectural styles (e.g., REST).
Received on Monday, 21 October 2002 15:04:24 UTC