Re: In-optional out

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

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.

Received on Tuesday, 29 March 2005 18:22:40 UTC