DataSets and Web services don't mix

The Microsoft .NET Framework has enabled developers to quickly build loosely coupled systems via Web services. In addition to Web services, the .NET Framework provides other benefits for developers. Perhaps one of the most important sets of classes in the .NET Framework is ADO.NET. With ADO.NET, developers can significantly work with disconnected data easier than before. It also allows the data to maintain relationships and referential integrity.

So it would seem only natural that a .NET Web service that is working with a database would want to take advantage of the disconnected data features of ADO.NET, and specifically the DataSet class. Many .NET Web service demos have done just that, creating a Web service that returns a DataSet to be consumed by a UI of some sort, also written in .NET, which can easily bind the data to some controls.

To evaluate the overall solution, developers need to understand that Web services are meant to create technology agnostic sets of functionality -- any client, using any technology, can reuse the features contained in that service. For this to be a "good" Web service, it should be usable by other technologies. Let's take a look at the details of a simple Web service that returns a DataSet and see how it measures up.

After creating a simple WebMethod that returns a DataSet, look at the WSDL (Web Services Description Language) generated by the .NET Framework. Remember that WSDL describes the service, including method names, parameters and return values. This data is used by the .NET Framework WSDL.exe tool, along with other tools in other technologies, to create a proxy class for client to use when accessing the service. A detailed description of the types used as parameters and return values is essential for generating a useful proxy class.

Below is an excerpt from a simple Web service's WSDL that shows the return value of the GetCustomers WebMethod. Notice that GetCustomersResult is actually comp...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Microsoft .NET Web services Microsoft preps .NET 4.0 - framework improves on REST, MVC, JQuery support How do I balance throughput requirements and interoperability? APM software traces transactions across tiers, technologies How you can learn M Grammar for Oslo modeling Legacy modernization opens Windows for publisher Former .NET Web developers ride Ruby and Rails application framework Microsoft Oslo at PDC: Dial 'M' for modeling language Yahoo proxy fight looms New Microsoft site for architects LAMP coders go hybrid route Microsoft .NET Web services Research .NET Developer Programming Indigo Security in .NET 2.0 Tracking down managed memory leaks Handling exceptions in .NET .NET Compact Framework graphics The Data Access Application Block A great .NET resource: .Net2TheMax Delegates vs. interfaces in .NET Project structure best practices Working with PDFs in a .NET environment Data services for SOA SPSS and PMLL Canonical Schema establishes interoperability: SOA Pattern (Week 6) Medical imaging group build HL7 messaging hub with InterSystems Ensemble Using atomicity to gain SOA granularity Use JavaScript with the iPhone to create smart phone apps Componentized XML Query tool takes a step forward Podcast: SearchSOA tips on software architect skills Services reuse drives ROI for SOA, survey finds Tibco releases Complex Event Processing (CEP) suite with new rules, query interfaces MapReduce moves from secret Google goo to enterprise architecture - Part 1

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary Common Language Infrastructure  (SearchSOA.com) Visual J#  (SearchSOA.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

rised of two types -- the first is an XML schema and the second is a type . When the method is executed, it will return a schema describing the result, and then the result itself that could be of any type. This is the WSDL equivalent to late binding.

The first issue is that any tool that attempts to generate a proxy for this service has no way of knowing what to expect. Type checking will have to be done at runtime.

So how does the .NET Framework know when to convert the result into a DataSet for the client proxy? The key is in the actual XML generated from the call. Below is a subset of the XML that is returned when the WebMethod is called with only one row being returned.

The schema definition has three columns in the table defined with their types, but notice the bolded sections. The specification for the schema includes a Microsoft specific namespace and then an attribute from that namespace called "IsDataSet" set to true -- the incoming data is actually an ADO.NET DataSet.

So then, a Java-based client application that has no concept of an ADO.NET DataSet is left having to work with the data strictly as XML. While this doesn't preclude interoperability altogether, it does make it significantly more difficult when the end result is just a list of customers with three fields.

By foregoing the use of a DataSet and using instead an array of custom types, this Web service can be significantly more useful and interoperable. An excerpt of the WSDL for the Web service created using custom types is below.

Notice that it defines the GetCustomers2Result as an array of a complex type with clear definitions for each field. Now even a Java-based tool can generate a useful proxy that will allow the client developer to use our service much more easily.

Paul Ballard is the Editor of TheServerSide.NET Enterprise .NET Community. Paul is an MCSD, MCAD, and MCSE certified consultant with more than 15 years of experience designing and building Windows- and Web-based distributed applications and is currently specializing in Microsoft's .NET technologies as a consultant, speaker, and trainer. Paul is also a volunteer with INETA and the founder of the Central Pennsylvania .NET User Group.