axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volanis, Alexander" <>
Subject RE: [BUG] Beta2 interop (was RE: Interoperability issue with MSVC ++.Net)
Date Thu, 16 May 2002 14:45:08 GMT

I am glad there is at least some discussion on this. I agree that the
namespaces are not explicitly required to be the same. This issue exists
only with the VC++.Net proxy generator. The C#.Net and VB.Net are not having
any issue with either one of the problems I outlined.

However, your last statement is exactly about what I am trying to say.
You are getting my assertion backwards, I am not saying the name of the
root return value tag MUST be 'return', I am saying it must be what the
WSDL defines. The VC++.Net parser simply follows the stated name attribute
value as a rule. The issue is that the generated SOAP messages from Axis DO
The Axis SOAP message for the WSDL you provided would be something like:

  <DumpConvHeaderInfoReturn xsi:type="xsd:string">hello

Like I am saying, the WSDL name definition name="return" does not equal
"DumpConvHeaderInfoReturn". What do you think?


-----Original Message-----
From: Chris Haddad []
Sent: Wednesday, May 15, 2002 8:28 PM
Subject: RE: [BUG] Beta2 interop (was RE: Interoperability issue with

Alexander - 

IMHO, the WSDL issue is a .NET problem to solve.  The fact that you can
hack a parseable WSDL definition doesn't prove correctness.  Correctness
is defined based on interpretation of the base specification and
underlying XML schema.

Can you show us in the WSDL specification [1] where the namespaces for
request messages must equal the namespaces for response messages.  I
believe the specification is silent in this regard.

But here's my rational for the fact that it is a .NET issue.  If the
namespaces MUST be the same, wouldn't the creators of the schema placed
the namespace attribute on the enclosing wsdl:operation tag. After all,
if the attribute values were REQUIRED to be the same for wsdl:input and
wsdl:output, then the multiple attribute definition is redundant.  

Also, in regard to the naming of the return value tag, this should be
specified in the WSDL.  You did not show us the WSDL definition such as
the example that follows:
   <wsdl:message name="DumpConvHeaderInfoResponse">
      <wsdl:part name="return" type="SOAP-ENC:string"/>

Again, if the name of the root return value tag MUST be 'return', then
why define an attribute on the part tag defining the response message.
I don't see any reference in the SOAP specification [2] or schema [3] to
back up your assertion.



-----Original Message-----
From: Volanis, Alexander [] 
Sent: Wednesday, May 15, 2002 6:27 PM
To: ''
Subject: RE: [BUG] Beta2 interop (was RE: Interoperability issue with

I would disagree. Correcting the WSDL to reflect the SOAP messages
in a way that is consistent fixes the problem.

There is also the new beta 2 issue that you are not responding to.
The namespace definitions for the operation bindings are no longer the
same between input and output messages.

-----Original Message-----
From: Fred Hartman []
Sent: Thursday, May 16, 2002 5:39 AM
Subject: RE: [BUG] Beta2 interop (was RE: Interoperability issue with

I believe this is a .NET problem.

I understand the naming rules are as follows:

If the part references a simple type, the name of the part is used for
the SOAP:Body element name.

If the part references a complex type, the names of the children of the
complexType are used as the SOAP:Body element names.

If the part references an element, the localName of the element is used
for the SOAP:Body element.


-----Original Message-----
From: Volanis, Alexander [] 
Sent: Wednesday, May 15, 2002 1:35 PM
To: ''
Subject: [BUG] Beta2 interop (was RE: Interoperability issue with

Hi all,

I know you all have a very busy schedule but nobody has acknowledged
this message in the past few days and I am wondering if it was noticed.
I believe there is an interoperability issue here with respect to
written using VC++.Net. If you need additional info I can provide
you need.

Thank you,
Alex Volanis

Consulting Engineer

-----Original Message-----
From: Volanis, Alexander 
Sent: Friday, May 10, 2002 1:50 PM
To: ''
Subject: Interoperability issue with MSVC++.Net

Hi all,

I have developed an Axis RPC web service that works very nicely
with C#.Net and VB.Net clients. Doing the same with VC++.Net which
uses ATL 7.0 to parse the XML messages revealed two issues with the
generated WSDL. 

Issue 1)
The generated WSDL contains response message definitions
that look like this:

<wsdl:message name="methodResponse">
  <wsdl:part name="return" type="tns1:complexTypeResponse" /> 

When the method is invoked the result message looks like this:

  <methodReturn xsi:type="ns2:complexTypeResponse"

MSVC++.Net generates some table based parsing that assumes the
response element will be named "return" instead of "methodReturn".
I looked into the Axis sources but could not pinpoint the problem.
It seems to me that the Java2WSDL should be able to keep the
element name consistent with the method invocation. I tried the
WSDD operation element returnQName attribute but I had no success.
Is the returnQName attribute supported in Axis?

Issue 2)
This problem appeared in beta 2 and I can still see this in the
5/6/2002 nightly build. The problem has to do with the generated
operation bindings. The namespace for input is different from the
namespace for output. The MS service proxy generator utility
stops with an error indicating that namespaces must be the same.
This is what I get for the operation method binding:

<wsdl:operation name="method">
 <wsdlsoap:operation soapAction="" /> 
namespace="method" use="encoded" /> 
namespace="http://localhost:7001/axis/services/test" use="encoded" /> 

Notice how the namespace is the method name for input and the service
URI for output. Both of these problems I can correct by editing the
WSDL but I would rather see the correct WSDL generated instead.

Thank you for your time and this great product!

Alex Volanis

Consulting Engineer

View raw message