W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > March 2005

Re: In-optional out

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Tue, 29 Mar 2005 15:26:50 -0500
To: David Hull <dmh@tibco.com>
Cc: public-ws-async-tf@w3.org
Message-id: <d0a921b557e9541d9d8bf07404839412@Sun.COM>

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.

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:26:57 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Tuesday, 29 March 2005 20:26:57 GMT