axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toshiyuki Kimura" <>
Subject Re: MustUnderstand faults
Date Thu, 14 Aug 2003 02:48:54 GMT
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
  - 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