Web service interoperability issue

We have a legacy web service implemented in Java which was recently updated to add an additional flavor to some existing transaction. The result was that we needed to consume both the old web method and the new one from different parts of the same application.

If you are trying to call a web service developed in a technology different from that of .NET, there is one thing that you need to keep in mind, especially if you have a very distributed environment with a lot of web services and have different implementations of the same web method. This is an issue that is only encountered with a .NET proxy client when referencing a non-.NET web service and when the web methods differ only by the SOAP action header. Yes, certain technologies other than .NET, allow a web service provider to create a web service with multiple methods with the same wire signature, differing only by the SOAP action header.

This is a valid scenario as often the web service developer would like to share the schema especially in the cases where the web methods differ only by the implementation and primarily meant to be different flavors of the same transaction.

In a wsdl such operations might be defined as follows:-

<wsdl:operation name=”Method1″>
<soap:operation soapAction=”Method1SOAPAction” style=”document”/>
<wsdl:input>
<soap:body use=”literal”/>
</wsdl:input>
<wsdl:output>
<soap:body use=”literal”/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name=”Method2″>
<soap:operation soapAction=”Method2SOAPAction” style=”document”/>
<wsdl:input>
<soap:body use=”literal”/>
</wsdl:input>
<wsdl:output>
<soap:body use=”literal”/>
</wsdl:output>
</wsdl:operation>

The problem here is that when adding a web reference to such a web service, Visual Studio does not throw an error and allows you to create the web reference successfully. However, during runtime it fails while instantiating the proxy and instead throws an exception. The details of such an exception would look as below:-

System.InvalidOperationException: Method TestWebReference.SecondOperationName can not be reflected. —> System.InvalidOperationException: The XML element ‘DuplicateElementName’ from namespace ‘http://tempuri.org/Transactions/schemas’ references a method and a type. Change the method’s message name using WebMethodAttribute or change the type’s root element using the XmlRootAttribute.\r\n   at System.Xml.Serialization.XmlReflectionImporter.ReconcileAccessor(Accessor accessor, NameTable accessors)\r\n   at System.Xml.Serialization.XmlReflectionImporter.ImportMembersMapping(String elementName, String ns, XmlReflectionMember[] members, Boolean hasWrapperElement, Boolean rpc, Boolean openModel, XmlMappingAccess access)\r\n   at System.Web.Services.Protocols.SoapReflector.ImportMembersMapping(XmlReflectionImporter xmlImporter, SoapReflectionImporter soapImporter, Boolean serviceDefaultIsEncoded, Boolean rpc, SoapBindingUse use, SoapParameterStyle paramStyle, String elementName, String elementNamespace, Boolean nsIsDefault, XmlReflectionMember[] members, Boolean validate, Boolean openModel, String key, Boolean writeAccess)\r\n   at System.Web.Services.Protocols.SoapReflector.ReflectMethod(LogicalMethodInfo methodInfo, Boolean client, XmlReflectionImporter xmlImporter, SoapReflectionImporter soapImporter, String defaultNs)\r\n   — End of inner exception stack trace —\r\n   at System.Web.Services.Protocols.SoapReflector.ReflectMethod(LogicalMethodInfo methodInfo, Boolean client, XmlReflectionImporter xmlImporter, SoapReflectionImporter soapImporter, String defaultNs)\r\n   at System.Web.Services.Protocols.SoapClientType.GenerateXmlMappings(Type type, ArrayList soapMethodList, String serviceNamespace, Boolean serviceDefaultIsEncoded, ArrayList mappings)\r\n   at System.Web.Services.Protocols.SoapClientType..ctor(Type type)\r\n   at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()\r\n   at TestApplication.TestWebReference. TestWebReference..ctor() in C:\\DOTNET\\ASP.NET\\ TestApplication\\Web References\\ TestWebReference\\Reference.cs:line 39\r\n   at TestApplication._Default.Page_Load(Object sender, EventArgs e) in C:\\DOTNET\\ASP.NET\\TestApplication\\Default.aspx.cs:line 16

When using the Web Services Description Language Tool – wsdl.exe to generate a proxy, it actually displays a warning describing the problem. However, it still generates the proxy. I fail to understand what is the purpose of a proxy that cannot be instantiated. Besides, Visual Studio does not even show any warnings. That is very disappointing.

Microsoft (R) Web Services Description Language Utility

[Microsoft (R) .NET Framework, Version 4.0.30319.1]

Copyright (C) Microsoft Corporation. All rights reserved.

Warning: This web reference does not conform to WS-I Basic Profile v1.1.

R2710: The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another. An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique wire signature.

–  Input message ‘OperationSoapIn’ from namespace ‘http://tempuri.org/Transactions/schemas’ has wire signature ‘http://tempuri.org/Transactions/schemas:DuplicateElementName’.

–  Input message ‘OperationSoapIn’ from namespace ‘http://tempuri.org/Transactions/schemas’ has wire signature ‘http://tempuri.org/Transactions/schemas:DuplicateElementName’.

For more details on the WS-I Basic Profile v1.1, see the specification at http://www.ws-i.org/Profiles/BasicProfile-1.1.html.

Writing file ‘C:\DOTNET\ASP.NET \TestWebReference.cs’.

It seems during instantiation of the proxy, the .NET runtime uses Reflection to create various types presumably for serialization purposes and hence based on the SOAP messages to be emitted on the wire. It seems like this process fails for some reason, presumably due to a name clash, during the processing of the second operation.

What this means, is that even if you specify a WebMethodAttribute or XMLRootAttribute as suggested in the exception message, it still fails during instantiation of the proxy to create two different classes of the same name within the same namespace.

So far the only solution is to change the schema or namespace in the web service so that the SOAP wire signature of the two operations is different. Or a more time consuming one would be to not use a web reference at all.

This problem has also been discussed here:-

One thought on “Web service interoperability issue”

  1. And these figures had a variety of other things in common, besides just
    being women. The College closed in 1968 along with the newly-rebuilt structure was converted into the current Retreat Center, an area contemplation and spiritual reflection. It is
    one of the 3 round churches which can be still in existence inside
    the city.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>