Living in the Tech Avalanche Generation

It has just recently come to my attention that Udi will soon be running his advanced distributed systems design course in Austin Texas with Jeffrey Palermo’s crew at Headspring. I was fortunate enough to take this very course earlier this year in Australia and I can truly say that my thinking, planning, designing and output have all been enhanced in the most profound ways since doing so, it was one of those great eye opening experiences that can move you to another plane of thinking.

Judging from the course outline on Udi’s site, it would appear that some new material has found it’s way onto the syllabus (I’m jealous), which covers Ultra High scaling possibilities by leveraging REST and after hearing Udi’s podcast on that topic I think I have a feel for what that promises and can only say that I wish I could make the trip to the US to be there.

Whilst I gained enormously from the SOA and DDD content, I also took away some wonderful stuff from the ‘Smart Client’ sections of the training. My team have been using our own home grown MVP framework for some time now and Udi certainly expanded our thinking there, particularly with regard to multi threading issues - greatly useful stuff.

When I had the privilege of sitting through this training I did so with my team and cant say enough about how it invigorated, improved and turbo charged the mind-set and output of all who attended. Udi is a very skilful presenter and a wonderful teacher and significantly has amassed some great wisdom that anyone who is serious about building Service Oriented systems should go out of their way to experience and imbibe. If your in Austin Texas or anywhere in the United States for that matter, I thoroughly recommend you take this course, it is worth far more than the advertised price. Prepare to have some of your beliefs challenged and come with a spirit of learning and you will enjoy the rewards - I know I have and so have many of my colleagues. I know that I personally often find enormous value in listening and learning from people of the quality of Udi and Randy, so imagine spending a week in the company of one such teacher!!!

With PDC around the corner and the buzz around Oslo beginning to form into some louder noise, it occurs to me that we (developers and architects) should be helping shape the discussion and hopefully make an impression.

If I could hand the Oslo team my single most precious wish it would read like this:

“Can I please have a framework that allows me to build applications that support durable messaging using the publish & subscribe pattern and communicate over a bus!”

That’s the main thing that I crave. In the meantime we can use nServiceBus, SimpleServiceBus, Mass Transit and a few others, including rolling our own with WCF but lets not forget that WCF does not give us this out of the box, in fact far from it.

To date we have heard about how integral Windows Communication Foundation and Workflow Foundation are to Oslo and that XAML activation looms large along with ‘the Repository‘ which might be storage for workflow and service discovery. It would seem that the idea of the ‘Repository’ is about assisting with architecture, but I’m not yet clear about how deep the Repository lives in the API and whether I can leverage it to promote or provide durable pub /sub messaging with a bus architectural pattern. Let’s wait and see what emacs.net, the repository and the so-called new process server bring to the table.

Parts 1 and 2 of this post.

I hear people talk about how WCF or ASMX services are inherently loosely coupled by default out of the box, whether they use HTTP or TCP or any old transport available for that matter. “Just use Web Services or WCF and you get loose coupling for free” they say. So the story of temporal coupling using Web Services is well known now as are the many issues with platform coupling and indeed the solution below does not address platform coupling directly as it leans on XML to manage serialization. The coupling that I am interested in addressing here is that created by dependency to the ubiquitous proxy or WSDL contract. Lets examine this a little more closely.

The Reason:

The most common method for a consumer of a service (WCF / ASMX) to maintain and manage the resolution to it’s interface is WSDL. This requires each consumer having to carry around the contract with it, forever in it’s servitude to understand the mysteries that lie at the boundary of it’s faithful service. So without this proxy I don’t know what message to send and where to send it (and yes I know you don’t have to use WSDL and you can proxy off the interface - but that leaves us still coupled to the service interface). Coupling is a measure of dependency and because our consumer depends rather heavily on the service interface or WSDL it is quite squarely coupled to it. Version control with WSDL isn’t trivial to manage and so the coupling story gets worse when we want to change the interface. WCF does provide some methods to relax this versioning problem by ignoring parts of messages from old contract consumers however this is still not adequate. We also hit the coupling ceiling when you consider that all my endpoints are bound to particular message types with respect to the message sent and returned. More recently prescribed guidance has suggested a pattern in sending more coarsely grained messages that are less chatty by utilising complex types or [DataContract] in the world of WCF, but unfortunately I’m still coupled to the schema of these big messages.

How to address this?

One way of addressing this would be to provide blandly consistent service interfaces that never change and utilise the most generic of all messages - System.ServiceModel.Channels.Message, otherwise known as an untyped message in WCF. We can bundle up our rich business messages (as serialized POCO’s) and send them in the body of the untyped message. Once having arrived at our bland endpoint, we could check for an appropriate handler of this message (POCO). What’s required is to de-serialize XML out of the body of our untyped message and back into a POCO and then have the handler manage the message for which it was built to handle. Below is a really rudimentary way of thinking about this interaction.

The Code for sending the message could look something like this:

