The quiz question is: What is going on here? What was my original code?
The first part in this series discussed various interoperability issues with DataSets. This time I want to discuss the performance implications.
Let us sent the simplest DataSet to some server:
Here is the generated Soap:
This Soap commits two “crimes”. The first one is the embedded schema. Since the wsdl is not typed, .Net must serialize the schema inside the soap. This can have serios performance implications with large schemas.
The second issue is the rowOrder and hasChanges attributes over each data row. In most cases when you just want to pass a snapshot of data to a client so these are simply not required.
The overall result is a bloated Soap without any meaningful benefit.
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.
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.”