Re: Action item - Part 2: SOAP request-response, response, request-optional-response ...

Chris Ferris writes:

> David Hull wrote on 01/12/2006 01:22:55 AM:
> 
> > One potential wild card here, though, is SOAP intermediaries.  I'm 
> > not sure quite how to analyze that, partly because I'm not really up
> > on how intermediaries are used in the real world.  Given that the 
> > SOAP processing model is one-way, I'd think an intermediary shouldn't
> > be aware that a given SOAP message is a request or a response, but 
> > it's highly possible I've missed something. 
> 
> IMO, a SOAP intermediary's binding should respect the 
> underlying protocol's MEP, and not 
> try to play fast and loose based on the application-level MEP. 

I strongly agree with Chris.  The intermediary certainly should know what 
MEPs in use, at least to the extent and endpoint in its place would know. 
It's implementing the inbound binding, and the spec for that will tell you 
what MEP is in use.  In the case of the HTTP binding, it will know that an 
inbound POST==Req/Resp.  In fact, it better know that, or it might be 
tempted to close the HTTP connection without waiting for the downstream 
nodes to respond.  Indeed, I'd say that the intermediary is responsible 
for ensuring that the 2nd hop binding can faithfully implment the MEP used 
by the first hop. 

I will say that one of my great regrets in SOAP is that having bothered to 
spec intermediaries in the first place (a questionnable call IMO), we did 
not clearly document the details of intermediaries very well.  I always 
thought that part 1 should have made it part of the requirement for the 
specification of an MEP that teh possible behavior of intermediaries be 
specified. For example, if an inbound request causes an mU fault at an 
intermediary, the fault message should presumably go back to the sender. 
If a similar error happens on a response, what to do is less clear. I 
think we should have said.  I am NOT proposing to expand the scope of the 
XMLP charter to say much new now, I'm just agreeing that it's not as 
clearly specified as it should be.

--------------------------------------
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/18/2006 12:16 PM
 
        To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Action item - Part 2: SOAP request-response, 
response,  request-optional-response  ...




David Hull wrote on 01/12/2006 01:22:55 AM:

> One potential wild card here, though, is SOAP intermediaries.  I'm 
> not sure quite how to analyze that, partly because I'm not really up
> on how intermediaries are used in the real world.  Given that the 
> SOAP processing model is one-way, I'd think an intermediary shouldn't
> be aware that a given SOAP message is a request or a response, but 
> it's highly possible I've missed something. 

IMO, a SOAP intermediary's binding should respect the underlying 
protocol's MEP, and not 
try to play fast and loose based on the application-level MEP. 

Someone was complaining to me about the use of the HTTP response to convey 
a SequenceAcknowledgement 
when the WSDL operation was a oneway because their intermediary would 
examine the WSDL and close 
the connection to the originating HTTP client before receiving the HTTP 
response to the intermediary's 
HTTP request forwarding the message. 

I believe that it is inappropriate for the intermediary to use knowledge 
of the WSDL to optimize the 
exchange since even a oneway message could generate a Fault and per the 
SOAP spec, the 
node generating the Fault is supposed to transmit that fault back on the 
HTTP response in the 
HTTP binding. If the intermediary had closed the connection back to the 
originating node before 
it received the response to the forwarded message, how is it supposed to 
convey that fault 
back to the originating client, which is the one that probably wants to 
know that its message 
generated a fault, and arguably would be expecting to receive such a fault 
because that was 
what was specified in the HTTP binding (it may not necessarily be aware 
that there's 
an intermediary involved in the exchange). 

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

Received on Wednesday, 18 January 2006 20:32:20 UTC