RE: Point of view in operation descriptions.

The choreography/orchestration argument is usually brought up when
talking about using two one-way messages described by two WSDL
interfaces. In that case, WSDL does not have anything currently to
logically connect the two interfaces, while languages like BPEL have
specific construct to indicate that relationship (e.g. partnerLinks in
BPEL). But I agree that requiring something like BPEL for the simple
case of two related WSDL interfaces is overkill.
 
Ugo

	-----Original Message-----
	From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
	Sent: Wednesday, February 16, 2005 6:28 AM
	To: WS-Async task force
	Subject: Point of view in operation descriptions.
	
	
	One recurring theme in our discussions, and in WSDL-ish
discussions in general, is where does WSDL leave off and choreography
begin.  There is fairly strong resistance to bringing choreography into
the picture, and I think this is justified.  I don't know much about
choreography, but as far as I can tell the salient feature is that it
involves interactions among arbitrarily many actors.  This is a concern
we're specifically not dealing with here.
	
	At the risk of stating the obvious (or finding out that the
obvious isn't actuall correct :-) WSDL is aimed at describing the
behavior of one particular actor.  It says things like "I may produce
messages of this form" (while being a bit vague on what will prompt me
to do it or whither I will deliver them.)  Most famously, it says things
like "If you send me a request like this, I will send you a reply like
that."  This has a nice, well-understood meaning in the synchronous
world of SOAP/HTTP: You send a request, I send back a reply (or fault)
on the back-channel.
	
	However, this introduces a coupling.  It dictates that the reply
be sent to the same actor that made the request.  This not only
restricts the range of possibilities, it also clouds the picture by
implicitly making request/reply into a minature two-party choreography.
The way around this is to read the WSDL more egocentrically:  "When sent
a request like this, I will send a reply like that."  All I've really
done here is delete the pronoun "you", but the result is significant.
We are no longer talking about choreography, or even a private little
dance.  We are simply describing the behavior of one party.
	
	This seems very much in keeping with WSDL in general.  In
particular, it gives a very sharp dividing line between WSDL and
choreography.
	
	With this in mind, here is a first cut at egocentric readings of
our use cases (to the extent I understand them).  I'm glossing over
faults here, but I don't think any of this breaks significantly if
they're included:
	

	*	Use case 1: "I can receive messages at this address" 
	*	Use case 2: "If I receive a request at this address, I
will send a reply on the back-channel" (status quo) 
	*	Use case 3: "If I receive a request at this address, I
will send a reply message to this other address." 
	*	Use case 4: "If I receive a request at this address, I
will make a reply available (at this address ?)." 
	*	Use case 5: From the minutes, this looks a lot like use
case 3. 
	*	Use case 6: "If I receive a request at this address, I
will send a reply to the reply-to address given (which may be the
back-channel)".