Add service link: streamlining serialization fields

Question

I am writing a C # web service client in Visual Studio 2008 with the Java web service endpoint. I do not control the endpoint and the SOAP messages it sends back.

I created an auto-generated proxy client from the WSDL web service using the "Add Service" link in Visual Studio. When I submit my request, I get a valid SOAP message that contains something like this:

<java:a_field xmlns:java="java:com.whatever">Value1</java:a_field> <java:different_field xmlns:java="java:com.whatever">Value2</java:different_field> 

However, he does not actually analyze these two values, and after that all values ​​are equal to zero. After debugging, I found that this code in Reference.cs auto-generated was a problem:

 [System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Order=30)] public string different_field { get { return this.different_fieldField; } set { this.different_fieldField = value; this.RaisePropertyChanged("different_field"); } } /// <remarks/> [System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Order=31)] public string a_field { get { return this.a_fieldField; } set { this.a_fieldField = value; this.RaisePropertyChanged("a_field"); } } 

These two fields fail, so they do not serialize them correctly, and the remaining fields are not serialized at all. The WSDL itself declares the fields in the same order in which the proxy class expects them, this is only the actual answer that changes the order. I can get around this by manually changing the two Order = values, but it will be a huge pain to maintain, given that WSDLs change frequently, and there are 100 fields that need to be checked for this kind of error. Is there a better way for me to ignore this mismatch and still use the auto-generated web service proxy?

Answer 1

Considering something like this and knowing that this is a huge pain, I would suggest creating my own “fake” WSDL, which reflects what is actually coming back from the web service, and not what is indicated. The problem seems to be related more to inaccurate XSD, which is part of WSDL. It seems that some of the Java web services frameworks are out of order (or other specifications) strictly by default, and your third-party web service provider may not have the knowledge, resources, or motivation to fix the problem.

It is even better, as a best practice, not to import WSDL at all as a service link, but instead to create interfaces and service proxies manually and by setting either manually or using the WCF configuration editor. There are many resources to do this - Google is your friend.