axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chaddad" <>
Subject Re: MustUnderstand faults
Date Thu, 14 Aug 2003 13:43:07 GMT
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.


---------- Original Message ----------------------------------
From: "Toshiyuki Kimura" <>
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 ...
>  Toshi (Toshiyuki Kimura) <>
>  R&D Headquarters
>  NTT DATA Corporation
>-----Original Message-----
>From: Chris Haddad []
>Sent: Wednesday, August 13, 2003 10:08 PM
>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.
>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) <>
>>   R&D Headquarters
>>   NTT DATA Corporation

View raw message