Re: In-optional out

I certainly think that while it may not be part of the SOAP MEP, persay, 
it's part of the SOAP bindings specified in the WSDL (as it does include 
the transport).  As long as we define the behavior and can answer the 
question that David has posed, I believe this was one of the requirements 
of what I was trying to get addressed.

Regards... Greg

Greg Truty
WebSphere Architecture/Development,  IBM Austin
EMail:     gtruty@us.ibm.com 
Phone:   (ext)  (512) 838-2828
                (Tie) 678-2828




David Hull <dmh@tibco.com> 
Sent by: public-ws-async-tf-request@w3.org
03/29/2005 03:55 PM

To
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
cc
Marc Hadley <Marc.Hadley@Sun.COM>, public-ws-async-tf@w3.org
Subject
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.