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

Chris Ferris writes:

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

I have thought for awhile that the exposition of the MEPs and the HTTP 
binding is in the unhappy middle space between ignoring streaming 
completely and getting the edge cases right. 

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

I'm less convinced I would go this way.  Section 2.6 of part 1 seems to 
quite properly constrain what the net response must be.  I think it is the 
responsibility of the responding node, including its binding, to generate 
a correct response.  Rather than going into detail about which steps to do 
when, I think we should leave it at that.  You may be right that it will 
be very hard for a correct implementation to proceed before certain steps 
are performed, but I think that should be an emergent property of the 
spec, not something we set down as fixed. 

I do think there is a fundamental conflict between XML's notion of 
well-formedness, our use of XML on the wire for the HTTP binding, 
streaming, and late error discovery.  The risk is that you have started to 
stream out a response envelope in streaming mode, and suddenly discover an 
error.  Maybe it's a clearly SOAPy error like an mU fault, but as likely 
it's an application error.  In principle, it would be nice to send a SOAP 
fault, but it's too late to do that cleanly.  I think there are only two 
choices, neither appealing:

* use an application-specific means of streaming into the response some 
error indication.  If you've started sending the response body, then it 
can't be a SOAP header.  In any case, SOAP intermediaries and other 
receivers won't know there's been an error.

* you can close the connection, thus turning what was an application-level 
error into a transport level error.  I think this maybe an OK strategy in 
emergencies, but as we've observed in our one-way debates, closing 
connections when you don't have to should be approached with caution.

I've thought for years that this use case exposes one of the major 
compromises in using XML as the basis for SOAP messaging.  Of course, we 
could further complicate the SOAP envelope format in future releases to 
allow for an "I hit an error trailer" to be appended to a possibly 
truncated body in the case of error.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Christopher B Ferris <chrisfer@us.ibm.com>
Sent by: xml-dist-app-request@w3.org
01/31/06 01:03 PM
 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Fw: SOAP 1.1 One-way HTTP Binding doc



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, 9 February 2006 22:58:14 UTC