Fw: SOAP 1.1 One-way HTTP Binding doc

I think that this issue from ws-a wg has relevance to our work on the 
binding,

In reviewing the current text and tables in part 2, it isn't clear to me 
that there is 
an established and well defined relationship between the request and 
response
messages with regards to the SOAP processing model.

e.g. it doesn't say anywhere whether the SOAP processing as described
in part 1 sect 2.6 MUST be performed BEFORE the "response message"
in the Request Response MEP is made available in the outputMessage
property.

As I indicated in my response to Marc on the ws-a list, I think that at a
minimum, any response, whether SOAPy or not, should be made only
AFTER steps 1, 2 and 3 as defined in section 2.6 of part 1 have been
completed so that any mU faults can be transmitted even if the actual
processing of the headers (and the body) are to be deferred.

Thoughts?

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
----- Forwarded by Christopher B Ferris/Waltham/IBM on 01/31/2006 12:49 PM 
-----

public-ws-addressing-request@w3.org wrote on 01/31/2006 11:53:27 AM:

> 
> Marc, 
> 
> Good question. 
> 
> Given that a 202 response is not related to the *processing* of the 
> request message, one could 
> conclude that any SOAP envelope carried in the 202 Accepted response
> might not necessarily 
> have a relationship with the request message at all. However, given 
> what Mark observed, I suspect 
> that we might do well to specify that at a minimum, the SOAP 
> processing w/r/t SOAP headers 
> MUST be performed before any response is generated, so as to ensure 
> that if a mU fault 
> is generated, it can be transmitted on the HTTP response (with a 500). 
> 
> So, my inclination would be (b) 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> public-ws-addressing-request@w3.org wrote on 01/31/2006 10:22:51 AM:
> 
> > 
> > Mark Baker wrote:
> > > On 1/31/06, David Hull <dmh@tibco.com> wrote:
> > >>  We've been pretty clear for a while that empty 202 means "ack". 
I'm
> > >> hearing that non-empty 202 is meant for things like WS-RX acks,
> but I'm not
> > >> sure this is nailed down.  There seems to be some possibility that 
a 202
> > >> with a SOAP envelope could also be a real response.
> > > 
> > > It's still a response, just not the result of processing the 
request.
> > > 
> > > So if you took a SOAP envelope and sent it as an HTTP response with 
a
> > > 202 code, it would mean something entirely different than if sent 
back
> > > with a 200 code... in the same way that a SOAP fault sent with 200
> > > means something entirely different than a SOAP fault
> > > 
> > Right, this chimes with my comments on the call last night. The 
envelope 
> > returned in the HTTP 202 response is something other than a reply to 
the 
> > envelope sent in the HTTP request. The question I'm struggling with is 

> > whether one can assume that the SOAP processing rules have been 
followed 
> > on the request envelope prior to the response envelope being returned 
or 
> > not ? E.g. if I include WS-Addr header blocks in the request envelope, 

> > can I assume that the 202 response envelope will contain the expected 
> > WS-Addr header blocks (e.g. relationship(msgid)). If the SOAP 
processing 
> > rules haven't been followed then what process lead to the generation 
of 
> > the 202 response envelope ? We've been using WS-RX as a use case but, 
> > AFAIK, WS-RX uses header blocks and relies on the SOAP processing 
model 
> > too so are we inventing a new two-stage SOAP processing model or what 
?
> > 
> > In a nutshell, I think we need to decide whether the 202 response 
> > envelope is returned:
> > 
> > (a) Before SOAP header block and SOAP Body processing, or
> > (b) After SOAP header block processing but before SOAP Body 
processing, or
> > (c) (for completeness although this seems to contradict the 'Accepted' 

> > semantics of HTTP 202) After SOAP header block and SOAP Body 
processing.
> > 
> > Thoughts ?
> > 
> > Marc.
> > 
> > >>  If 202 can be a real response, then one would have to use 
> > something besides
> > >> 202 to figure out what's really going on (e.g., whether the 
> > message consists
> > >> only of WS-RX headers and similar).  In this case 202 isn't 
> really carrying
> > >> any information and why bother allowing for it?  On the other 
> hand, if 202
> > >> means something in particular, then what exactly does it mean?
> > > 
> > > Just what it says in the HTTP spec.
> > > 
> > >>  As far as I can tell, the value in non-empty 202 is telling 
> the SOAP stack
> > >> "Hey, this is just infrastructure stuff.  Don't pass it along to 
the
> > >> application."  We can't say that here, but we could (probably) say 
it
> > >> elsewhere.
> > > 
> > > 202, like 200, is a symbol with application layer semantics, and as
> > > such, it should be exposed to the application (plus the SOAP 1.2 
HTTP
> > > binding is a *transfer* binding).  In the case of 202, the 
application
> > > needs to know that no subsequent message which includes "the results
> > > of processing" of the initial request, is necessarily forthcoming 
(and
> > > won't be without additional agreement).
> > > 
> > > BTW, I just noticed this part of the 202 spec which should probably 
be
> > > highlighted;
> > > 
> > >   "The entity returned with this
> > >    response SHOULD include an indication of the request's current 
status
> > >    and either a pointer to a status monitor or some estimate of when 
the
> > >    user can expect the request to be fulfilled."
> > > 
> > > Which suggests that a URI could be returned upon which the 
application
> > > could invoke GET to determine the state of the processing of the
> > > request (anybody remember CORBA "Futures"?).
> > > 
> > > Mark.
> > > 
> > 
> >