Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
The design goals of the SoapFormatter are very different from
the ones of the XmlSerializer.
The latter’s focusses on mapping .NET classes to XML types defined by an XSD
schema. It provides lots of flexibiliy to customize the mappings between the
two to be able to map classes to virtually every schema type. This makes the XmlSerializer a
powerful tool if our application needs to interoperate with other systems
through the exchange of XML documents, but it is not intended as a general
purpose serialization solution. Likewise, we can develop classes the XmlSerializer
can map to an XML document even if the document was not created the XmlSerializer
because it does not rely on type information inside the SOAP message to map
schema types to programmatic types. Instead we have to provide the XmlSerializer
with information about the type mappings before it can do its work. Usually, we
provide the information in the form of metadata attributes attached to classes
specially designed to map to XSD schema types.
Runtime serialization on the other hand focuses on an
accurate description of the serialized object, not the format of the
description. Customization of the format is not an issue because the SoapFormatter
assumes that it performs both, serialization and deserialization of an object.
Other than the XmlSerializer,
the SoapFormatter
embeds all type information required to deserialize objects directly into the
message. This approach limits interoperability considerably because it requires
applications that exchange messages have access to the same assemblies.
Another aspect where the two solutions differ considerably is
performance. Microsoft designed the XmlSerializer for high performance
and moved all the expensive computing operations into the constructor. The
constructor analyzes all types it can process up front and internally creates
compiled classes that can serialize and deserialize these types very fast. As a
consequence, Serialize()
and Deserialize()
are very fast operation because the serializer leverages these classes instead
of analyzing the structure of each object over and over again.
The SoapFormatter
behaves the opposite way; the constructor does not require any information
about types it will process up front. In return it has to analyze the structure
of each object it processes. Compared side-by-side serializing identical
objects, the XmlSerializer
is up to 6x faster than SoapFormatter
for simple classes and this performance gap grows wider with the complexity of
the serialized classes. This makes the XmlSerializer the solution of choice
for high throughput applications, like ASP.NET WebServices and the XmlMessageFormatter
for message queues.
This chapter introduced us to object serialization with the SoapFormatter.
We have seen how we can persist complete object graphs to SOAP messages and
re-hydrate the graphs from the message at a later point. We built a custom
messaging framework around the SoapFormatter to interact with other applications over
the SOAP protocol. The strong type safety of the SoapFormatter’s serialization format
hampers its ability to interoperate with other platforms, but it provides a
type safe solution to communicate between distributed components running on the
.NET platform.
Alternatively, many people persist objects with the SoapFormatter for storage purposes only because the formatter can
serialize the complete internal state of a large number of classes. Persisting
objects with the SoapFormatter
also takes advantage of the strong type safety and provides the benefits of an
XML-based storage format, which makes it easy to verify to serialized data and
works well with text search enabled databases, like SQL Server.
