W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: Revised Asynch Binding

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Thu, 8 Jul 2004 19:35:02 +0600
Message-ID: <15c201c464f0$608fec30$84614109@LANKABOOK>
To: <www-ws-desc@w3.org>

BTW Dave I did answer your question: but not the way you want it
done. My answer is that you don't need two SOAP MEPs to solve
this problem.

Can you give rationale for why you want to use two SOAP MEPs
when you can do a perfectly good solution by just rebinding how
a single SOAP request-response MEP is carried over SOAP?

Sanjiva.

----- Original Message ----- 
From: David Orchard
To: Prasad Yendluri ; www-ws-desc@w3.org
Cc: Sanjiva Weerawarana ; paul.downey@bt.com
Sent: Thursday, July 08, 2004 4:02 AM
Subject: RE: Revised Asynch Binding


Prasad,

I never said that the reply address had to be fixed.  I fully expect it to
be dynamic.

And you don't answer the same question I asked of Sanjiva: How are the soap
binding components set in the callback mep?  You don't answer how soap
action is set on the 2nd soap req/resp mep for example.  This ought to be
done in the binding.

Cheers,
Dave
-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Wednesday, July 07, 2004 1:35 PM
To: www-ws-desc@w3.org
Cc: David Orchard; Sanjiva Weerawarana; paul.downey@bt.com
Subject: Re: Revised Asynch Binding


I agree with Sanjiva that this needs to be kept simple. Since Dave's
analysis shows there is no conflict in using the same protocol URI (for
soap/http) here, I like to propose that we take Paul's suggestion and
accomplish this by adding the wsdl:async attribute on the binding/operation.
The presence of this attribute with a value of "true" implies the operation
supports async exchanges (default "false").
However, I do not think it makes sense to "fix" the reply address at the
service level (asynclocation) as proposed by Dave, as we want this to be
dynamic based on the specific client that is interacting with the service
(EP). Hence I propose that we attach the following semantics when
@wsdl:async=true on a binding/operation:

If the EP identified in the service/endpoint/@location is that references a
binding (@binding) with the @async=true, it is declaring itself to be
capable of asynchronous exchanges. However for the EP to respond
asynchronously, the asyncLocation / replyTo address must be communicated by
other means (WS-Addressing header or WS-MD header etc.).

Perhaps this can be added as an extension to <service> (or binding  or
binding/operation?). E.g.
<service ... @EPRprotocol="xs:anyURI"? ...>


<definitions>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           wsoap:protocol="xs:anyURI"
           wsoap:mepDefault="xs:anyURI"? >

    <operation ref="xs:QName"
               wsoap:mep="xs:anyURI"?
               wsoap:action="xs:anyURI"?
        wsdl:async="xs:boolean"
        >

    <input messageLabel="xs:NCName"? >
    </input>*
    <output messageLabel="xs:NCName"? >

    </output>*
    </operation>
  </binding>

<service name="xs:NCName" interface="xs:QName"
    <endpoint name="xs:NCName" binding="xs:QName" location="xs:anyURI"
EPRprotocol="xs:anyURI"?>
    </endpoint>*
</service>*


Regards, Prasad

-------- Original Message -------- Subject: RE: Revised Asynch Binding
Resent-Date: Tue, 6 Jul 2004 13:19:34 -0400 (EDT)
Resent-From: www-ws-desc@w3.org
Date: Tue, 6 Jul 2004 10:15:30 -0700
From: David Orchard <dorchard@bea.com>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Sanjiva Weerawarana
> Sent: Tuesday, July 06, 2004 8:49 AM
> To: www-ws-desc@w3.org
> Subject: Re: Revised Asynch Binding
>
>
> Hi Dave,
>
> Good discussion.
>
> > I already argued the point about SOAP HTTP binding of interface
> > operations.  How is my or even Paul's proposed use of asynch
> > violating the XMLP defined SOAP HTTP binding?  That binding roughly
> > says that the HTTP request and response contain a SOAP body.
>
> I just read section 7 of SOAP 1.2 part 2 and to me it says pretty
> clearly that the HTTP request carries the request message of the
> SOAP request-response MEP and and the *response to that request*
> contains the response message of the SOAP request-response MEP.
>
> (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp)
>
> Can one of the XMLPers please confirm or deny that statement please?)
>
> If that is true, we CANNOT claim to use the SOAP-HTTP protocol
> binding defined by XMLP and use WS-Addressing ReplyTo or other such
> mechanism to do an asynch call.

Ah, but you haven't seen the legal maven DaveO in action.

I would argue that in the case of 2 separate http operations, we can be
quite creative
in the interpretation of the word "that" in "that request".  If I have a
protocol trace of
->Request #1 (wsdl operation input)
<-Response #1 (200/empty)
<-Request #2 (wsdl operation output)
->Response #2 (200/empty)

I feel completely comfortable in saying that both of the 200/empties are
responses to the respective request.  That is the 200/empty is the
*response to the request*.  We have layered *gasp* an abstraction on top
that isn't seen by the underlying protocol, and the underlying protocol
doesn't need to care.

Remember soap/http binding just says what goes on the wire.  The
interpretation of that
is up to us.

>
> > It says nothing about how a WSDL operation is sent on the wire.
> > In particular, it does NOT say that a wsdl operation response must
> > come over the HTTP response.
>
> That's right- it talks about the SOAP request-response MEP (and the
> SOAP response MEP). However, in our binding we say that we map an
> in-out WSDL MEP to a request-response SOAP MEP (see the default
> rules:
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20
> -bindings.html#soap-defaults).
> So, if a WSDL in-out MEP is in use and
> the default SOAP MEP value is used then you cannot do asynch with the
> @protocol value pointing to the XMLP defined SOAP-HTTP protocol
> binding.

And I'm arguing that we can validly say that we map an in-out WSDL MEP to
either:
- a single http operation request-response SOAP-MEP (default)
- a double http operation of 2 request-response SOAP-MEPs.

>
> > I find it ironic that people keep
> > talking about interfaces being abstract, but then they almost
> > invariably think that an interface operation binds directly to
> > a protocol operation.
>
> I certainly don't think so.
>
> > My proposal takes 1 interface operation
> > and maps it to 2 HTTP protocol operations.
>
> That's precisely what mine does too! Obviously I haven't explained
> it properly: it replaces the XMLP-defined binding of the SOAP
> request-response MEP to HTTP with one that uses two HTTPs, with
> the URL of the 2nd being somehow specified in the first (via ReplyTo,
> for example).

>
> > Your proposal removes the ability for the WSDL to specify the
> > soap information for the callback, such as soap action, in the
> > binding of the interface operation.
>
> Not at all! One can specify the SOAP Action for the output message
> and it'll work just great. We currently specify SOAP action at
> the operation level, which is by itself a problem .. see
> WS-Addressing's
> <Action> gizmo for example .. it uses different actions for the
> request and response messages. Paul's message described a scenario
> which motivates that.
>
> (Which again reminds me that I want to propose a solution for the
> "operation name" problem to address that too.)
>
> > In your proposal, I have to have 2 interface operations to do
> > the callback, whereas mine allows for a single interface operation.
>
> Absolutely not - my proposal allows a single WSDL operation using
> the WSDL in-out MEP to be bound to two HTTPs to enable the asynch
> behaviour we are looking for.
>

Can you show me how your proposal would do this?  I'm not seeing it...

My proposal uses the binding output to allow the adornment of the 2nd soap
request/response mep.
I don't see where yours would allow this data.

Cheers,
Dave
Received on Thursday, 8 July 2004 09:35:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT