choreography usage scenarios

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