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.

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

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

> The working group needs to decide whether an interface operation
> is abstract from the protocol operation or not, and whether 2
> interface operations versus 1 are required to do a callback.
> I argue that for the 80/20 case, a single interface operation
> is the right way to go.

I couldn't agree with you more!

> I do like and support the idea that any asynch binding must
> specify through some mechanism how to succesfully perform the
> callback.

+1.

Sanjiva.

Received on Tuesday, 6 July 2004 11:49:48 UTC