I am often asked about the suitability of using datasets as the message types to web services. There are a number of issues with doing this, specifically around interoperability.

Web services provide a great mechanism for exposing programmatic end-points over the internet that can be easily consumed by client applications, regardless of the platform or programming language used. Having Web services return datasets is very useful for .NET-based clients; however, they can be problematic for other consumer platforms. Some background will help understand why.

The reason that Web services are so universally consumable is because their interfaces are defined in terms of schema and contract. When a development environment (such as Visual Studio .NET) references the WSDL description of a web service and associated schema, a client-side proxy is generated which contains data structures that correspond to the schema types which describe the parameters of the Web service methods. For convenience, these data-structures are typically mapped onto a synthesized class in your language of choice. That is to say, there is no shared type relationship between the client and the server, simply a shared understanding of how the message is structured. Contrast this with a typical .NET remoting application where the implementation of types that are shared between the client and server need to reside on both the client and the server.

In the case of a .NET dataset, the runtime generated schema for the dataset provides a hint to consumers in the form of the msdata:IsDataset=”true” attribute. This hint enables .NET client tools to generate code that deserializes the XML stream into the .NET Dataset type, i.e., there is a shared dataset type implementation between the client and server. As this is the same dataset type that was implemented on the server, the client is able to use the dataset object to manipulate the XML stream as appropriate (through the dataset api), which is a big help not only for consuming datasets, but for also sending back to the server updated datasets that are encoded using diff grams.

Non .NET clients can work with dataset-based types, but have to manually manipulate the XML structures, which can quite a bit of work, and a good understanding of how data and associated updates are encoded in XML.

The article Web services and Datasets (http://msdn.microsoft.com/msdnmag/issues/03/04/XMLFiles/default.aspx) provides a far more detailed explanation of this topic, and discusses a number of ways of returning non-simple data types to clients.