Re: In-optional out

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.

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