On a recent project, I was trying to return an object (with child objects) from an ASMX Web Service and was using the XmlSerializer for serialization. (When doing ASMX Web Services, you really have no choice but to use the XmlSerializer.) The child objects contained a circular reference, which ended up being the bane of my existence because the XmlSerializer can’t handle circular references. The XmlSerializer reports, “Circular reference detected” and gives up. It just can’t serialize it. The amount of code (and changes to the domain model) to work around this limitation was just plain stupid, not to mention the subtle bugs that needed to be fixed when object identity wasn’t respected in other areas of the object graph.
So what does this have to do with Windows Communication Foundation (WCF)? Given how excited I’ve been about WCF, my fellow developers (and the PM) asked if WCF would have avoided the XmlSerializer problems that we had experienced. My curiosity was piqued and I had to find out. As it turns out, WCF can handle circular references and preserve object identity. Or more correctly, the DataContractSerializer can. This would have saved me untold effort if I had been able to use WCF on the project. (Unfortunately release dates didn’t match up. Ironically the project released into production the day before WCF went RTM.) Just a pronouncement that WCF can handle circular references wouldn’t make for a very interesting blog entry. The reality is that out-of-the-box, WCF cannot handle circular references even though the DataContractSerializer can. With a bit of digging, I was able to configure WCF to serialize circular references and properly preserve object identity.
Let’s take a deeper look… Consider a simple object graph with a circular reference. The simplest is a parent-child relationship where the child has a back-reference to the parent. (My situation was more complex, but this example suffices.) Here is a Person class, which has a list of Children, as well as a reference to its parent.
[DataContract(Namespace=“http://jameskovacs.com/Examples/WcfCircularRefs”)]
public class PersonDTO {
[DataMember]
public string Name {
get { return m_name; }
set { m_name = value; }
}
private string m_name;
[DataMember(Name=“Parent”)]
private Person m_parent;
[DataMember(Name = “Children”)]
private List<Person> m_children = new List<Person>();
/* Additional constructors/properties/methods elided. */
/* I’ve also omitted the Order and IsRequired DataMember parameters above. */
/* Full source can be found in the linked zip file at the end. */
}
<Aside>One of the nice things about the DataContractSerializer is that serialized members are opt-in. If you don’t decorate a member with the [DataMember] attribute, it is not serialized. For instance, m_name is not decorated and is therefore ignored by the DataContractSerializer. This is in stark contrast to the XmlSerializer where all public read/write properties are serialized unless they are marked with [XmlIgnore]. Another point to note is that I can serialize both properties and fields, which allows me to have read-only properties, such as m_parent and m_children, while still serializing them at the field level. (N.B. You can still configure WCF to use the XmlSerializer for compatibility, though the preferred serializer is the DataContractSerializer.)</Aside>
Now why can’t WCF handle circular references out-of-the-box. The reason is that there is no industry-accepted, interoperable way of expressing anything but parent-child relationships in XML. You can use the ID/IDREF feature of XML or the key/keyref feature of XML Schema, but a lot of serializers don’t respect these attributes or handle them properly. So if you want to serialize circular references, you need to stray out of the realm of safe interoperability. I found some very intriguing information in Aaron Skonnard’s MSDN article about the DataContractSerializer, Serialization in Windows Communication Foundation. When instantiating the DataContractSerializer, you can tell it to respect object identity (and thus handle circular references) by passing true for preserveObjectReferences constructor parameter.
DataContractSerializer serializer = new DataContractSerializer(typeof(PersonDTO), null, int.MaxValue, false, true /* preserveObjectReferences */, null);
serializer.WriteObject(memStream, person);
The resulting XML looks like this:
<PersonDTO z:Id=“1“ xmlns=“http://jameskovacs.com/Examples/WcfCircularRefs“ xmlns:i=“http://www.w3.org/2001/XMLSchema-instance“ xmlns:z=“http://schemas.microsoft.com/2003/10/Serialization/“>
<Name z:Id=“2“>Sam Spade</Name>
<Parent z:Id=“3“>
<Name z:Id=“4“>Unknown</Name>
<Parent i:nil=“true“/>
<Children z:Id=“5“ z:Size=“0“/>
</Parent>
<Children z:Id=“6“ z:Size=“2“>
<PersonDTO z:Id=“7“>
<Name z:Id=“8“>Jane Spade</Name>
<Parent z:Ref=“1“ i:nil=“true“/>
<Children z:Id=“9“ z:Size=“0“/>
</PersonDTO>
<PersonDTO z:Id=“10“>
<Name z:Id=“11“>Bobby Spoon</Name>
<Parent z:Ref=“1“ i:nil=“true“/>
<Children z:Id=“12“ z:Size=“0“/>
</PersonDTO>
</Children>
</PersonDTO>
You’ll notice that references to other objects are encoded using the z:Id attribute. So the DataContractSerializer can handle circular references, but how do we tell WCF to pass true for the preserveObjectReferences parameter when creating a DataContractSerializer? We can’t, but what we can do is do it ourselves and wedge our code into the WCF pipeline. Is that cool or what? All the details can be found in Ingo Rammer’s MSDN Library Article, From .NET Remoting to the Windows Communication Foundation (WCF). We create a class derived from DataContractSerializerOperationBehaviour, which we’ll call PreserveReferencesOperationBehavior. Here’s the important overload:
public override XmlObjectSerializer CreateSerializer(
Type type, XmlDictionaryString name, XmlDictionaryString ns,
IList<Type> knownTypes) {
return new DataContractSerializer(type, name, ns, knownTypes,
0x7FFF,
false,
true /* preserveObjectReferences */,
null);
}
So we’ve wedged in the preserveObjectReferences = true. We then create an attribute, PreserveReferencesAttribute, which implements IOperationBehavior, to inject the PreserveReferencesOperationBehavior.
public void ApplyDispatchBehavior(OperationDescription description,
DispatchOperation dispatch) {
IOperationBehavior innerBehavior =
new PreserveReferencesOperationBehavior(description);
innerBehavior.ApplyDispatchBehavior(description, dispatch);
}
Finally, we apply this attribute to the OperationContract in our ServiceContract.
[ServiceContract(Namespace=“http://jameskovacs.com/Examples/WcfCircularRefs”)]
public interface IPersonService {
[OperationContract]
[PreserveReferences]
PersonDTO GetDefaultPerson();
}
Our service is now able to serialize circular references, as well as preserve object identity. If we need to transmit objects with circular references back to the service, we could make similar changes to inject PreserveReferencesOperationBehavior into the client-side proxy.
To summarize, WCF is a very extensible framework for distributed communication. We were able to make some small modifications to the WCF pipeline that allowed us to return an object graph with circular references from a service. With the release of WCF, the life of the distributed application developer just got a whole lot easier. Full source code can be found here (16 KB).
N.B. The HTTP transport in WCF relies on http.sys for hosting HTTP ports outside of IIS. Opening up arbitrary HTTP ports cannot be done by non-admins unless they have been granted permission by an administrator. This means an administrator must run httpcfg to grant non-admin users permission to open these ports.
