Rockford Lhotka

 Monday, January 24, 2005
« Thoughts on passing DataSet objects via ... | Main | Web services, DataSets and now...Busines... »

OK, so Shawn has some good points about the use of a DataSet for the purpose of establishing a formal contract for your web service messages. This is in response to my previous entry about not using DataSets across web services.

 

The really big distinction between using web services for SO vs n-tier remains.

 

If you are doing SO, you need to clearly define your message schema, and that schema must be independent from your internal data structures or representations. This independence is critical for encapsulation and is a core part of the SO philosophy. Your service interface must be independent from your service implementation.

 

What technology you use to define your schema is really up to you. Shawn’s entry points out that you can use strongly typed DataSet objects to generate the schema – something I suppose I knew subconsciously but didn’t really connect until he brought it up. Thank you Shawn!

 

Any tool that generates an XSD will work to define your schema, and from there you can define proxy classes (or apparently use DataSet objects as proxies). Alternately you can create your “schema” in VB or C# code and get the XSD from the code using the wsdl.exe tool from the .NET SDK (though you have less control over the XSD this way).

 

But my core point remains, that this is all about defining your interface, and should not be confused with defining your implementation. Using a DataSet for a proxy is (according to Shawn) a great thing, and I’ll roll with that.

 

But to use that same DataSet all the way down into your business and data code is dangerous and fragile. That directly breaks encapsulation and makes you subject to horrific versioning issues.

 

And versioning is the big bugaboo hiding in web services. Web services have no decent versioning story. At the service API level the story is the same as it was for COM and DCOM – which was really bad and I believe ultimately helped drive the success of Java and .NET.

 

At the schema level the versioning story is better. It is possible to have your service accept different variations on your XML schema, and you can adapt to the various versions. But this implies that your service (or a pre-filter/adapter) isn’t tightly coupled to some specific implementation. I fear that DataSets offer a poor answer in this case.

 

And in any case, if you to create maintainable code you must be able to alter your internal implementation and data representation independently from your external contract. The XSD that all your clients rely on can’t change easily, and you must be able to change your internal structures more rapidly to accommodate changing requirements over time.

 

Again, I’m talking about SO here. If you are using web services for n-tier then the rules are all different.

 

In the n-tier world, your tiers are tightly coupled to start with. They are merely physical deployments of layers, and layers trust each other implicitly because they are just a logical organization of the code inside your single application. While there are still some real-world versioning issues involved, the fact is that they aren’t remotely comparable to the issues faced in the SO world.