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

Yes indeed!

So there's little than can be said about which steps have been performed 
when the OutputMessage is ready for delivery. :-(

This being said, as you suggested, some words about the 
issue/relationship could have been usefully added to the spec.

JJ.

Christopher B Ferris wrote:

>
> Ah,
>
> I see your point. I think we are thinking the same thing, and the 
> words are getting in the way:-)
>
> I agree that certain faults will be generated before step 3, and that 
> they would immediately be made
> available in OutputMessage because by definition, a generated fault 
> terminates all processing of
> the message.
>
> Agreed?
>
> 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
>
> Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> wrote on 
> 02/01/2006 12:12:03 PM:
>
> > Chris,
> >
> > Possibly, and I was about to agree with you, but then again you say :
> > "(or fault)", and for me the OutputMessage will be set after step 3 
> only
> > for some fauts but not for all (for example, for mU but not vM faults).
> > I don't see any need to perform steps 1 to 3 if we're going to fault on
> > version mismatch (we might not even be able to do so because the 
> message
> > may be unreadable).
> >
> > JJ.
> >
> > Christopher B Ferris wrote:
> >
> > >
> > > JJ,
> > >
> > > Possibly you mis-understood me. I totally agree that a 
> VersionMismatch
> > > or other receiver
> > > fault can be generated. I was only suggesting that at the very least,
> > > the SOAP processing
> > > model, through step 3 needed to be performed before making the
> > > response message
> > > (or fault) available in the OutputMessage as per the binding, just so
> > > that we are precise
> > > about what the responsibilities are.
> > >
> > > I think that this also applies in the streaming case.
> > >
> > > 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
> > >
> > > Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> wrote on
> > > 02/01/2006 06:47:28 AM:
> > >
> > > > Hi Chris,
> > > >
> > > > What if there's a VersionMismatch or some "early" Receiver fault?
> > > > Shouldn't that be reported before the processing model is even 
> engaged
> > > > (i.e. before step 1 is completed [if ever started])?
> > > >
> > > > If the response is a response (i.e. not a fault), then it cannot 
> happen
> > > > before step 4 has been completed. If it's a fault, then all bets are
> > > > off. It could happen at any stage: from before step 1 up to during
> > > step 4.
> > > >
> > > > Did I miss something?
> > > >
> > > > JJ.
> > > >
> > > > 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 Thursday, 2 February 2006 10:42:27 UTC