RE: choreography usage scenarios

Mike,

	From: "Champion, Mike" <[email protected]>
	To: [email protected]
	Date: Mon, 21 Oct 2002 15:19:23 -0400
	MIME-Version: 1.0
	Subject: RE: choreography usage scenarios

	> -----Original Message-----
	> From: Mark Jones [mailto:[email protected]]
	> Sent: Monday, October 21, 2002 3:04 PM
	> To: [email protected]
	> Subject: choreography usage scenarios
	> 
	> 
	> Is it helpful to elaborate a set of such scenarios to sharpen further
	> distinctions?

	Yes, IMHO.  For example, I'd like to see a more business-oriented
	explanation of "The requestor is able to correlate a response received in a
	separate message (and protocol invocation) with the original requesting
	message."  That is, what business is being transacted here, and why is the
	correlation necessary?

The correlation is necessary because there may be many concurrent
requests between a given pair of client/server nodes and the client
must match the responses with the requests.  The case assumes that the
protocol binding cannot manage the correlation by itself since the
messages occur over separate protocol invocations.

As for the business-oriented explanation, this scenario occurs
frequently when the response cannot be computed in "real-time"
(relative to the underlying protocol time-outs).  This might be due to
complicated calculations, human decision-making as part of the server
processing, etc.  For example, extremely large orders may only be
accepted with human approval.

We can add these kinds of clarification, but when I wrote the question
"Is it helpful to elaborate a set of such scenarios to sharpen further
distinctions?", I was thinking more in terms of whether a long(er)
list of these scenarios could help us taxonomize all the various kinds
of relationships that might exist among messages.  (And whether those
relationships are in a particular conception of choreography.)

	> 
	> --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).

	Right.  Remember that we're not trying to design an actual choreography
	language, just figure out the scope of a WS Choreography WG.  I do think
	that the suggestions, such as the "state machine in XML", help us think
	about these requirements, but let's not get carried away :-) 

--mark

Mark A. Jones
AT&T Labs -- Strategic Standards Division
Shannon Laboratory
Room 2A-02
180 Park Ave.
Florham Park, NJ  07932-0971

email: [email protected]
phone: (973) 360-8326
  fax: (973) 236-6453