Living in the Tech Avalanche Generation

Having just read one of Howard Dierking’s latest posts regarding how we reason about time when it comes to software, I am reminded about the benefits that one way messaging and publish / subscribe can bring to the table. It stands to reason that we all want our code to execute faster and our applications to respond to their users in a timely fashion; ‘slow’ is not a word users or developers alike want to hear when discussing or describing their systems. Howard’s post is a discussion that came out of his reading a book by Steven Seow titled “Designing and Engineering Time: The Psychology of Time Perception in Software”. I personally haven’t read the book however my interest in doing so has certainly been raised. I am interested here in turning the architectural spotlight onto the strategies for managing time.

Howard includes the following table in his post (the first two columns), demonstrating how perceptions of time in software / human interaction can be managed effectively. As my mind turned to thinking about publish subscribe and one way messaging I decided to add another column to this table clarify my thinking.

In request / response systems, often the focus goes into that described in row 1 column 2 above; that is we tend to narrow in on speeding up our code, substituting for faster implementation technologies or even scaling up our hardware. In the case of stateless Web Services it’s also common to scale out the web servers. With one way messaging and NServiceBus we can increase our throughput and speed (both real and perceived) by scaling out our services and what’s more this can be achieved relatively cheaply with commodity hardware.

It’s also worth noting that the effects of implementing durable queues play’s into the Reliability aspect of the system and when those queues are placed physically adjacent with task based smart client applications that both send and receive messages, then it’s possible to create the perception that work is submitted immediately; potentially it may be repudiated later if there is something wrong with the submission itself. Maintaining a low number of  these repudiated work submissions (command / messages) can increase the tolerance levels and the perceived improvement in speed in getting through the work itself.

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.

Ayende created Rhino.Queues.Storage.Disk a while ago and followed with Rhino.Queues and left it to the community to join them together. I would love to have transactional ‘store and forward‘ available as a design choice that incorporates Silverlight and I’m wondering if these two abandoned children of Ayende’s might provide the basis of an answer? Maybe not. I can see that wrapping Isolated Storage read / write operations with some kind of veneer might be useful however really what’s required here is a solution that enlists in transactions (System.Transaction) thus  making our ’store and forward’ pattern safe and durable. Offline Silverlight with MSMQ? Perhaps, but for now that’s a hack. What about localhost WCF with a database behind it? Sure there are ways and means and somehow this is something I don’t see Microsoft investing in as it’s probably a bit too ‘fringe’ as a requirement, so it’s probably going to be up to the community. Personally I will probably wait till Silverlight is working offline (by design) and reconsider durable storage with Silverlight until then. In the meantime however I am absolutely loving working with XAML based UI in both Silverlight and WPF and going back to Windows Forms is not something likely to ever happen. Oddly, when I open a WinForm application in VS.Net I get the strangest feeling, almost like the one I used to have when opening the VB6 IDE after having developed in .NET for a few years. Must be sign?