Is my objective possible using WCF (and is it the right way to do things?)

Question

I'm writing some software that modifies a Windows Server's configuration (things like MS-DNS, IIS, parts of the filesystem). My design has a server process that builds an in-memory object graph of the server configuration state and a client which requests this object graph. The server would then serialize the graph, send it to the client (presumably using WCF), the server then makes changes to this graph and sends it back to the server. The server receives the graph and proceeds to make modifications to the server.

However I've learned that object-graph serialisation in WCF isn't as simple as I first thought. My objects have a hierarchy and many have parametrised-constructors and immutable properties/fields. There are also numerous collections, arrays, and dictionaries.

My understanding of WCF serialisation is that it requires use of either the XmlSerializer or DataContractSerializer, but DCS places restrictions on the design of my object-graph (immutable data seems right-out, it also requires parameter-less constructors). I understand XmlSerializer lets me use my own classes provided they implement ISerializable and have the de-serializer constructor. That is fine by me.

I spoke to a friend of mine about this, and he advocates going for a Data Transport Object-only route, where I'd have to maintain a separate DataContract object-graph for the transport of data and re-implement my server objects on the client.

Another friend of mine said that because my service only has two operations ("GetServerConfiguration" and "PutServerConfiguration") it might be worthwhile just skipping WCF entirely and implementing my own server that uses Sockets.

So my questions are:

• Has anyone faced a similar problem before and if so, are there better approaches? Is it wise to send an entire object graph to the client for processing? Should I instead break it down so that the client requests a part of the object graph as it needs it and sends only bits that have changed (thus reducing concurrency-related risks?)?
• If sending the object-graph down is the right way, is WCF the right tool?
• And if WCF is right, what's the best way to get WCF to serialise my object graph?

Answer 1

Object graphs can be used with DataContract serialization.

Note: Make sure you're preserving object references, so that you don't end up with multiple copies of the same object in the graph when they should all be the same reference, the default behavior does not preserve identity like this.

This can be done by specifying the preserveObjectReferences parameter when constructing a DataContractSerializer or by specifying true for the IsReference property on DataContractAttribute (this last attribute requires .NET 3.5SP1).

However, when sending object graphs over WCF, you have the risk of running afoul of WCF quotas (and there are many) if you don't take care to ensure the graph is kept to a reasonable size.

For the net.tcp transport, for example, important ones to set are maxReceivedMessageSize, maxStringContentLength, and maxArrayLength. Not to mention a hidden quota of 65335 distinct objects allowed in a graph (maxObjectsInGraph), that can only be overridden with difficulty.

You can also use classes that only expose read accessors with the DataContractSerializer, and have no parameterless constructors:

using System;
using System.IO;
using System.Runtime.Serialization;

class DataContractTest
{
    static void Main(string[] args)
    {
      var serializer = new DataContractSerializer(typeof(NoParameterLessConstructor));

      var obj1 = new NoParameterLessConstructor("Name", 1);

      var ms = new MemoryStream();
      serializer.WriteObject(ms, obj1);

      ms.Seek(0, SeekOrigin.Begin);

      var obj2 = (NoParameterLessConstructor)serializer.ReadObject(ms);

      Console.WriteLine("obj2.Name: {0}", obj2.Name);
      Console.WriteLine("obj2.Version: {0}", obj2.Version);
    }

    [DataContract]
    class NoParameterLessConstructor
    {
        public NoParameterLessConstructor(string name, int version)
        {
          Name = name;
          Version = version;
        }

        [DataMember]
        public string Name { get; private set; }
        [DataMember]
        public int Version { get; private set; }
    }
}

This works because DataContractSerializer can instantiate types without calling the constructor.

Answer 2

You got yourself mixed up with the serializers:

• the XmlSerializer requires a parameter-less constructor, since when deserializing, the .NET runtime will instantiate a new object of that type and then set its properties

• the DataContractSerializer has no such requirement

Check out the blog post by Dan Rigsby which explains serializers in all their glory and compares the two.

Now for your design - my main question is: does it make sense to have a single function that return all the settings, the client manipulates those and then another function which receives back all the information?

Couldn't you break those things up into smaller chunks, smaller method calls? E.g. have separate service methods to set each individual item of your configuration? That way, you could

• reduce the amount of data being sent across the wire - the object graph to be serialized and deserialized would be much simpler
• make your configuration service more granular - e.g. if someone needs to set a single little property, that client doesn't need to read the whole big server config, set one single property, and send back the huge big chunk - just call the appropriate method to set that one property