Re: Revised Asynch Binding

I am a bit uneasy about creating new (SOAP) bindings uncesserily. In 
certain circumstances, I agree with Sanjiva, this is unavoidable. 
However, for simpler cases, I like Dave's idea of essentially providing 
a "MEP scripting language". This helps reuse existing bindings when 
applicable.

This is related to issue 191 [1] BTW, whose resolution I don't think I 
am quite happy with. As Dave is now clearly pointing out, how are WSDL 
MEPs actually mapped to SOAP MEPs? The mapping is not one-to-one.

JJ.

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x191

Sanjiva Weerawarana wrote:

>> <>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 Thursday, 8 July 2004 10:59:26 UTC