Re: SOAP 1.1 One-way HTTP Binding doc

This message contains the clarification point I was trying to make on 
the Call.

Tom Rutt

Christopher B Ferris wrote:

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

I would like to point out that the WS-RX "AckTo: EPR, is not sent on the 
request message, it is sent
on an earlier create sequence message exchange, which associates an 
ack:to address with the reliability sequence.

If this AckTo epr has anonymous address, then the intent is to have the 
ws-rx ack headers be "piggybacked" on the http response
to the reliabile message request (even if that http response does not 
contain the "response" associated with the request message.

The clarification is that the "AckTo: epr does not appear in the soap 
header of the reliable message request.

Tom Rutt

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



-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 31 January 2006 19:03:55 UTC