Free! - CompactFormatterPlus: Generic Serializer

The advent of .Net framework is the most significant event in the programming world over the last 10 years and I think it is still underestimated. It is the most solid and comprehensive framework ever. However nothing and nobody is perfect. This article is about .Net framework communication and compact framework communication (serialization) in particular.

Communication system model

What is a communication framework? Generally a communication framework is an object delivery system. No more and no less. If this system implements RPC/RMI, another layer is built on the top of that. The object delivery system in turn consists of just two sub layers:

1. Transport layer (physically delivers the stream of bytes to the destination)
2. Converter from the byte stream to the object (a serializer) And nothing else.

The rest can be hidden inside this ideal communication framework.

Note: The late statement is true only for the systems that describe the objects in the same terms (same OS, same .NET framework)

Minimal (Optimal) communication system

Minimal communication system has just one method Send(Object). Does the programmer have to care how the object is converted to the byte stream how it is managed by the threads, how queued, fragmented etc.? No, it is the communication framework job.

WCF

When I first looked at WCF, I had a feeling that I was missing something. It could not be true: automatic generic serialization had gone! Instead it has a semi manual very restrictive serialization.

Judge for youself:

public class Person
{
    public string FirstName;
    public string LastName;
    public int ID;
    ArrayList alist = new ArrayList();
    public ClassB _b;
}

In WCF the decoration of such a primitive object for serialization looks like:

[DataContract(Name = "Customer", Namespace = "http://www.contoso.com")]
class Person : IExtensibleDataObject
{
    [DataMember()]
    public string FirstName;
    [DataMember]
    public string LastName;    
    [DataMember()] public int ID;
    [DataMember()]
    ArrayList alist = new ArrayList();
    [DataMember()] public ClassB _b;
    private ExtensionDataObject extensionData_Value;
    public ExtensionDataObject ExtensionData
    {
        get
        {    
            return extensionData_Value;
        }
        set
        {
            extensionData_Value = value;
        }
     }
}

Does everybody like that? Apparently not. The web is full of blogs suggesting numerous "smart" solutions overcoming the restrictive nature of WCF. The limited WCF serialization is "successfully" worked around by using BinaryFormatter and then putting the byte array as a parameter. Is it the price paid for the interoperability? Microsoft apparently sacrificed versatility for interoperability simply by limiting the functionality. The logical extreme of such approach would be a return to the old good raw socket communication. Hence most of the WCF programs run on Windows, would it be more sensible having the generic serializer as a default and the rest as an option?

What makes the communication framework OS specific

The only thing that makes the system OS specific is the formatter (the serializer). It is the only component in the system that converts the stream to the object. The stream is always the same. As the sculpture is made of stone (any stone) so the object is made of stream. In fact WCF has all these bits and pieces but the way the system is composed is far from perfect.

Interoperability

As I already mentioned that the Serializer makes the framework OS specific. In turn the serializer exists in the framework [say .NET]. What if the OS does not support the frameworks and does not have even the notion of the serializer? In this particular case manual (or semi manual) processing of the byte stream is appropriate but that should be an option, not a default.

If you like everything automatic, why not to use Remoting?

Standard remoting is based on just synchronous communication model. It is unidirectional. The attempts to use call backs for the duplex communication do not work with the client behind proxy or NAT because Remoting opens a second connection for the events. Since the firewall is a standard network component, we may forget about bidirectional communication using remoting.