RE: mustUnderstand on client side

>I agree, the SOAP spec does provide some guidance for the case 
>where a processor fails to understand a mustUnderstand header. 
>I believe the SOAP spec should also provide some guidance for 
>"how to respond" to a mustUnderstand fault, and this is where 
>the spec is deliberately silent, as Henrik said.
>
>Can you share the authors reasoning behind the deliberate silence?

I can share you my reasoning :)

The short version is that as SOAP fundamentally is a one-way message
model this means that talking about a fault *response* doesn't make much
sense in the base model. This would have to be expressed in another way.
One can imagine two ways to do this:

 * use protocol bindings that provide some message exchange pattern

 * add a SOAP module that provides enough information to figure out
   where to send faults.

Looking at this is a bit more detail then we have:

Protocol Bindings
-----------------

We all know that HTTP defines a request/response model and when SOAP is
used in combination with HTTP, it can take advantage of that message
pattern. The HTTP model means that if the request fails, we know what to
do with the fault - send it back to the client.

If the client fails the response either by not understanding it or for
some other reason, there is no mechanism in HTTP to alert the server. In
other words, as soon as you go outside a request/response interaction
(with some level of exception in the case of 3xx status codes) then HTTP
says nothing about what to do and in any case it never forces the client
to do anything. 

One could imagine a SMTP binding that also is a one-way message - what
would happen if there was a mustUnderstand that the recipient didn't
know or wanted to perform? It would have to discard it because there is
no way to send any fault *response* unless a mechanism was layered above
in some manner.

SOAP Module
-----------

One could also envision defining a module that defined mechanisms for
where to send additional messages in the message flow - this could be
part of a simple request/response interaction or some more complicated
message exchange pattern - or protocol involving multiple messages being
exchanged in either direction.

All these mechanisms are valid and useful - but we also have to keep in
mind that SOAP might be used for one-way messages where there really is
no reverse path or the initial sender doesn't want to see responses
regardless of whether there is a reverse path or not.

This is the reason why the core SOAP says that you get a one-way message
and the hooks for building more complex message exchange patterns. How
you do this is up to the solution that one applies to the problem. 

Henrik

Received on Wednesday, 2 May 2001 15:47:38 UTC