Somebody asked:
I created a Web Service from a WSDL that came from Java (Apache SOAP). It contains the definition of Vector as complex type:
<schema targetNamespace=”” xmlns=”“>
<import namespace=””/>
<complexType name=”Vector”>
<sequence>
<element maxOccurs=”unbounded” minOccurs=”0″ name=”item” type=”xsd:anyType”/>
</sequence>
</complexType>
</schema>
Then, .NET generated the following (wrong) class:
<System.Xml.Serialization.SoapTypeAttribute(“Vector”, ““)> _
Public Class Vector
Public item() As Object
End Class
This seems to be correct from my point of view! Maybe not all of you are XSD-literate, but the schema specifically says there is a complex type called Vector, which is a sequence of 1:n of xsd:anyType. .NET (correctly) translates this to an array of Object. This illustrates the danger of including platform-specific types such as Java Vector in a Web Service interface – such types are not easily translatable into and out of XML Schema without some loss of information. Instead, start with XSD Schema, and generate the interface from it. Generate the server skeleton and client-side proxy from the WSDL and XSD.
This is called “contract first”, or “Schema first” design. It’s a Good Thing.
But I know you all are thinking, jeez, I’d really rather use some of the more advanced classes that are available with my platform. A Java Vector or ArrayList for example. Does webservices really make me give that up?
It’s fine to use those things in the implementation of your service, but since there is no well-defined mapping of those Java-specific classes to XSD (and thus, no well-defined mapping of those types to a type on a different, non-Java platform such as .NET), you will get surprises. Stick to XSD for defining the datatypes to be sent and received over a webservice interface, and you will avoid these unpleasant surprises.