Recently I had a discussion with a developer at a client’s office about data types being returned from web services (and data passing strategies in layered applications), and in defense of my arguments I did some research. I ran across some interesting articles and they pointed out some stuff that I did not realize (or did not think about in certain contexts) about SOA and data types.
In actuality, the same thing gets passed back every time from a web service, which is an XML document that is defined by a schema from the WSDL.
I ran into a table (I took out the stuff which does not apply to us) which summarizes the data types and their pros/cons:
|
Abstraction |
Contract standard |
Advantages |
Disadvantages |
|
Text, JSON, binary |
Informal, textual |
Relatively efficient |
Not self-describing, not ideally efficient |
|
Native objects |
Class definition |
Unified behavior and data, encapsulation, high-level abstraction, and composition |
Requires conversion of most data into objects, which requires a mapping technique |
|
XML |
XML schemas (XSD), Relax NG, WSDL, and many others |
Self-describing, rich schema description, and extensible without breaking backward compatibility |
Very size inefficient, no way to distribute behavior, and schema descriptions are limited even with XSD |
In the case of a smart client, it will always be the XML type being passed from a web service to the smart client application. For the most part, I really like the pattern of the smart client talking to a generic service broker web service that accepts a variable number of arguments and returns a generic DataSet. Then once the client gets the DataSet (deserialized of course), it can do whatever it wants with it. That contract should never be broken, at least at design time it will not. What a DataSet does is it gives you a common abstraction to all data, which gives you a single unified model to work with. That is very appealing for all of the reasons that we discussed earlier.
What could happen once the application receives the DataSet is that you may try converting the DataSet to some type of strongly-typed DataSet (based on a schema) or a class instance on the client at run time, and that is that part that could break. This is what I like about the DTO pattern, everything is strongly typed at design-time, and type-casting errors are caught by the compiler and not the run-time.
DataSets are nice in .NET consumers because the framework will automatically convert the XML from the web service into a DataSet (not just the data, but all of the DataSet functionality) “automagically” for you, whereas it will only convert a class entity into a dumb object (just with properties only). Now, you could modify the proxy to convert the XML from the web service to cast it to a local class instance (or better yet use a derivation of the Mapper or Assembler pattern), but then you would need the definition of the class to be referenced (either in a .cs file or in a referenced assembly) on the client, but with a DataSet this happens for free (you get both the data and the behavior).
One thing I also found out was that you can have a web service that has nullable data type arguments, meaning that you can actually change the contract of a web service without breaking an existing consumer of the service (although they will want to eventually upgrade). In XSD terms, this means that all non-essential arguments can have their nillable attribute set to true (nillable=”true”).
Anyways, I’m glad we talked about it because it really got me thinking bout this stuff.
By the way, all of the articles that I read in regard to this subject were in this month’s edition of The Architecture Journal (Issue 8), which you can get to at http://www.ArchitectureJournal.net. Luckily, I just happened to have a hard copy with me in my backpack while travelling back home, and this month’s theme was Data by Design.