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
