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

noah_mendelsohn@us.ibm.com wrote:
> I'm not sure where to go with this.  One of the responsibilities of MEPs 
> in general is to indicate where faults will be delivered.  In the case of 
> req/resp, they are to be delivered to the requestor, I.e. whatever the 

Do you mean req-resp where it is a SOAP req and a SOAP response OR 
req-resp where it is a SOAP req and a transport response?
I think there are different implications for faults depending on whether 
the response is a SOAP res or a transport-level-only response.

> binding considers to be the requestor.  Typically, as in HTTP, this is 
> implemented by the underlying transport, which keeps a connection open and 
> knows how to get back to the requestor without any explicit addreses at 
> the HTTP level (of course, down at the IP level, an IP address and port is 
> known.) 
> 
> While I agree that we don't in general talk about how promptly processing 
> is done, it seems to me to be a misuse of req/resp to claim that the SOAP 
> fault that results from processing a SOAP message is either intentionally 
> lost, or delivered to some place that's potentially different from the 
> requestor.  That's a fine thing to do if you want it, but it's a different 
> MEP.   Of course, we're in the process of "clarifying" the MEP, and maybe 
> we could/should "clarify" it to state that a responder that sends no 
> envelope is making no warranty as to whether SOAP processing has yet been 
> done, and in the case that it's not been done, that the MEP has nothing to 
> say about fault routing.
> 

That is what I'm leaning towards.
Basically, I want to allow the following usecase:
1) a soap request gets sent over HTTP request with WSA FaultTo and 
ReplyTo as non-anonymous.
2) the HTTP server that gets the message pushes it on a queue 
successfully but does not do any SOAP processing.
3) A 202 status code with empty entity body is returned in the HTTP response
4) subsequently, another agent dequeues the SOAP message, processes it 
and sends the response/fault to the appropriate address specified by WSA 
ReplyTo/FaultTo

If this means that it can't use req-res MEP that is defined/clarified, 
then we would need another MEP (say a 'one-way' MEP) that can be used.

> FWIW, architecturally, I'm increasingly convinced that the WSA delayed 
> response use case would ideally have been a separate MEP, and that we 
> should have had a story about who determines which one the HTTP binding is 
> using when.  I think the political realities are that a SOAP 1.3 and a new 
> HTTP binding won't fly just now, and so there is pressure to stretch the 
> rules of the existing MEP.   We're probably serving our users better that 
> way.  I've supported doing this and I guess I still do.  It's probably the 
> least of the evils, but this discussion of faults reminds me that it 
> involves some compromises architecturally.
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> Sent by: xml-dist-app-request@w3.org
> 02/08/2006 01:44 AM
>  
>         To:     Christopher B Ferris <chrisfer@us.ibm.com>
>         cc:     xml-dist-app@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        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, 15 February 2006 08:14:45 UTC