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

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

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 Tuesday, 14 February 2006 23:56:00 UTC