I would expect another SOAP toolkit to croak on this WSDL. The big issue is that it hasn't imported the apachesoap namespace, therefore there's no definition of the apachesoap:Document type.
Note that this WSDL creates a wrapper element for the input document (tns1:request) and the output document (impl:processRequestReturn), so I don't think it's quite what you wanted (arbitrary input and output documents). There's another problem in the WSDL -- the <wsdlsoap:body> elements should not include the namespace attributes. Are you using the latest build? This problem should have been fixed in the latest beta. Anne -----Original Message----- From: Dave Anderer [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 3:59 PM To: [EMAIL PROTECTED] Subject: newbie .net interop question The goal is to have a simple service that can accept and return an arbitrary XML document. Environment is Axis 1.2 beta. Given a method definition: public Document processRequest(Document request) ..and a deployment descriptor: <service name="RequestFromVendorService" style="document"> <requestFlow> <..some handlers..> </requestFlow> <responseFlow> <..some handlers..> </responseFlow> <parameter name="className" value="com.abc.midtier.RequestFromVendorService" /> <parameter name="allowedMethods" value="processRequest" /> </service> This yields the following WSDL: <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://localhost:8080/gvi/services/RequestFromVendorService " xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://localhost:8080/gvi/services/RequestFromVendorService" xmlns:intf="http://localhost:8080/gvi/services/RequestFromVendorService" xmlns:tns1="http://midtier.abc.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <!--WSDL created by Apache Axis version: 1.2beta Built on Mar 31, 2004 (12:47:03 EST)--> <wsdl:types> <schema elementFormDefault="qualified" targetNamespace="http://midtier.abc.com" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="request" type="apachesoap:Document"/> </schema> <schema elementFormDefault="qualified" targetNamespace="http://localhost:8080/gvi/services/RequestFromVendorService " xmlns="http://www.w3.org/2001/XMLSchema"> <element name="processRequestReturn" type="apachesoap:Document"/> </schema> </wsdl:types> <wsdl:message name="processRequestResponse"> <wsdl:part element="impl:processRequestReturn" name="processRequestReturn"/> </wsdl:message> <wsdl:message name="processRequestRequest"> <wsdl:part element="tns1:request" name="request"/> </wsdl:message> <wsdl:portType name="RequestFromVendorService"> <wsdl:operation name="processRequest" parameterOrder="request"> <wsdl:input message="impl:processRequestRequest" name="processRequestRequest"/> <wsdl:output message="impl:processRequestResponse" name="processRequestResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RequestFromVendorServiceSoapBinding" type="impl:RequestFromVendorService"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="processRequest"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="processRequestRequest"> <wsdlsoap:body namespace="http://midtier.abc.com" use="literal"/> </wsdl:input> <wsdl:output name="processRequestResponse"> <wsdlsoap:body namespace="http://localhost:8080/gvi/services/RequestFromVendorService" use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="RequestFromVendorServiceService"> <wsdl:port binding="impl:RequestFromVendorServiceSoapBinding" name="RequestFromVendorService"> <wsdlsoap:address location="http://localhost:8080/gvi/services/RequestFromVendorService"/> </wsdl:port> </wsdl:service> </wsdl:definitions> All looks good to me, and WSDL2Java handles it nicely. However, should someone using the .net toolset be able to take this WSDL, automatically generate their required proxies, and use them? I've got a report from a user who says their tools either die on this, or report no errors, but generate no proxies.
