Re: Point of view in operation descriptions.

I think the characterization of the usecases from a egocentric term is 
quite useful.
To extend Ugo's comment, in usecase 5, there are two different 
interface/operations (and therefore two services involved). Using 
David's terminology, I would characterize usecase 5 as:

If I receive a request at this address, I will send a reply to the 
reply-to address provided and the reply will conform to the foobar 
interface (which is a one-way).

-Anish
--

Ugo Corda wrote:
> 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)". 
> 
>

Received on Wednesday, 16 February 2005 22:52:19 UTC