I'm considering using the System.Xml.Serialization.XmlSerializer class
to implement an in-house data protocol between various applications in
a suite of products. It was already decided for various reasons that
the protocol should use XML to encode the data. I had considered
simply writing custom code to marshal and unmarshal the XML messages
(since they would be fairly simple XML messages and nesting would be
limited), but then I thought: why not just have .NET do all that grunt-
work for me (there is a limited amount of time to get this work
finished)? Thus, I'm currently floating the idea of designing the
protocol around the XmlSerializer class, where I simply define a base
Message class, and create a bunch of Message-derived classes for each
message in the protocol's message repretoire. Then I can code to the
classes instead of directly to the XML DOM, using an XmlSerializer to
serialize/deserialize the messages to and from Message-derived object
instances. Then, the high-level protocol API would define everything
in terms of Message objects.

Thus, a client could say something like the following to authenticate
itself to the server:

    ServerResponse response = client.SendMessage (new
LogonRequest("user","password"));

where ServerReponse and LogonRequest are both derived from Message.

On the server side, it might get a MessageReceived event that contains
a Message object representing the received message as a parameter
(which I'll call msg). The server can then decide what to do based on
the run-time type of the object:

      .
      .
      .

    if (typeof(msg) is LogonRequest) {
        LogonRequest logon = (LogonRequest) msg;
        checkCredentials(logon.UserId, logon.Password);
    }
    if (typeof(msg) is LogoffRequest) {
      .
      .
      .

Obviously, it's a little more complicated because of the limitations
of XmlSerializer (can't serialize ArrayLists and IDictionary-derived
classes) and the slight annoyance of having to tack an XmlInclude
attribute to the base class identifying each of the derived class
types. As for the ArrayList/IDictionary limitations, we are passing
scalar data around for the most part, and I could use just use a
Collection when I need to push around a list of items.

I doubt that I'm the first person to have thought of this: in fact,
this implementation is essentially a subset of remoting, albeit
concentrating more on data that on method invocation.

On that note, I didn't do Remoting because a message-centric protocol
seemed to fit more naturally with the requirements, whereas Remoting
implies coding to the RPC model, which then implies writing a bunch of
methods on an object that would expose a very ugly API (for example,
one of the requirements of the protocol is the ability to query a data
system using a fairely fine-grained XML-based query format, the
details of which don't translate very cleanly into a neat litte
parameter list, although yes, I could just pass the XML query part as
a single string parameter). Point is, I'm thinking I can save myself
some grief and let the XmlSerializer do most of the dirty work across
the wire, and I can concentrate on protocol logic.

Does this design make sense? I google'd various combination of
"XmlSerializer" and "sockets" and didn't find much. A few other people
seem to have tried a similar approach to creating a message-based
protocol, getting XML marshalling for free via XmlSerializer, but it
doesn't seem to be a "popular" design as far as what google thinks.
This makes me wonder if it is fatally flawed....I mean, it sounds
great on paper (to me anyway), but I'm wondering if there aren't some
weird edge cases that I would have to code for.

--
Mike S