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

Received on Tuesday, 29 March 2005 20:34:00 UTC