PDC2003::Using XSD, CLR Types and Serialization in Web Services
Indigo: Using XSD, CLR Types and Serialization in Web Services
Doug Purdy dishes out the goods on Indigo.
Serialization Overview
- The transformation of a graph of objects to a stream and back again
- System.Xml.Serialization
- System.Runtime.Serialization
- The transformation of a CLR type into another type system (XSD) and back again
- Framework-wide feature
- Web Serices, Remoting, Yukon, etc.
- End-user feature
What's new for Whidbey
- XmlSerializer
- New imperative modes
- Schema import extensibility
- Serializer pre-generation (sgen.exe today, future implementations will use Reflection.Emit)
- Generics support
- SqlTypes (switch on XSD.exe, support for optional primitives)
- BinaryFormatter
- Version tolerant serialization
- Performance improvements
- Generics support
[OptionallySerializable] (name may change) can be applied to new fields when a class is versioned up to allow the BinaryFormatter to deserialize the new version of your class from an old serialized version.
System.Runtime.Serialization.XmlFormatter
- Serialization Engine
- Extensibility
- Xml Processing
- Representation
Idea is to make anything that is [Serializable]/ISerializable will work with the new XmlFormatter.
"XmlFormatter about XML, not text! Should really call it the InfosetFormatter." All about the abstract data model of the Infoset. You could have a binary representation or any custom representation of the Infoset you like, but the Infoset is what the serialization architecture is now based on.
New model requires you to be explicit about everything. [DataContract] on class, [DataMember] on members (including non-public fields).
XmlFormatter has two modes:
- Tightly coupled - means you care about CLR type you serialized (actually embeds .NET assembly qualified name as attribue of class element)
- Loosely coupled - means you care about the service oriented contract of the data (allows you to serialize into any CLR type that has a compatible contract)
Mode set in constructor of XmlFormmater (SerializationMode enum).
DataMember has VersionAdded property, of type int, that can be used to indicate which version of the schema the property was added. Allows loading of old serialized data into newer versions of a CLR type that maps to that DataContract.
Method marked with [OnDeserialization] with signature "MyClass(StreamingContext)" so you can do custom deserialization. CALLED BEFORE CONSTRUCTOR!?!? Method marked with [OnSerialization], same signature, so you can do custom serialization.
XSD Support
- Every serializable type is interoperable
- Export valid XSD for any CLR construct (including Generics and IDictionary)
- Mapping is not extensible (POR for v1)
- Every XSD schema is supported
- XmlFormatter
- Provides a canonical mapping for CLR <-> XSD mapping
- No mapping extensibility (POR for v1)
- Xml programming models
- Supports all schema constructs
- XmlSerializer, XPathNavigator
Xml Serialization != Xml Programming
New tool, dc.exe (note: dc == data contract), runs over CLR types and generates a valid XSD schema.
Versioning handled in schema using a ref'd group called "unknownData" as opposed to an open content model. Group contains . Allows endless extensibility by repeating that patter in subclasses! WOW. Hell of a solution!
Three levels of support for deserialization on the service end. [ServiceMethods] can use XmlFormatter (you care about CLR types), mark with [XmlMethod] indicates you care more about the [DataContract] scenario than the CLR types, or if you really really want to touch the XML, you can take a Message parameter and Indigo will just hand you the message without any processing and you can read the XML off however you like using it's XmlReader properties.