Re: In-optional out

Yalcinalp, Umit wrote:

>The response at the HTTP transport is just a side effect of using the http protocol (202). It is an HTTP response, not SOAP response for one way messages. Wrt SOAP MEP perspective, this is not an ACK per se for SOAP protocol, but for http transport since there is no SOAP response message. Hence, I don't think we should bring the side effect of the transport with an explicit ACK at the SOAP layer. 
>  
>
The question then is, how do you know when you're done?

If you get an explicit 202 back, you know you're not going to get an 
actual message on the back-channel.  Do we try to capture that at the 
SOAP level?  Whatever we choose to call it, how would the SOAP level 
distinguish "in, no out" from "in, no out yet"?

>--umit
> 
>
>-----Original Message-----
>From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org] 
>Sent: Tuesday, Mar 29, 2005 12:33 PM
>To: Marc Hadley
>Cc: public-ws-async-tf@w3.org
>Subject: Re: In-optional out
>
>
>Marc Hadley wrote:
>
>  
>
>>On Mar 29, 2005, at 1:51 PM, David Hull wrote:
>>
>>    
>>
>>> Marc Hadley wrote:
>>> This is all a bit confusing. SOAP doesn't define anything like an 
>>>ACK, that's an application level construct (assuming its a SOAP 
>>>message) so the in-(out|ACK) MEP is just a SOAP in-out (or 
>>>request/response).
>>>
>>> My understanding was that, if there were no explicit reply, you 
>>>would still want to get back an empty (i.e., non-SOAP) message with a 
>>>202 code.  This is distinct from, e.g.,  the receiver simply closing 
>>>the connection.  Thus the (possible) need to introduce the notion of 
>>>an ACK at the SOAP level.
>>>
>>>      
>>>
>>I think my confusion here stems from the fact that SOAP MEPs only talk 
>>about exchanging SOAP messages not underlying protocol exchanges 
>>(that's where the binding comes in) so if the ACK is purely at the 
>>underlying protocol level then it won't show up as part of the SOAP MEP.
>>    
>>
>
>The question then is whether it is enough to model POST in/202 out as 
>in-[out] with no out, or whether the SOAP layer needs to report that 
>/something/ happened.  If it needs to report that something happened, 
>then it can't very well report a SOAP message arrived, and we (or 
>someone :-) will have to create some new construct -- which I'm calling 
>an ACK -- to describe what happened.
>
>  
>
>>Marc.
>>
>>    
>>
>>> This would not be an application-level construct.  The application 
>>>may well view things differently.  For example, it might consider 
>>>sending the request and getting back a reply or fault as separate 
>>>events.
>>>
>>> E.g.
>>>
>>>
>>>
>>>App View
>>>
>>>SOAP View
>>>
>>>
>>>App sends request, reply-to: a callback, fault-to: the back channel
>>>
>>>Sender sends the inbound message of an in-[out]
>>>
>>>
>>>(normal processing) App gets reply on callback
>>>
>>>Receiver sends back ACK.  And that's it (sending back the reply is a 
>>>separate interaction)
>>>
>>>
>>>(fault processing) App gets a fault
>>>
>>>Receiver sends back a message (and that's it).
>>>
>>>
>>>
>>>
>>>
>>> Marc.
>>>
>>> On Mar 29, 2005, at 12:46 PM, David Hull wrote:
>>>
>>>
>>>  I've just read over the minutes from last week, and I'm doubly 
>>>sorry I missed the discussion.  I'd also like to thank Jonathan for 
>>>the clear and thorough minutes.
>>>
>>>  When I first heard of an in-[out] (or even [in]-[out]) "über MEP", 
>>>it seemed like it was trying to generalize any possible MEP.  An 
>>>in-only would be treated as [in]-[out] with an in and no out, and so 
>>>forth.
>>>
>>>  This seemed like a bad idea.  It wouldn't actually cover all 
>>>possible MEPs, but it would add a layer of complexity to in-only or 
>>>even in-out ("in-out is [in]-[out] with both in and out present" as 
>>>opposed to "in-out is in-out").  Thence the George Carlin quote about 
>>>volleyball being team ping-pong with a raised net etc.
>>>
>>>  Reading through the minutes, though, in-[out] looks to be more 
>>>narrowly focused on an important fact of life: In some scenarios you 
>>>can't tell in advance whether you will get an application-level reply 
>>>on the back-channel.  For example, if the normal course of action 
>>>were to send messages on to the "approval" and "logging" endpoints 
>>>given in the message addressing properties, while a fault should come 
>>>back on the back-channel, you would have to find out dynamically 
>>>which alternative was actually in effect.  I suppose the 
>>>request/reply case with the one of the two endpoints directed to the 
>>>back-channel and the other directed elsewhere would also be an example.
>>>
>>>  In such cases, the in-[out] pattern captures the fact that you 
>>>might get back a message on the back-channel, or you might just get 
>>>back an ACK.  It doesn't quite capture the possibility of getting 
>>>more than one message back on the back-channel (e.g., two or more 
>>>non-mutually-exclusive endpoints both pointed at the back-channel), 
>>>but perhaps it could be expanded to cover that, too.  It might also 
>>>be better to describe the pattern as "in-(out|ACK)", emphasizing that 
>>>something always comes back (if that's what we mean).
>>>
>>>  As a side-effect, we could also model a one-way WSDL MEP as an 
>>>in-[out] with just an ACK coming back.
>>>
>>>  This is all described at the SOAP level, without reference to HTTP 
>>>or any other physical binding, which is why I say "ACK" instead of 
>>>"202".  It's up to the binding to say what form the ACK takes.
>>>
>>>  With this in place, as I understand it:
>>>
>>>     *     a in-only message would manifest as in-[out] with just an 
>>>ACK in reply
>>>
>>>     *     existing synchronous request/reply still manifests as 
>>>request/reply
>>>     *     asynchronous request/reply manifests as in-[out]
>>>  Is this all roughly correct?
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> Marc Hadley <marc.hadley at sun.com>
>>> Business Alliances, CTO Office, Sun Microsystems.
>>>
>>>
>>>
>>>
>>>      
>>>
>>---
>>Marc Hadley <marc.hadley at sun.com>
>>Business Alliances, CTO Office, Sun Microsystems.
>>
>>    
>>
>
>
>  
>