public void ExampleSend()
{
    //create a channel to the BUS
    EndpointAddress address =
        new EndpointAddress
            (“net.tcp://localhost:9002/Org.ItResults.” +
            “Soa.Hosts.HumanResourceServiceSvc”);

    NetTcpBinding binding =
        new NetTcpBinding
        { SendTimeout = new TimeSpan(0, 10, 0) };
    ChannelFactory<IEndpoint> factory =
        new ChannelFactory<IEndpoint>(binding, address);
    IEndpoint channel = factory.CreateChannel();

    TestMessage tm = new TestMessage(Guid.NewGuid());

    XmlReader reader = Serializator.SerializeMessage(tm);

    //Create the Message to put on the BUS
    //with the serialized data contract embedded
    //into its body and the target method
    //at the endpoint for the BUS channel
    Message msg = Message.CreateMessage(
        binding.MessageVersion,
        “urn:BaseEndpoint-Recieve”, reader);

    //send the message onto the BUS
    channel.Recieve(msg);

    //Close the comms
    factory.Close();
}

On the receiving side the code might look like the following:

public void TestReceive(Message msg)
{
    //NOTE: the types of T handlers could be
    //loaded into the host process

    //a library where an appropriate
    //set of handler might be located
    const string path =
        @”D:\LocalWorking\ITResults\” +
        “Org.ItResults.ServiceOriented.System” +
        @”\Org.ItResults.Soa.Poc.Messages\bin\debug“;

    //get all the types in the path that have
    //generic args. They may be Message Handlers
    //for messages (the generic args)
    List<Type> generics =
        GenericTypeReader
        .InterfaceTypesInPathWithGenericArgs(path);

    List<object> unravelled = new List<object>();

    //for each type found with a generic arg
    //try to deserialize the body of the message
    //in the endpoints method arg into each
    //generic type found
    generics.ForEach(t =>
        unravelled.Add
        (Serializator.DeserializeMessage(msg, t)));

    unravelled.ForEach(delegate(object o)
    {
        //find a handler for the deserialized object
        IMessageHandler handler;
        handler = GenericTypeReader.
            FindHandlerForMessageTypeInPath<IMessageHandler>
            (path, o.GetType());

        handler.GetType().
            GetMethod(”HandleMessage”)
            .Invoke(handler,
            new[] { o });
    });
}

Where a message handler looks something like:

public interface IMessageHandler { }

public interface IResponseMessageHandler<T> :
    IMessageHandler where T : IMessage
{
    /// <summary>
    /// Handles messages that are not required
    /// to return a response.
    /// </summary>
    /// <param name=”message”>
    /// The type of message to handle.
    /// </param>
    Message HandleMessage(T message);
}

public interface IOneWayMessageHandler<T> :
    IMessageHandler where T : IMessage
{
    /// <summary>
    /// Handles messages that are not required
    /// to return a response.
    /// </summary>
    /// <param name=”message”>
    /// The type of message to handle.
    /// </param>
    void HandleMessage(T message);
}

And finally the message and it’s concrete handler might look like this:

public interface IMessage
{
    Guid ID { get; }
}

[XmlRoot(Namespace = "Org.ItResults.com.au")]
public class TestMessage : IMessage
{
    private Guid _id;
    private string _nameofMEssage;

    #region IMessage Members

    [XmlElement(Order = 1)]
    public Guid ID
    {
        get { return _id; }
        set { _id = value; }
    }

    #endregion

    public TestMessage() { }

    public TestMessage(Guid id)
    {
        _id = id;
    }

    [XmlElement(Order = 2)]
    public string NameOfMessage
    {
        get { return “Test Message”; }
        set { _nameofMEssage = value; }
    }
}

public class TestHandler :
    IOneWayMessageHandler<TestMessage>
{
    #region IMessageHandler Members

    public void HandleMessage(TestMessage message)
    {
        Console.WriteLine(“The Test Message name was “ +
            “{0} and it’s ID is {1}”,
            message.NameOfMessage, message.ID);
    }

    #endregion
}

It’s evident from the code that I should be able to drop message handlers (contained in libraries) in a library folder close to my service and give that service the ability to handle messages defined by handlers in those libraries. This is very similar to how nServiceBus deals with declaring how a service defines what messages it handles and I have adapted the idea to fit with WCF, which affords us the following:

1. Decouple from any WSDL proxy and it’s associated versioning issues.
2. Proxies are now managed via a consistent interface less likely to ever require change, as messages pass in the body of an untyped message.
3. Release newer versions of message handlers to services without rebuilding against them or  any newly refreshed proxy definition.
4. Freedom from carrying around WSDL.
5. No coupling to API CRUD styled service endpoints.
   • This is where the style of using Handlers becomes important. Developers are not required to understand an RPC styled API that describes how to affect the state of underlying data, which more often than not is the legacy found in default Web Service Architecture.

It’s also worth noting that the code above does not list how to deal with return messages contained in the untyped message body of an IResponseMessageHandler<T>. This would be managed in a similar fashion to discovering the correct handlers at the service endpoint, by attempting to deserialize messages into available handlers.

Something that is missing in this example is the ability to do publish and subscribe. Some of my colleagues and I are working on a proof of concept framework that extends the concept demonstrated in this post and will include how to handle Pub / Sub (no duplex channels), endpoint discovery via PNRP and durable messaging using queues (Service Broker Queues).