Toshi - The SOAP processing rules are orthogonal to the constraints imposed upon handlers.
http://www.mail-archive.com/[EMAIL PROTECTED]/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 <[EMAIL PROTECTED]> >
