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 <[EMAIL PROTECTED]>
