axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Haddad <hadd...@apache.org>
Subject Re: MustUnderstand faults
Date Fri, 15 Aug 2003 04:10:54 GMT
Toshi -

The SOAP processing rules are orthogonal to the constraints
imposed upon handlers.

http://www.mail-archive.com/axis-user@xml.apache.org/msg11922.html  has an
excellent dissertation on the fact that a handler is neither a SOAP node
nor a SOAP intermediary.  The specification fragments referenced in your
note does not necessarily pertain to the inner processes (handlers) of the SOAP node
(Axis).


/Chris


On Thu, 14 Aug 2003, Toshiyuki Kimura wrote:

> Hi Chris,
>
>   Thank you for meaningful discussion with you.
>
> | Would you agree that the JAX-RPC specification and API is
> l broken in regards to the processing of MU headers?
>
>  Nope. :-)
>
> | It seems to me that there are a few API methods that need to be
> | added to the JAX-RPC SOAPHeaderElement definition. for example,
> | an 'isProcessed' method to mark that a handler did in fact
> | successfully process the header. without the inclusion of this
> | method, handlers do not have the option of conditionally
> | processing a MU header (and still passing the header element
> | down the chain).
>
>   No, No... If a MU header is *correctly* processed, the node
> will be removed or changed to another node.  But, the message
> style is outside the scope of SOAP 1.1, 1.2, and JAX-RPC spec.
>
> <snipet of SOAP 1.0 >
>  4.2.2 SOAP actor Attribute
>  ...
>  Not all parts of a SOAP message may be intended for the ultimate
>  destination of the SOAP message but, instead, may be intended
>  for one or more of the intermediaries on the message path. The
>  role of a recipient of a header element is similar to that of
>  accepting a contract in that it cannot be extended beyond the
>  recipient. That is, a recipient receiving a header element MUST
>  NOT forward that header element to the next application in the
>  SOAP message path. The recipient MAY insert a similar header
>  element but in that case, the contract is between that
>  application and the recipient of that header element.
> <snipet of SOAP 1.0 >
>
> <snipet of SOAP 1.1 >
>  3.2 The "mustUnderstand" Attribute
>  ...
>  A env:mustUnderstand value of "true" means that the SOAP node
>  must process the header with the semantics described in that
>  header's specification, or else generate a SOAP fault.
>  Processing the header appropriately may include removing the
>  header from any generated SOAP message, reinserting the header
>  with the same or altered value, or inserting a new header.
>  The inability to process a mandatory header requires that all
>  further processing of the SOAP message cease, and a SOAP fault
>  be generated. The message is not forwarded any further.
> <snipet of SOAP 1.1 >
>
> | Another facet to consider is that deployment descriptors
> | should represent options that may be enabled at deployment
> | time. A handler is either built to process a header or not.
> | A deployment marker has no influence on the run-time
> | operation of the handler.
>
>   Are you sure ?  How do you like passing a set of parameters
> to handler ? Axis has been using the configuration with wsdd.
>
>   Could you let me know your thought for "Axis vs. JAX-RPC" ?
>
> ---
> Toshi <toshi@apache.org>
>

Mime
View raw message