Toshi - I admire your goal of enhancing the capabilities of JAX-RPC handlers while attempting to eliminate code changes to JAX-RPC compliant handlers. Would you agree that the JAX-RPC specification and API is broken in regards to the processing of MU headers?
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). Given that there are API changes required to allow the JAX-RPC specification to fully support MU header processing, additions to the deployment descriptors are a partial solution that will only make Axis more complicated. 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. /Chris ---------- Original Message ---------------------------------- From: "Toshiyuki Kimura" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Thu, 14 Aug 2003 11:48:54 +0900 >Hi Chris, > > My proposal is based on the conditions as follows; > > - I want to improve usability of JAX-RPC users on Axis. > - As a general rule, I don't want to change (i.e. add, > remove, or extend) the JAX-RPC APIs as the standard. > - If any enhancements are required, the change should > be minimum for its users, and be guaranteed backward > compatibility. > - Furthermore, the enhancements would be better off > going to be standardized so far as possible. > - If we've any choice to avoid the problem except with > nonstandard mechanism, we'd be better to take a way > near the standard. > > Now, we're able to update any APIs for Axis handler, >however it won't be appreciated by JAX-RPC users. The >last proposal which I posted, is an effort to solve >the MU headers problem except with an API enhancement. >I think the root problem is still; > "- Axis Handler - vs. - JAX-RPC Handler - " > >I'm not sure how can we reach a consensus, right now ... > >Thanks, > > Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]> > R&D Headquarters > NTT DATA Corporation > >-----Original Message----- >From: Chris Haddad [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 13, 2003 10:08 PM >To: [EMAIL PROTECTED] >Subject: Re: MustUnderstand faults > >Toshi - > >i'm still missing the improvement that your proposal will add to Axis. > >The canHandleBlock() and getUnderstoodHeaders() methods provide all the >information required to determine the header processing capabilities of >the chain. Moving this information into an XML based configuration >doesn't provide added value and has the drawback of separating the >implementation from the specification; increasing the likelyhood of >synchronization issues. > >What advantage does a MU marker interface add? Handlers by nature can >process headers, and a marker is only really useful if it indicates the >QName of the header that can be processed. the marker interface will >therefore not be a standalone entity and there will still be a need for a >getUnderstoodHeaders method. > >MU is an attribute that is specified by the ws-client not the >server. A server implementation only knows what header QNames >can be processed, not that the processing of the header will be >required by the client. > >/Chris > >On Wed, 13 Aug 2003, Toshiyuki Kimura wrote: > >> Hi Glen! >> >> Nice to hear from you !! >> >> > I hope you don't mind my stepping in - you seem to be doing >> > just fine on your own though... :) >> >> "stepping in"? - No, I think that you are also the leading cast >> in this thread. That's warmly welcomed any time. :-) >> >> >> 2) Without the execution of the registered JAX-RPC handlers, >> >> we never know whether all MU headers are processable or not. >> > >> > Actually, it's even worse than that. There doesn't seem to be a >> > JAX-RPC API for marking a header as processed... so if you're >> > programming strictly in JAX-RPC, I don't see how you can get this >> > working at all. >> > >> > That said, I think we should focus on getting the Axis mechanism >> > for this as clean and functional as possible, then take JAX-RPC >> > issues up with the JAX-RPC group (I'm a member, as is Russell >> > Butek who used to work a lot on Axis). >> >> Sure, I know you're a member of JAX-RPC (JSR-101) Expert Group, >> not an ordinary member. And I'm also doing paperwork to join the >> group as a member. >> Because I'd like to have a direct connection to the Expert Group. >> A couple of weeks ago, as you may know, I sent a question to them >> with mediation by Roberto Chinnici who is the specification lead >> of JSR 224 (JAX-RPC 2.0). But, I've never received any response. >> >> Anyway, I agree with you that Axis handler has advantages of >> extensibility and easy to update, because we are Axis committer. >> At the same time, I hate a version fork on "Handler Architecture". >> (i.e. - Axis Handler - vs. - JAX-RPC Handler -) >> >> Please note I don't want to make a denial of "Axis Handler", >> I just want to assist users of JAX-RPC Handler on Axis with >> my humble contributions. >> >> > While this would work, I don't like the fact that it provides >> > another place where configuration and code can get out of sync. >> > The code of a given Handler is the final arbiter of which headers >> > it can process and which ones it can't - so I think the code >> > should be responsible for filling in the engine's registry. >> > This is why we have the canHandleBlock() API, and that can be >> > used (for Axis handlers) to do what we need. For JAX-RPC handlers, >> > I agree a separate mechanism is needed, and maybe we can do a >> > simplified version of what you suggest for JAX-RPC HandlerChains. >> > But I don't think this should be the default way of dealing with >> > the problem. >> >> I'd noticed the sync problem, before I sent the last mail. >> How do you strictly clear the problem ? It's very difficult, >> even if you add any APIs to Axis handlers. >> >> That's like as the Serializable problems on Java language. >> If an object implements the Serializable interface, the object >> must be serializable. "No". - The Serializable interface is >> a Marker Interface which doesn't actually define any fields. >> >> If we define a new Marker Interface to indicate a capability >> for MU headers, it won't enough to know an implementation is >> really implement the capability. >> >> Thus, I proposed the XML configuration based architecture. >> >> Thanks, >> >> Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]> >> R&D Headquarters >> NTT DATA Corporation >> > >
