I agree that interoperability is important, not just with Axis2 but
also with other Web Service stacks out there.
The best guide to industry standard Web Service interoperability
that I am aware of is the WS-I Basic Profile.
If we send an empty body in the case of a no-argument Java method
(as this form of WSDL would imply), and if more than one method on a
service interface can have a no-argument signature, then this would
violate the following requirement for WS-I interoperabilty:
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result
in operation signatures that are different from one another.
If we (or the Axis2 runtime) rely on the soap:action to disambiguate
these operations (as was suggested in a previous post to this thread),
then this would violate the following WS-I requirement:
R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP
header to correctly process the message. [SOAP12]
However if we are using WS-Addressing then it would be valid from a
WS-I perspective to use wsa:Action to disambiguate the operations.
We are using parts of WS-Addressing but I don't think we are currently
fully compliant.
I'm doing further investigation into how Axis2 disambiguates the case
of two different service operations without arguments that are both
mapped to an empty body in the SOAP message. If anyone can give me a
pointer to the relevant code, it would be much appreciated.
Simon
ant elder wrote:
But doesn't that mean we're not going to work with wsdl generated by Axis2
tooling (and likely others) and all the existing services using that wsdl
and returning it with ?wsdl.
Its even debatable the wsdl is "wrong" as wrapped style has been used long
before jaxws came along but never precisely defined in any spec. I'd still
prefer we just make Tuscany tolerant of it than try to fiddle about changing
the wsdl that people are trying to use.
...ant
On 9/5/07, Simon Nash <[EMAIL PROTECTED]> wrote:
I have concerns about making the Tuscany code wrong to compensate for
the generated WSDL being wrong. This feels like a step in the wrong
direction, and it won't allow non-Tuscany Web service clients to call
Tuscany services that use generated WSDL.
Instead, I'd prefer to have Tuscany postprocess the incorrect
WSDLDefinition returned by the Axis2 generator and fix it up so that
it's correct. The seems much cleaner and more robust that having
Tuscany override parts of the Axis2 generator code. If in future
the Axis2 code returns a correct WSDLDefinition, then the Tuscany
postprocessor can just pass it through unchanged.
I am willing to take on the task of implementing this.
Simon
ant elder wrote:
On 9/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 8/31/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 8/31/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
The operation.getInput() cannot be null to qualify for the wrapper
style.
There must be a part in the input message corresponding to the
operation
name:
input
--- message
--- part (only one part)
--- element (the element name should be the same as
the
operation name)
The element should look like this:
<element name="myMethod">
<complexType>
<sequence/> <!-- an empty sequence -->
</complexType>
</element>
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Friday, August 31, 2007 10:34 AM
Subject: Wrapper style test in WSDL processing?
There is a test to determine whether a WSDL operation follows the
"wrapped"
style in accordance with JAX-WS 2.0 spec. See
WSDLOperationIntrospectorImpl
(
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
)
The code is currently
public boolean isWrapperStyle() throws InvalidWSDLException {
if (wrapperStyle == null) {
wrapperStyle =
wrapper.getInputChildElements() != null && (
operation.getOutput() == null || wrapper
.getOutputChildElements() != null);
}
return wrapperStyle;
}
Which doesn't seem to cater for the case where there may be no input
parameters. I'm diving into this code now to see if I can work out
what it
means but if anyone has any insight I would appreciate it.
Needless to say I have a scenario where I am trying to auto generate
WSDL
for a method with the signature
String myMethod()
And it's complaining that it's not wrapped.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
What you are saying sounds right to me, I.e. you can validly have no
parameters in your method but in this case it should build an empty
sequence
<element name="myMethod">
<complexType>
<sequence/> <!-- an empty sequence -->
</complexType>
</element>
And have this as the single input type. I'm deeper into the code now
looking for why this isn't the case.
Thanks Raymond
Simon
I've done a bit more investigation now. For the signature
String foo()
Axis2 Java2WSDL generates
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://test/xsd";>
<xs:element name="fooResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" nillable="true"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="fooMessage" />
<wsdl:message name="fooResponseMessage">
<wsdl:part name="part1" element="ns:fooResponse" />
</wsdl:message>
So in our code when it comes to testing for wrapped it returns false
because
this doesn't match the algorithm that was presented earlier in this
thread,
i.e. there is no part of the input message corresponding to the message
name. So when you try this in Tuscany is throws an exception saying that
the
operation is not wrapped.
It would be inconvenient for us to not support operations with no
parameters. As the wsdl generation process assumes that the target
operations will be generated as wrapped operations here's what I did..
1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
to
read.
public boolean isWrapperStyle() throws InvalidWSDLException {
if (wrapperStyle == null) {
wrapperStyle =
(operation.getInput
().getMessage().getParts().values().size()
== 0 ||wrapper.getInputChildElements() != null) &&
(operation.getOutput() == null ||
wrapper.getOutputChildElements() != null);
}
return wrapperStyle;
}
I.e. I'm letting it pass if there are no input parts at all which I
believe
is valid according the the JAX-WS 2.0 spec
2/ Fixed the getWrapperInfo method to take account of the case where
there
are no input params
if (in != null) {
for (XmlSchemaElement e : getInputChildElements()) {
inChildren.add(getElementInfo(e));
}
}
3/ Fixed the Axis2 binding to properly deal with the case when no
parameters
are present in Axis2ServiceInOutSyncMessageReceiver.
public void invokeBusinessLogic(MessageContext inMC, MessageContext
outMC) throws AxisFault {
try {
OMElement requestOM = inMC.getEnvelope
().getBody().getFirstElement();
Object[] args = null;
if (requestOM != null) {
args = new Object[] {requestOM};
}
The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
This works with the forward message relying on the soap action to
indentify
the correct operation.
I haven't checked this in as the code seems to have been carefully
crafted
to assume that there will always be an input parameter. Can someone
explain
why this is thought to be the case?
If there's no objections very soon then how about just doing this fix
for
now so Tuscany tolerates the Axis2 way for now (and something similar
for
TUSCANY-1658)?
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
