The Other .NET Serializer

A final note on schemas and serialization: The .NET Framework has two serializers, not one. Only one—that found in System.Xml.Serialization—is built into the Web method API and is used by xsd.exe to generate schemas for services and XML messages on demand. The other—the one found in System.Runtime.Serialization—is more generic. It allows you to define exactly how classes are serialized by using the IFormatter interface. The two built-in implementations of this interface specify a binary-based and a SOAP- based result, respectively.

If this second serializer can generate SOAP, why not use it instead of the default? Because for our purposes, the System.Xml serializer prioritizes the use of XSD types and schemas over what .NET types a class can use. If, for example, the request class contains a .NET type that cannot be translated into a <complexType> in the service schema, it will be disallowed. This requirement means the service has a platform-independent interface and clients can hold conversations with it regardless of the platform they are based on. On the other hand, the System.Runtime serializer gives preference to .NET types over XSD and handles classes that cannot be translated into schemas, which means it can handle and distinguish the likes of public and private data, pointers, object graphs, and polymorphism, but services that use it can be used only where both server and client are running .NET.

If you are working in a .NET-only environment (which belies one of the aims of Web services), you might want to consider throwing away the Web method API and using the Handler API with System.Runtime.Serialization. However, you’re heading into the realm of Remoting, which is out of the scope of this book. Look for a copy of the Visual Basic. NET Serialization Handbook by Andy Olson, Matjaz Juric, Adil Rehan, and Eric Lippert (Wrox Press, 2002). It covers everything you could possibly want to know about using serializers, and then some.