Re: Revised Asynch Binding

Hi Dave,

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

This looks a bit too slick willy to me ;-).

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

I don't think so! Glen/JJM/Gudge/Jack/<any other XMLPers>: What do you
think?

> 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 understand your proposal .. but I think its unnecessarily complex.
There's nothing whatsoever wrong with mapping our MEP to a single
SOAP MEP. The problem w.r.t. enabling asynch is how that SOAP MEP
is being mapped to HTTP operations. Thta's what my proposal addresses.

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

See that's where we differ. I don't need *two* SOAP MEPs. I still want
to use one SOAP MEP and bind it to two distinct HTTP operations.

Let me try to explain it again. Consider a WSDL operation foo:

    <operation name="foo">
        <input element="x:foo-in"/>
        <output element="x:foo-out"/>
    </operation>

We bind this to a *single* SOAP request-response MEP, but not using the
XMLP defined SOAP-HTTP binding. Let's first consider an SMTP binding of
this:

    - the endpoint/@address would be where the message with payload
      x:foo-in should be sent to
    - where the reply should be sent will be indicated to the service
      using the ReplyTo: SMTP header
    - service sends the message containing the x:foo-out payload to
      that address
    - receiving email server correlates the message with the outgoing
      message and completes the WSDL in-out MEP

Now, consider an HTTP binding:
    - the originator of the foo operation will do an HTTP POST
      of the foo-in element to endpoint/@address, along with
      something like WS-Addressing's <ReplyTo> element to
      indicate where the reply POST should go.
    - service responds with 201 OK (or 200 OK / content=0)
    (time elapses)
    - service does an HTTP POST to the ReplyTo address with the
      response SOAP envelope
    - receiving HTTP server responds with 201 OK
    - receiving HTTP server correlates the message with the outgoing
      message and completes the WSDL in-out MEP

This is much simpler, and cleaner, than using two SOAP-MEPs for one
WSDL MEP. I don't see why that makes sense at all.

Sanjiva.

Received on Wednesday, 7 July 2004 20:32:05 UTC