Hi Glan,Cris,Toshi and All, Am with Glan idea, That was what I want to clear in the first place.
The SOAP intermediate(SOAP node) is a Axis server... not a Handler ....(I think the Cris make it quite clear). The SOAP spec talk about nodes ..not about handlers(i belive)... The processing (MU headers and headers in general) is done Node to node. > Handler is not a SOAP Node itself, so it doesn't have to do anything > to the headers to pass them along to the next Handler. Otherwise > you'd have to do MU checking/processing at EACH Handler, which would > be bad. Does that mean ..if the role is next in the Header that added in this node .. it SHOULD be processed in the NEXT node. next == NEXT NODE ??? hope am making sense .. thanks for your time ...I found the dicussion quite intersting regards Srinath On Tue, 19 Aug 2003 14:57:38 -0400, Glen Daniels wrote > Hopping in here again... sorry for the delay in replying. I know > this conversation has progressed from here, but I wanted to send > this before catching up since I started writing it last week! :) > > > | 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. > > I think you may have misunderstood the SOAP spec, Toshi. When they > talk about the "SOAP Message Path" that means the collection of SOAP > Nodes along a message path - i.e. different servers, each of which > implements the SOAP processing model. As Chris pointed out a > Handler is not a SOAP Node itself, so it doesn't have to do anything > to the headers to pass them along to the next Handler. Otherwise > you'd have to do MU checking/processing at EACH Handler, which would > be bad. > > I was talking to Marc Hadley from Sun at XML/WS One and he mentioned > that JAX-RPC's handler architecture supports MUs declaratively - in > other words, the deployment descriptor for a given handler states > which QNames are understood by that handler. I haven't looked into > this code in a while, but we must support this pattern as well (if > the TCK tests it). So that's good enough to calm my worries. > > Also, the "processed" flag should really be renamed to "understood" > for Axis. It's not strictly an indication that the header was > *successfully* processed, just that it was in fact understood by the > Handler in question. > > I still like the "up front" checking for this (which is the same > pattern as JAX-RPC uses) rather than the check-on-the-way-through. > > > | 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. > > A given Handler can process a certain number of QNames. That > handler can either get that list of "understood" QNames > declaratively (from config metadata) or programatically (in the code) > , however for maximal flexibility it should be asked about it at > runtime in either case. Since the code is really the final arbiter - > in other words, you probably wrote the code for a Handler while > looking at the spec for some particular set of headers - we should > support the idea that Handlers can just know which headers they support. > > --G -- Lanka Software Foundation (http://www.opensource.lk) Promoting Open-Source Development in Sri Lanka
