Hi Steve, Glen and all of axis-dev folks,
Despite no ACK, I'd like to carry on a one-sided conversation. :-)
> Now, even though we take the "pre-flight-check" logic, it still
>might be scant. Please refer to the attached. I pointed out two
>problems on it.
> Do you already have any ideas for these problems ?
[Report of issues]
1) How can we recognize that which of the MU headers are
bound for the runtime to do process ?
2) Without the execution of the registered JAX-RPC handlers,
we never know whether all MU headers are processable, or not.
[Proposal]
Abstract:
In order to solve the above two issues, I'd like to propose
an enhancement to the description rules for wsdd (Web Services
Deployment Descriptor) of Axis.
Detail:
- Specify a new node "delegatedMUheader", to make clear
the deployer's belief that which of the MU headers are
bound for the runtime to do process
- Specify a new node "responsibleMUheander", to make clear
a chosen handler instance is responsible to the specified
MU headers for processing
Note:
- Axis can exclude un-supported MU headers when a user deploys
a Web Service with the "enhanced" wsdd.
- Axis can know which MU headers are bound for me (i.e. JAX-RPC
runtime implementation), determinately.
- Axis can know whether an MU header is processable or not
without the execution of any user implementations.
- Axis will take care of a MU header, if either conditions are met.
a) A "delegatedMUheader" node is defined in wsdd clearly.
b) A "delegatedMUheader" node is NOT defined in wsdd, but the
targeted MU header is also NOT listed in "handlerInfoChain"
as a "responsibleMUheander" node.
[Sample of wsdd file]
Please pay attention to the highlighted lines below with "|".
These lines are expanded.
.........*.........*.........*.........*.........*.........*.........*
<deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="jaxrpchandler" provider="java:RPC">
| <delegatedMUheader name="MuHeaderName1"value="URI1"/>
| <delegatedMUheader name="MuHeaderName2"value="URI2"/>
| <delegatedMUheader name="MuHeaderName3"value="URI3"/>
| <delegatedMUheader name="MuHeaderName4"value="URI4"/>
<handlerInfoChain>
<handlerInfo classname="test.ServerHandler1">
| <responsibleMUheander name="MuHeaderName5"value="URI5">
| <responsibleMUheander name="MuHeaderName6"value="URI6">
</handlerInfo>
<handlerInfo classname="test.ServerHandler2"/>
<handlerInfo classname="test.ServerHandler3">
| <responsibleMUheander name="MuHeaderName1"value="URI1">
</handlerInfo>
</handlerInfoChain>
<parameter name="className" value="test.StockQuoteImpl"/>
<parameter name="allowedMethods" value="getQuote"/>
<parameter name="wsdlServicePort" value="GetQuote"/>
</service>
</deployment>
.........*.........*.........*.........*.........*.........*.........*
Any constructive comments, objections, and an approval will be
appreciated. If you can't see the above issues, please feel free
to ask me.
Regards,
Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
-----Original Message-----
From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 7:53 PM
To: [EMAIL PROTECTED]
Subject: Re: MustUnderstand faults
Hi Steve and Glen,
> > Glen> In cases where no back-end state is affected by
> > Glen> the service invocation (i.e. all the interop tests),
> > Glen> it doesn't actually matter.
> >
> Steve> I think its trivial to test, as its almost the same
> Steve> as the test that a service is stateful.
>
Glen> I didn't say it was difficult or complicated...
Glen> I said it was subtle. :)
It seems that even if MU headers are not understood by the
targeted end-point, you accept a service invocation which has
no back-end state. Right ?
In my humble opinion, the checking of MU headers should
be cared *before* the service invocation. Could you take a
look at the following snippets ?
<snippet of JAX-RPC 1.0 spec>
If one or more of the header blocks identified in the preceding
step are not understood by this node then generate a single SOAP
MustUnderstand fault. If such a fault is generated, any further
processing is not done.
</snippet of JAX-RPC 1.0 spec>
On the other hand, there is another issue to be discussed. The
point is a role of the SOAP mustUnderstand attribute. I believe
that the MU attribute is not only for the runtime, but also for
an end-point implementation.
Or rather, I think that we should care more prudently how the
end-point process the attribute. Because the final destination
of the MU header is JAX-RPC handlers of the Web Service impl.
(i.e. The JAX-RPC runtime like as Axis is just an intermediator.)
Thus, I agreed you on "pre-flight-check" in my last mail.
Now, even though we take the "pre-flight-check" logic, it still
might be scant. Please refer to the attached. I pointed out two
problems on it.
Do you already have any ideas for these problems ?
Regards,
Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
