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 Tue, 19 Aug 2003 10:04:16 GMT
Hi Srinath and All,

  If you assume that the handlers are parts of an ultimate receiver
of JAX-RPC implementation, I think that the following scenario is an
unrecommended usecase.

Because of;
 - A1 has no way programmatically to know whether there're components
   (i.e. A2, A3 ...) behind A1, or not.
 - MU headers should be processed before starting any business logics.
   ( If the MU header, which is added by A1, is refused by A2,
     A2#handleRequest() may need to rollback.  Who and how ??? )

So, I proposed an extension of API as an IF for handling MU headers.

Toshi <>

-----Original Message-----
From: []
Sent: Monday, August 18, 2003 9:05 PM
Subject: Re: MustUnderstand faults

Hi All

This is another prob that (at least to me) goes closly to the discussions.

say there are two handlers A1 and A2 if A1 called before A2 and add a new
Header to the messageContext (message) with the role is "next" then what
should happen next.

Will A2 processed the header (does he is the next ?) or the next is in
SOAPEngine .. where ever it goes....

I was reading SOAP spac and I get the feeling that latter is the case...
Any Ideas....

Thanks for your time

On Sun, 17 Aug 2003 20:39:26 -0700 (PDT), Toshiyuki Kimura wrote
> Hi Chris,
>   I entirely agree with you on valuation of Ann's dissertation.
> However, my conclusion is different from yours;
> [My definition]
>  Intermediary:
>    - It has features as a SOAP server to receive, understand,
>      and process SOAP messages.
>    - It also has features as a SOAP client to invoke, or pass
>      the processed SOAP messages to the next node.
>    - It has a URI to indicate its location.
>    - It has no restriction to implement these features.
>      ( Proxy type, JAX-RPC type, or any others ? )
>  Handler:
>    - It should be called as "SOAP Message Handlers on JAX-RPC
>      specification", in the strict sense of the word.
>    - It is a functionality to implement a JAX-RPC end-point
>      as a Web service implementation, and JAX-RPC client.
>    - The server side handler implementations are a part of
>      a user implementation as an end-point.
>    - Axis Handler is outside the scope of this discussion.
>    Note: - The JAX-RPC handler is the only way to touch SOAP
>            headers on JAX-RPC environment.
>          - The ultimate receiver SOAP node (i.e. an end-point
>            implementation [equiv] handler impl(s) on JAX-RPC)
>            also has to process SOAP headers which may have MU
>            attributes.
> Thus, I said before;
> ""
>   On the other hand, how should we identify our implementation,
> Axis as a JAX-RPC runtime ?  It's standing between a ws client
> and a ws implementation on a server, it's also capabilities for
> processing of SOAP messages. But, Axis has no URI to intercept
> SOAP messages, like as "/soap/servlet/rpcrouter" on Apache SOAP.
>   Nevertheless, I think that we should take care of Axis like as
> an intermediary, because the role is in effect an intermediary.
> ---
> Toshi <>
> -----Original Message-----
> From: Chris Haddad []
> Sent: Friday, August 15, 2003 1:11 PM
> To:
> Subject: Re: MustUnderstand faults
> Toshi -
> The SOAP processing rules are orthogonal to the constraints
> imposed upon handlers.
> 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

View raw message