Doodling Songhay Web Services
Because XML is the life blood of Web Services, I need to remember that XML passes one ‘real’ type, String. XML uses the String type to simulate every other type in the universe. This “simulation” is implemented by serialization on the .NET plane of reality (SOAP Serialization to be more exact). I’m sure Don Box warned me about this cost of doing business years ago but I wasn’t listening. I am beginning to understand a few consequences of this:
- I created data classes that are designed to live in managed code interacting with SQL server. Members of these classes use types from the
System.Data.SqlTypesnamespace. This is great for handling nulls that SQL server can recognize. This is not so great for people that hate SQL Server. Moreover, these types cannot be serialized as they generate the “System.Globalization.CultureInfocannot be serialized because it does not have a default public constructor” errors. It follows that ‘companion’ data classes had to be created that are designed for serialization. This adds an unexpected layer of complexity but I am not yet willing to give up my .NET intimacy with SQL Server! So, for example, I have a data class calledSonghay.Data.WebSegmentthat works perfectly with SQL server. But I had to create a “companion” class calledSonghay.Data.WebServiceSegmentfor serialization. - Because of this companion class stuff, I had to build a helper class of static members that, say, handle the translation from
Songhay.Data.WebSegmenttoSonghay.Data.WebServiceSegment—and vice versa. When a member of the service-friendly class contains a zero-length string for a String property or when there is a zero assigned for anintproperty, this helper class decides when to assign SQL-friendly null values during translations of web service input destined for SQL Server. - Translation issues like this are probably best handled with custom serialization procedures featuring the
ISerializableinterface. But it appears I am a victim of crazy conspiracy theories promoted by Neil Davidson, his CodeProject.com article, “Nine reasons not to use serialization.” So, to ‘liberate’ myself, I went straight to Jeffrey Richter who, in “Run-time Serialization, Part 3,” introduces me to the concept of a “surrogate type,” which almost appears to serve the same function as my aforementioned translation helper class. But in Jeffrey’s scenario, we are trying to serialize a class that can be serialized when it is properly marked for serialization. In my scenario, I do not have such Microsoft luck. Moreover, the use of serialization in his scenario is required when the developer does not have intimate knowledge of all classes involved. I do. - Because XML is being used to transport data across the wire, strings sent from the database with HTML markup must be ‘handled’ in ‘special’ ways—otherwise all of my angle brackets will escape to a bunch of
<and>entities. The first “special” thing that has to be done is to convert all HTML to XHTML. Secondly, properties of type SQL String have to be translated into type XML Node—this type is recommended by Microsoft when exposing “Rich Text” from Web Services to InfoPath. So now, we can see just how these Web Service classes can freely diverge from the original SQL-friendly data classes because I am not using this “surrogate class” stuff.