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>
>
|