Living in the Tech Avalanche Generation

I haven’t yet had time to look at Azure in too much depth. I do wonder whether or not messages in WCF 4.0 on Azure and in the ISB are going to continue to encourage the RPC CRUD style remote API’s that we have been seeing over the .ASMX and .WCF years? I look forward to the day when the prescribed guidance for service design does not look like this:

[OperationContract()]
public List<Customer> GetCustomer(string customerID)
{
    //look up the customer from your data store
}

I haven’t worked this way in quite some time now, but surely if we are going to move messaging forward with the latest technologies, we are not going to continue to subscribe to this style of working? This no longer demonstrates the concept of a message to me at all - it’s more like a remote low level API call, which should probably exist in a Repository of some kind. When I must use WCF, I have been employing System.ServiceModel.Channels.Message for quite some time now and as a result my applications don’t suffer the proxy coupling syndrome that many WCF applications do. But will Azure and it’s kit bag of tricks encourage pushing the boundaries of our RPC CRUDiness to the cloud and perhaps even go a long way to encourage it?

The approach I am currently employing with WCF is something inspired directly out of the top drawer of NServiceBus.

public interface IMessageHandler<T> where T : IMessage
{
    void HandleMessage(T message);
}

An IMessage is almost a placeholder.

public interface IMessage
{
    Guid ID { get; }
}

And a typical message might look like:

[XmlRoot(Namespace = "org.myco.com.au.test.messages")]
public class TestMessage : IMessage
{
    private Guid _id;
    private string _nameofMessage;

    public TestMessage() { }

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

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

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

And to handle this kind of message we need a handler:

public class TestHandler : IMessageHandler<TestMessage>
{
    public void HandleMessage(TestMessage message)
    {
        Console.WriteLine(string.Format(“The Test Message name was “ +
            “{0} and it’s ID is {1}”,
            message.NameOfMessage, message.ID));
    }
}

Not a GetCustomer() method in shouting distance. IMessages get placed into the body of System.ServiceModel.Channels.Message and the endpoints check whether they have the appropriate handler available to them. This is how I avoid WSDL and gain the benefit of dropping new handlers in and out if the system needs to change.