Re: Fw: SOAP 1.1 One-way HTTP Binding doc

I don't quite see the value in requiring steps 1, 2 and 3 if a 202 is 
returned. This restricts services from receiving 'one-way' messages and 
processing them off-line, do batch-processing of messages or store it in 
a queue.

Since we are talking about an MEP (request-optional-response) that 
optionally allows the service to return a SOAP message (or not). If the 
service does indeed performs steps 1, 2 or 3 and generates a fault 
before/during those steps it is free to send a fault back with a 4xx/5xx 
status code. The client has to always wait for a HTTP response. On 
getting a 202 back the client should not assume anything (about SOAP 
processing), as the non-committal nature of 202 indicates, other than 
the fact that the bytes were transfer correctly and that the message was 
a correct HTTP message (with the correct/expected HTTP headers).

-Anish
--

Christopher B Ferris wrote:
> 
> 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.
>  > > >
>  > >
>  > >

Received on Wednesday, 8 February 2006 06:44:56 UTC