Re: [ws-caf] Revised MustUnderstand Proposal

[Greg Pavlik <greg.pavlik@oracle.com>]

Kevin Conner wrote:

>I knew I should have logged in yesterday :-)
>
>On Wed, 20 Apr 2005, Furniss, Peter wrote:
>  
>
>>If B is considered unacceptable, then I guess we must follow A. Which
>>means we must at least define a fault value.  I'd suggest we avoid
>>another attribute of our own by saying that the soap:mustUnderstand is
>>taken to have implications for the need for understanding the inner
>>elements of the header. But the extra fault is only needed to avoid what
>>seems to be over-precise statements in the SOAP spec. (Does anyone know
>>if the issue of non-recognition of inner elements was discussed in the
>>SOAP group ?)
>>    
>>
>
>I believe that A is the correct choice but do not agree with the
>overloading of the soap:mustUnderstand attribute.  The reason for this is
>that there are SOAP frameworks that handle the processing of the attribute
>without deferring to the header processing code.
>
>The SOAP implementations I have used generally fall into two distinct
>categories, either a stack of interceptors that can process the message as
>it passes or a set of handlers that are registered with the framework.
>
>The interceptor frameworks allow the interceptors to perform any
>processing (thus allowing B), requiring them to be aware of the
>soap:mustUnderstand attribute and to indicate that compulsory headers have
>been processed by modifying a message context.  This context is then
>checked before processing the SOAP body.
>
>The handler frameworks require the handler to be registered using the
>namespace/local name of the header element.  They differ in how this is
>configured (XML files, programmatically or a method on the handler) but 
>they tend to enforce the soap:mustUnderstand attribute independently of
>the handlers, the existence of the handler qualifying as understanding.
>
>My understanding, as I previously stated, is that the soap:mustUnderstand 
>attribute only requires the endpoint to be able to process the header 
>element and not that this should be successful.  I believe these are
>different aspects and should be treated as such.
>  
>
+1. In the end, it doesn't matter how the endpoint is implemented, only 
that the MU semantics are applied.

>The question I have regarding B is how to differentiate between an
>endpoint that supports the element but not the extension and one that
>doesn't support the element?  I believe that SOAP 1.1 requires the
>definition of additional header elements to differentiate whereas 1.2
>allows sub codes within the must understand fault.
>
>	Kev
>
>
>  
>