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