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.
<http://marc.theaimsgroup.com/?l=axis-dev&m=106120252307587&w=2>
--
Toshi <[EMAIL PROTECTED]>
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2003 9:05 PM
To: [EMAIL PROTECTED]
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
next
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
regards
Srinath
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;
> "http://marc.theaimsgroup.com/?l=axis-dev&m=106032619706497&w=2";
>
> 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 <[EMAIL PROTECTED]>
>
> -----Original Message-----
> From: Chris Haddad [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 15, 2003 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: MustUnderstand faults
>
> Toshi -
>
> The SOAP processing rules are orthogonal to the constraints
> imposed upon handlers.
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg11922.html
> 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
