- From: <jones@research.att.com>
- Date: Mon, 21 Oct 2002 15:37:28 -0400 (EDT)
- To: Mike.Champion@SoftwareAG-USA.com, www-ws-arch@w3.org
Mike, From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com> To: www-ws-arch@w3.org Date: Mon, 21 Oct 2002 15:19:23 -0400 MIME-Version: 1.0 Subject: RE: choreography usage scenarios > -----Original Message----- > From: Mark Jones [mailto:jones@research.att.com] > Sent: Monday, October 21, 2002 3:04 PM > To: www-ws-arch@w3.org > 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: jones@research.att.com phone: (973) 360-8326 fax: (973) 236-6453
Received on Monday, 21 October 2002 15:37:59 UTC