DataSets Considered Harmful (part 1): Interoperability

@YaronNaveh

There are various reasons why you do not want to expose System.DataSet in your web service contract. One reason is interoperability: Non-.Net clients will have hard time consuming such services. Let’s see how the schema of a service with DataSet looks like.

Service

public interface MyService
{
    public void MyOperation(DataSet value);
}

Wsdl

<xs:element minOccurs="0" name="value" nillable="true">
          <xs:complexType>
            <xs:annotation>
              <xs:appinfo>
                <ActualType Name="DataSet" Namespace="http://schemas.datacontract.org/2004/07/System.Data" xmlns="http://schemas.microsoft.com/2003/10/Serialization/" />
              </xs:appinfo>
            </xs:annotation>
            <xs:sequence>
              <xs:element ref="xs:schema" />
              <xs:any />
            </xs:sequence>
          </xs:complexType>
</xs:element>

The “DataSet-ness” of the element is expressed inside an “appinfo” element. Also it is under a Microsoft specific namespace. This means only .Net clients can understand the semantic of this type.

To be specific, the actual content of the schema type is an “any” element. This is an xml “wildcard” that allows to put any arbitrary xml inside it. This has very bad interoperability and usability implications. To begin with, a client application cannot know the on-the-wire format of xml instances from this wsdl as it is not typed. The format is dependent in the implementation (DataSet). This breaks one of the SOA main tenets “Service API should rely on Contract.”

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!