Now: A Concept Whose Time Has Come And Gone?

I recently came across the Flow Programming Language, which aims to “solve the multicore dilemma through ubiquitous, guaranteed-safe implicit parallelization”. However, rather than going down the route of Functional Programming, it aims to do so for imperative languages. This lead to an interesting claim:

The specific minimal way that an imperative programming language must be restricted to make programs written in that language precisely implicitly parallelizable is to make it impossible to read the current value of a variable.

In other words, “there is no such thing as the concept of ‘now’ in the program”. This lead to the following alternative options:

  1. Reading the only value that a variable will ever take i.e. immutability.
  2. Reading the value of a variable at a specific (local) timestamp.
  3. Reading the set of all values that a variable will ever take on i.e. pushing values into a collection.

What I find interesting about this is that the first two options are making time an explicit concept within the language: either a variable has a single value for all time, or else you must ask for the value at a specific point in time.

However, the Flow language is a long way from even an Alpha release, so I filed it under “intriguing but not going to impact me for a while”. But my interest was piqued, so I went searching for more information about models of time within current programming languages, and only really came up with one option: Clojure’s Epochal Time Model.

The linked video is essential viewing for a proper understanding, but for the purposes of this post there is a nice summary here. The key concepts are Identity (e.g. me), State (e.g. hungry), and functions that cause the state of the identity to transition to a new value (e.g. Eat muffin, resulting in me being satiated.). State is immutable, and Identity is a concept that ties together a sequence of these states.

Clojure has a number of ways of modelling identity: vars, refs, atoms and agents, depending on the exact semantics required for access to the underlying state (aside: it would be nice to see the equivalents in F#). However, what they all share is that there is just one underlying state i.e. they are still operating in the “now”.

Then I listened to the Relevance podcast episode with Michael Nygard. In it the host (Craig Andera) mentioned that “there is no such thing as ‘now’”. This was said in the context of a discussion around Datomic (a time-aware database of immutable facts) and distributed systems, where you can never be sure you have the most up-to-date information. Datomic has a very explicit time model, where each fact has an associated transaction, which in turn has both a relative and an absolute time value. This seems to be the piece that is missing from Clojure’s time model.

And finally I was struck by a real world example from my current project. Our application requests data from a 3rd party, but the default API assumes that the request is for the latest data. So the response depends on the time at which the request was sent. The horror, the horror.

However it would be unfair to pick on that particular API, because this style of programming is the default approach today. Programming in the “now” implies an implicit dependency – time – and even though we agree that implicit dependencies are bad, we are blind to this one. Not only have we all written APIs like the above, haven’t we all also written code like the following?

prev = curr;
curr = CalcNewValue(prev);

Or how about?

var timeSeries = new List<Foo>(); // index represents time order
for (var t = 0; t < 10; t++)
{
    timeSeries.Add(CalcFoo(t));
}

In both cases we are kludging together a representation of time using language features – variable names in the first example; list indexing in the second – because time is not a first class concept in the language.

We have known for a while that manual memory management is painful and error-prone, and many languages now provide garbage collection to relieve us of that burden. However, when it comes to time, we are still left to manage that for ourselves.

I think the sane default should be that all (immutable) values should be associated with a point in time, which might be local or global, absolute or relative, depending on nature of the problem. And our languages and/or libraries should provide support for this, rather than requiring us to hand-roll our own implementations every time.

Waiting for language-level support for this does not help in the short term, so we need libraries to help us out. In future posts I’ll explore some possible implementations using F#, as decent support for immutability is an essential prerequisite.

Shrink, Script, Shape

In a recent blog post about null reference exceptions, Don Syme bemoaned the status quo:

Unfortunately a sort of stasis, or lack-of-will seems to be gripping the industry at the moment. People stick with their existing languages, though occasionally make noises about needing non-null types (thus making C# and Java even more complex, when we should be ridding ourselves of this curse altogether).

So why do people stick with their existing languages, and what can we do to increase F# adoption? I think it is useful to start by considering what someone faces when they decide to investigate F#. They will find very useful material online, covering a range of topics, and after a little browsing will find themselves faced with a barrage of concepts:

  • Non-nullability
  • Immutability
  • Expression-oriented programming
  • First class functions
  • Higher order functions
  • Pattern matching
  • Discriminated unions
  • Partial function application
  • Currying
  • Recursion instead of loops
  • Monads

Switch Book Cover
And how do people react when faced with so much information? Switch, a book by Chip and Dan Heath, provides some answers and, as the subtitle suggests, provides ways to tackle this kind of problem. In it the authors make the point that effecting change requires not just rational arguments, but also emotional arguments and adapting the environment of the target audience.

As engineers, we tend to focus on the rational, and therefore often ignore factors that could have a larger impact. Indeed, there are a wealth of good online articles making rational arguments for wider F# adoption, and yet uptake is not as large as we’d like.

Maybe it is time to take a deep breath and dive into the uncomfortable world of emotional arguments and environmental manipulation?

I think there are three concepts from the book that are applicable here:

Shrink the Change

Coaches are masters of shrinking the change. By pushing…to attain a sequence of “small, visible goals”, they build momentum…A small win reduces importance (“this is no big deal”), reduces demands (“that’s all that needs to be done”), and raises perceived skill levels (“I can do at least that”). All three of these factors will tend to make change easier and more self-sustaining.

We need to reduce that mountain of information into a manageable molehill. I think that involves under-playing the host of benefits and instead focussing on just one or two. We can emphasise that first class and higher order functions are at least somewhat familiar via LINQ. And we can tackle just one of the new concepts at a time – perhaps non-nullability because everyone understands the problem and therefore will understand the benefit of eliminating null references.

I’d also suggest further shrinking the change by encouraging people to start with a single component in F# rather than a full system. However, the interop with other languages weakens the non-nullability argument, so we need to be careful.

Script the Critical Moves

Change brings new choices that create uncertainty…that yield decision paralysis…Change begins at the level of individual decisions and behaviours, but that’s a hard place to start because that’s where the friction is. Inertia and decision paralysis will conspire to keep people doing things the old way. To spark movement you need to provide crystal-clear guidance. That’s why scripting is important…

The barrage of concepts listed earlier is what leads to decision fatigue. To prevent this we need to carefully script the exact steps people should take. So, sticking with non-nullability, we need to show exactly how the single component could be developed to avoid null references. And we need to be specific about how to tackle interop with “dirty” code e.g. how to use the interop features in FSharpx to convert nulls to Options.

Shape the Path

…Alternatively, you can simply make the journey easier. Create a steep downhill slope and give them a push. Remove some friction from the trail.

Anything that gets in the way of making a change, even if it only constitutes a small obstacle, will reduce the likelihood of the change being adopted. Therefore anything we can do to remove the obstacles will be beneficial.

A recent InfoQ survey asked the question “why are you not using functional languages?”, and the top two answers are revealing:

  1. Couldn’t find developers (770 votes)
  2. Insufficient tool support (618 votes)

The first reason is a chicken-and-egg situation, so we need to find a way to increase adoption within the developer community – that is the topic of this post. The second reason is more interesting. It specifically mentions automated refactoring support, and that is certainly an area where F# is weak. I’ve heard the (rational) argument that refactoring tools aren’t as important for functional languages, but we need to forget about whether the argument is valid: if there is a perceived tooling problem, then adoption will be adversely affected. This is a case of us failing to “Shape the Path”.

A Crazy Idea

Refactoring tools are extremely hard to write, and require a level of dedicated resource that mean it is unlikely to happen as a spare-time effort, so should we instead start a community-lead fund-raising campaign (Kickstarter?) to pay for the initial development? I can imagine that certain companies would be glad to publicly sponsor such an effort, and that individuals would chip in too.

Summary

In order to increase adoption of F#, we need to make the change seem as small, undaunting and easy as possible. The first two can be tackled through tutorials that focus of explaining, in detail, how to achieve a specific benefit. I think the benefit to address is non-nullability, but I’d be very interested to hear other ideas.

A big hurdle in making adoption as easy as possible is lack of tool support. Here I think the scale of the task means we need a more radical approach. Is there sufficient interest, and is the community large enough, to fund such a project?

F# Testing DSL Part 3

I ended the last post by proposing a syntax for asserting against floating point results:

let ``Comparing floating point numbers``() =
    Given 1.0 |>
    When ``dividing by 3`` |>
    Then it should be (0.333333333 +/- 0.00000001)

How can we implement this? Let’s start with the trivial part: the be function. It is just another “filler” word like it and should:

 let be f = f

That leaves (0.333333333 +/- 0.00000001) to perform the same role as the ``return`` function implemented previously i.e. it is a custom overloaded operator that should have a signature 'a -> TestContext<'a> -> unit. If we restrict 'a to be a float, we could implement it as:

let (+/-) (expected: float) (tolerance: float) (context: TestContext) =
     Assert.AreEqual(expected, context.ToState, tolerance)

Then, assuming we have also defined let ``dividing by 3`` = n / 3.0, the above test passes. However, we will want to comparing other types of floating point numbers, not just floats. Unfortunately we can’t just do this:

let (+/-) expected tolerance (context: TestContext<_>) =
     Assert.AreEqual(expected, context.ToState, tolerance)

The compiler can’t determine which overload of AreEqual to use. Instead, we need to somehow write generic code that is constrained to work with any numeric type. This answer on StackOverflow shows how to use inline functions, explicit member constraints and statically resolved type parameters to (messily) achieve the required result:

let inline (+/-) (expected) (tolerance) (context: TestContext<_>) =
    let zero = LanguagePrimitives.GenericZero
    let actual = context.ToState
    let absDiff = if expected > actual then
      		      expected - actual
		  else
		      actual - expected

    let absTolerance = if tolerance < zero then
		           -tolerance
		       else
			   tolerance

    if absDiff < absTolerance then
        ()
    else
        let msg = sprintf "Expected: %s +/- %s\nBut was:  %s" <| expected.ToString() <| tolerance.ToString() <| actual.ToString()
	raise <| AssertionException(msg)

We basically have to implement Assert.AreEqual(expected, actual, tolerance) ourselves, and I’ve chosen to throw the same exception that NUnit would throw so that it can be a drop-in replacement.

If we then implement ``dividing by 3`` in a similar generic manner:

let inline ``dividing by 3`` (n:^a) : ^a =
    let three:^a = (Seq.init 3 (fun _ -> LanguagePrimitives.GenericOne)) |> Seq.sum
    n / three

Then both of the tests below pass:

[<Test>]
let ``Comparing floats``() =
    Given 1.0 |>
    When ``dividing by 3`` |>
    Then it should be (0.333333333 +/- 0.00000001)

[<Test>]
let ``Comparing decimals``() =
    Given 1.0m |>
    When ``dividing by 3`` |>
    Then it should be (0.333333333m +/- 0.00000001m)

This brings me to the end of this series of posts. Hopefully I’ve illustrated one of the ways in which F# makes it (relatively) easy to write an internal DSL, as well as whetting your appetite for exploring the possibilities of low-ceremony BDD in F#.

F# Testing DSL Part 2

Last time we got to the stage where we could write the following test:

let ``Basic example`` () =
    Given (123 |> ``is pushed onto a stack``) |>
    When ``stack is popped`` |>
    Then it should ``return`` 123

I also suggested looking at NaturalSpec (which inspired these posts) to see how it tackles the same problem. If we strip out all extra features that NaturalSpec provides, we are left with:

let Given f = f

let When f = f

let It f = f // NaturalSpec equivalent of Then

let should f x y =
    f x y |> check // Implementation of check not shown

So the real work is all deferred to the should and check functions. The relevance to this post is that an exception that occurs during the action executed by the When is not caught, so we have to use the ExpectedException attribute to assert that an exception has occurred.

I’d like to avoid using the ExpectedException attribute, and instead be able to do something like:

let ``Basic exception Handling`` () =
    Given (Stack<int>()) |>
    When ``stack is popped`` |>
    Then it should throw<InvalidOperationException>

So how do we modify our implementation to support this? The first problem is that we need to catch the exception in the When clause and make it available to the Then clause. In other words, we now need to be able to pass either the system state or an exception to the Then clause. We can model this as:

type TestContext<'a> =
    | State of 'a
    | Exception of exn
	
    member this.ToState =
        match this with
        | State(s) -> s
        | Exception(e) -> failwith "Context does not represent a state."

    member this.ToException = 
        match this with
        | State(s) -> failwith "Context does not represent an exception."
        | Exception(e) -> e

I’ve added ToState and ToException helper properties to avoid repetitive pattern matching in the calling code.

We also need to modify the When function:

let When action precondition = 
    try
        State(action precondition)
    with
    | e -> Exception(e)

The TestContext will be passed to the Then clause, which means that ``return`` will need to be modified to accept a TestContext<'a> instead of an 'a:

let ``return`` (expected: 'a) (context: TestContext<'a>) =
    Assert.AreEqual(expected, context.ToState)

…and yes, the code still compiles and we still have the expected passing and failing tests.

Now we can move on to the throw<'e> function. We can cheat here and look back at the earlier ``result is 123``, which had a signature of 'a -> unit. By analogy throw<'e> should have a signature of TestContext<'a> -> unit:

let throw<'e> (context: TestContext<'a>) =
    Assert.IsInstanceOf<'e>(context.ToException)

However, this fails due to a compiler warning (you do treat warnings as errors, don’t you?):

FS0064: This construct causes code to be less generic than indicated by the type annotations. The type variable ‘a has been constrained to be type ‘int’.

This is because the state we are passing around is an int. In order to make throws properly generic we would need:

let throw<'e, 'a> (context: TestContext<'a>) =
    Assert.IsInstanceOf<'e>(context.ToException)

But that leads to an ugly calling syntax where we have to specify the state type:

let ``Basic exception handling`` () =
    Given (Stack<int>()) |>
    When ``stack is popped`` |>
    Then it should throw<InvalidOperationException, int>

The problem is that throw is dealing with two generic parameters when we only want it to deal with one. Can we extract the exception in one function, then pass it to the next to assert against? Something like this:

let ``Basic exception handling`` () =
    Given (Stack<int>()) |>
    When ``stack is popped`` |>
    Then it should throw any<InvalidOperationException>

The new throw could extract the exception from the test context, then any will be a simplified version of the original throw that gets passed the exception rather than the TextContext.

let throw checkExnType (context: TestContext<'a>) = 
    checkExnType context.ToException

let any<'e> ex =
    Assert.IsInstanceOf<'e>(ex)

More passing tests! However, we want to be sure that the correct InvalidOperationException is being thrown. Something like:

let ``Advanced exception example`` () =
    Given (Stack<int>()) |>
    When ``stack is popped`` |>
    Then it should throw (specific<InvalidOperationException> (fun e -> e.Message = "Stack empty."))

We need to add brackets around the specific function to ensure it gets evaluated first. Then, as long as it returns an exn -> unit (i.e. the same signature as any<'e>) everything should work out:

let specific<'e> (check: exn -> bool) (ex: exn) =
    Assert.IsInstanceOf<'e>(ex)
    Assert.IsTrue(check ex, "Exception condition not met:\n\n" + ex.ToString())

With this, the ``Advanced exception example`` passes. So we now have a DSL that allows us to assert that expected results and expected exceptions have occurred. However, what if the state that we are trying to verify is a floating point number? In that case Then it should return 1.234 is not a good idea.

Wouldn’t it be nice to be able to do the following?

let ``Comparing floating point numbers``() =
        Given 1.0m |>
        When ``dividing by 3`` |>
        Then it should be (0.333333333m +/- 0.00000001m)

More next time…

F# Testing DSL

I’m a fan of the Gherkin DSL for specifying software behaviour. Having a structured but human readable language helps the discussion with business users. However, when it comes to converting the resulting specifications in executable tests, I find the tooling cumbersome. I suspect I would find it more useful if the business users were writing large numbers of tests, but this has never happened on any projects that I’ve been involved with.

I prefer a lighter weight approach where the developers write the tests in plain old code, but hopefully in a format that makes it easy to map them back to the specifications. The problem with this is that most convention-based approaches or BDD frameworks that I’ve encountered leave a big gap between the code syntax and the specification syntax. Then I discovered NaturalSpec, which leverages F#’s DSL-friendly syntax to produce very readable tests, and I was totally blown away by it. Using it you can write tests like the following (taken from solution to the Tennis Kata provided in the NaturalSpec source code):

[<Scenario>]     
let ``When Player1 scores once the score should be Fifteen to Love`` () =   
    Given NewGame
      |> When point_goes_to Player1
      |> It should equal (Fifteen <=> Love)
      |> Verify

It uses the forward pipe operator to thread the test state through the When and Then functions, producing very readable code with no external state. I wanted to understand how it worked under the hood, but my F# skills weren’t up to the task. So, to help myself learn I decided to write my own variant at the same time. I’m going to describe that variant, but if you want a production-grade solution, please use NaturalSpec!

The general form of a Given/When/Then spec is:

Given precondition
When action
Then expectation

We can convert this into (theoretically) valid F# code by piping each clause into the next:

Given precondition |> 
When action |> 
Then expectation

So how do we define the Given/When/Then functions such that they compile? First let’s deal with the Given function:

let Given precondition = 
    precondition

This is just some syntactic sugar to make the test more readable; it does nothing but return the precondition. We’ll need to start looking at function signatures soon, so let’s start with this function, which has a signature of 'a -> 'a. We can use it like:

Given (Stack<int>()) 

or (assuming ``a binary tree of depth 3`` is already defined)

Given ``a binary tree of depth 3``

Notice how F#’s double-backtick notation makes the code more readable. The When function needs to execute an action on the precondition (which is piped in from the result of the Given clause) and pass on the result to the Then:

let When action precondition = 
    action precondition

This has the signature ('a -> 'b) -> 'a -> 'b, and we can then use it in our test like so:

let ``is pushed onto a stack`` n = 
    let s = Stack<int>() 
    s.Push n 
    s 

let ``stack is popped`` (stack: Stack<int>) = 
    let v = stack.Pop() 
    v 

let ``Basic example`` () = 
    Given (123 |> ``is pushed onto a stack``) |> 
    When ``stack is popped`` 

Notice that ``stack is popped`` takes a Stack<int> as its input but returns just the popped value, not the entire stack i.e. we do not need to pass the same kind of state between the clauses.

Now we need to assert against the result. The idea here is to use NUnit’s asserts rather than writing custom ones, but to wrap them in meaningful syntax. So Then needs to test the result (which is piped in from the result of the When clause) against an expectation. Naively, we could assume it takes the form:

let Then expectation result = 
    expectation result 

If we look at the signature, it is ('a -> 'b) -> 'a -> 'b. This looks about right, though we don’t expect Then to return anything meaningful, so would expect 'b to be unit. However, let’s try it “as is” before messing with the signature. As a first attempt how about trying to make the following syntax compile?

let `Basic example` () = 
    Given (123 |> `is pushed onto a stack`) |> 
    When ``stack is popped`` |> 
    Then ``result is 123``

In other words we are trying to make Then ``result is 123`` actual_value have the signature ('a -> 'b) -> 'a -> 'b. But because the whole clause is just going to assert, it will return unit, and then the signature we are gunning for is ('a -> unit) -> 'a -> unit. So, partially applying ``result is 123`` to Then needs to yield a function with signature'a -> unit. So ``result is 123`` must have a signature of'a -> 'unit:

let ``result is 123`` (actual: 'a) = 
    Assert.AreEqual(123, actual)

If we try to compile and run this, we get a passing test…and if we change the Given to push 999 onto the stack, we get the expected failing test. Progress!

However we don’t want to hardcode 123 into the expectation; we would prefer to write:

let ``Basic example`` () = 
    Given (123 |> ``is pushed onto a stack``) |> 
    When ``stack is popped`` |> 
    Then ``result is`` 123 

So now we want to make Then ``result is`` expected_value actual_value have the signature ('a -> unit) -> 'a -> unit. Again, partially applying ``result is`` to Then needs to yield a function with signature 'c -> 'c -> unit (I’ve changed the generic letter for clarity) i.e. 'a must be ('c -> 'c). So, ``result is`` must have the signature ('c -> 'c -> unit):

let ``result is`` (expected: 'a) (actual: 'a) = 
    Assert.AreEqual(expected, actual)

If we try to compile and run this, we still get a passing test…and if we change the expected value to 999, we still get the expected failing test. More progress!

Can we make the syntax more readable and in line with BDD terminology?

let ``Basic example`` () = 
    Given (123 |> ``is pushed onto a stack``) |> 
    When ``stack is popped`` |> 
    Then it should ``return`` 123 

Comparing this to the previous example, we can imagine that ``return`` takes the place of ``result is``, with it and should just being syntactic “filler words”. i.e. we are looking for signature for it and should such that Then return 123 and Then it should return 123 have the same signature. What function does nothing? How about:

let it f = f 

and

let should f = f 

They both have signature 'a -> 'a. So in the above example, with ``return`` having signature ('c -> 'c -> unit), both should return and it should return also have signature ('c -> 'c -> unit). This all looks promising…and yes, the code still compiles and we still have the expected passing and failing tests.

So at this stage the entire implementation (and two test cases) looks like:

namespace ItWorksOnMyMachine

open System.Collections.Generic

open NUnit.Framework

module FSpec =
    let Given precondition =
        precondition

    let When action precondition = 
        action precondition

    let Then expectation actual =
        expectation actual

    let it f = f

    let should f = f

    let ``return`` (expected: 'a) (actual: 'a) =
        Assert.AreEqual(expected, actual)

module FSpecExamples =
    open FSpec

    let ``is pushed onto a stack`` n =
        let s = Stack()
        s.Push n
        s
        
    let ``stack is popped`` (stack: Stack) = 
        let v = stack.Pop()
        v

    [<Test>]
    let ``Basic passing example`` () =
        Given (123 |> ``is pushed onto a stack``) |>
        When ``stack is popped`` |>
        Then it should ``return`` 123
       
    [<Test>]
    [<ExpectedException(typeof<AssertionException>)>]
    let ``Basic failing example`` () =
        Given (999 |> ``is pushed onto a stack``) |>
        When ``stack is popped`` |>
        Then it should ``return`` 123

I would recommend comparing the above implementation (full solution here) to the NaturalSpec code. Even when you strip away all the nice extra features that NaturalSpec provides, you are still left with a very different implementation: one that would never have occurred to me.

Next time I’ll look at an implication of those differences, and try extending my implementation to allow asserting that expected exceptions are thrown, rather than relying on the ExpectedException attribute.

Me, A Name I Call Myself

In F#, unlike other CLR languages, you can define the self-identifier that a class uses, rather than being restricted to a language-specific one. If you come from a C# background (as I do), you might be tempted to use “this”, as it is familiar.

namespace ItWorksOnMyMachine

type MyFirstFSharpClass(m: int) =
    let l = seq {for i in 1..100 do yield i}
            |> Seq.toList

    let n = 2 * m     

    member this.Multiples () =          
        let isMultiple =             
            fun i -> i % n = 0

        l |> Seq.filter isMultiple

This is perfectly reasonable, but the above code demonstrates a possibly confusing situation when debugging this code. If a breakpoint is placed at line 13, we can inspect the value of n using this.n:

watch1

However, if the breakpoint is placed at line 11 then things get confusing:

watch2

The type of “this” has changed, because it now refers to the compiler-generated class used to hold the let binding! In order to access the same instance we now need to use “this.this.n”:

watch3

If I wanted “this” to point to different things at different times, I’d write code in JavaScript. However, being of reasonably sane disposition, I prefer a little more consistency. My attempted solution was to use “me” as the F# self-identifier, but this just introduces a fresh hell:

watch4

How can “me” not exist when the breakpoint is in the method body?

watch5

Oh, but it does exist when the breakpoint is in the compiler-generated class! Time for me to go and lie down…

Message Bus In Action

It has been a long time since my last post, but I do have a partial excuse: I started a new job at pebble {code} the day after posting it. My two previous posts on the message bus have been cross posted to the company blog: head over there for an eclectic mix of articles. If you like what you see, why not consider applying for a job?

In this post I want to summarise the advantages of the message bus approach, and also look at a potential limitation. The benefits as I see them are:

  1. (Very) loose coupling between services.
  2. Encourages narrow interfaces (what is narrower than an interface with one method e.g. IRequestHandler?)
  3. Provides not only Event Aggregator functionality, but also asynchronous Request-Response.
  4. The ability to enforce sequential message processing can make it simpler to develop stateful services.

If all the request processing is sequential then we have something akin to the Actor Model but without the concept of identity: a request can only have a single registered handler, so it is meaningless to talk about the handler’s identity. In general I think this is a good thing – having to know about the identity increases the coupling between the services.

However, there are situations where we really do need to distinguish message destinations based on the identity of the receiver. Is this a situation that we can’t handle? Or are there workarounds using the message bus?

The example I’ve chosen to use is the simplest two person game I could think of – Noughts and Crosses. The design consists of 4 services: a Game service (responsible for controlling the game and ensuring legal play), two instances of a Player service (P1 and P2) and a UI service. In all of the sequence diagrams that follow the messages are assumed to go via the bus (not shown), unless explicitly stated otherwise. Async/sync requests are shown with a solid line and an open/closed arrowhead; events are shown with a dashed line and an open arrowhead. First the players have to register to play the game:

Players send a RegistrationRequest to the Game (N.B. as long as the Game has been registered as a handler for RegistrationRequest using MessageProcessingMode.Sequential, we don’t need to worry about race conditions during registration). The Game returns a RegistrationResult indicating whether registration has been successful. Once two players have registered the game can begin. The idea is that the Game should be able to send a PlayerMoveRequest and receive a PlayerMoveResponse containing the player’s chosen move. However, both players are capable of handling a PlayerMoveRequest, and they can’t both register as handlers for this request. The options seem to be:

Unique Request Types

Use different request types for Player1 and Player2:

This is ugly because of the large amounts of duplication (P1MoveRequest = P2MoveRequest; Player service needs to implement IRequestHandler<P1MoveRequest, P1MoveResponse> and IRequestHandler<P2MoveRequest, P2MoveResponse>).

Two Message Bus Instances

Introduce two message bus instances, with communication between the game and each player happening on separate buses: Whilst this initially felt more natural – we are simply saying that the game has a dedicated communication channel with each player – it gets complicated once we consider the UI. Does each player use its dedicated bus to communicate with the UI? Then how does the Game communicate with the UI? Via a third bus? Or does it arbitrarily choose one of the two existing buses?

Player Message Router

Introduce a PlayerMessageRouter that receives the PlayerMoveRequest and routes it (using information present within the request) to the appropriate Player. This routing does not go via the bus – it will probably just be a direct method call: This initially felt like an unnatural abstraction – there is no concept of a player router in the Noughts and Crosses domain – introduced to get around a limitation in the message bus. However, on closer inspection the Game/Player/UI don’t need to know anything about the router, which can be implemented in a generic manner and just becomes another infrastructure component that we can choose to use if appropriate (like the load balancers):

namespace ItWorksOnMyMachine.MicroSoa
{
    using System;
    using System.Diagnostics.Contracts;
    using System.Linq;
    using System.Threading.Tasks;

    public class RequestRouter<TRequest, TResponse, THandler> : IRequestHandler<TRequest, TResponse> where THandler : IRequestHandler<TRequest, TResponse>
    {
        private readonly IMessageDispatcher messageDispatcher;

        private readonly Func<TRequest, THandler, bool> isCorrectHandlerForRequest;

        private readonly IMessageQueue[] requestQueues;

        public RequestRouter(IMessageDispatcher messageDispatcher, Func<TRequest, THandler, bool> isCorrectHandlerForRequest, params Tuple<THandler, MessageProcessingMode>[] handlerProcessingModePairs)
        {
            Contract.Requires<ArgumentNullException>(isCorrectHandlerForRequest != null);
            Contract.Requires<ArgumentOutOfRangeException>(handlerProcessingModePairs.Count() >= 2);

            this.messageDispatcher = messageDispatcher;
            this.isCorrectHandlerForRequest = isCorrectHandlerForRequest;
            this.requestQueues = handlerProcessingModePairs.Select(CreateQueue).ToArray();
        }

        private static IMessageQueue CreateQueue(Tuple<THandler, MessageProcessingMode> handlerProcessingModePair)
        {
            var handler = handlerProcessingModePair.Item1;
            var messageProcessingMode = handlerProcessingModePair.Item2;

            return MessageBusFactory.MessageQueueCache.GetOrAdd(handler, messageProcessingMode);
        }

        public Task<TResponse> HandleRequest(TRequest request)
        {
            var targetQueue = requestQueues.Single(queue => isCorrectHandlerForRequest(request, (THandler)queue.Service));

            return targetQueue.Send<TRequest, TResponse>(request, messageDispatcher);
        }
    }
}

The RequestRouter is also a good example of the first three of the SOLID design principles:

  • Single Responsibility: it simply forwards requests to the correct recipient. It does not even understand how the correct recipient is chosen, it simply knows that the provided delegate will do the work for it.
  • Open/Closed: we’ve introduced routed messages into our system by adding a new component rather than modifying existing ones.
  • Liskov Substitution: it implements IRequestHandler<TRequest, TResponse> and hence is a drop-in replacement for the original request handler.

Bringing It All Together

I’ve implemented a solution using the “Player Message Router” approach. I’ve assumed that both players are humans, and they forward the move requests to a UI, of which there is both a console version and a WinForms version. The Game, HumanPlayer, ConsoleUI and WinFormUI classes are quick and dirty implementations (though take a peek at HumanPlayer.HandleRequest and WinFormUI.GetMoveFromButtonClick for some Async/Await and Rx tastiness). The real interest is in how they are wired up. The code below is for wiring up the ConsoleUI version:

class Program
{
    static void Main(string[] args)
    {
        var bus = MessageBusFactory.Create();

        var game = new Game(bus);

        bus.RegisterRequestHandler(game, MessageProcessingMode.Sequential);
        bus.RegisterRequestHandler(game, MessageProcessingMode.Sequential);

        var player1 = new HumanPlayer("Player 1", bus);
        var player2 = new HumanPlayer("Player 2", bus);

        var playerRouter = new RequestRouter(
                bus,
                (request, player) => player.Name == request.Player,
                Tuple.Create(player1, MessageProcessingMode.Sequential),
                Tuple.Create(player2, MessageProcessingMode.Sequential));

        bus.RegisterRequestHandler(playerRouter, MessageProcessingMode.Sequential);

        var userInterface = new ConsoleUI(bus);
        bus.RegisterRequestHandler(userInterface, MessageProcessingMode.Sequential);
        bus.RegisterEventHandler(userInterface, MessageProcessingMode.Sequential);

        player1.RegisterForGame();
        player2.RegisterForGame();

        userInterface.Run();
    }
}

What I like about this is that all of the messages that flow through the system are clearly laid out in the application root. This provides a nice high level overview of the system. Also notice that the Game and the Players don’t know anything about the RequestRouter that has been introduced to route messages to the correct player. Now, if we compare this to the setup for the WinFormUI:

static class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);

        var bus = MessageBusFactory.Create();

        var game = new Game(bus);

        bus.RegisterRequestHandler(game, MessageProcessingMode.Sequential);
        bus.RegisterRequestHandler(game, MessageProcessingMode.Sequential);

        var player1 = new HumanPlayer("Player 1", bus);
        var player2 = new HumanPlayer("Player 2", bus);

        var playerRouter = new RequestRouter(
                bus,
                (request, player) => player.Name == request.Player,
                Tuple.Create(player1, MessageProcessingMode.Sequential),
                Tuple.Create(player2, MessageProcessingMode.Sequential));

        bus.RegisterRequestHandler(playerRouter, MessageProcessingMode.Sequential);

        var userInterface = new WinFormUI(bus);
        bus.RegisterRequestHandler(userInterface, MessageProcessingMode.Sequential);
        bus.RegisterEventHandler(userInterface, MessageProcessingMode.Sequential);

        player1.RegisterForGame();
        player2.RegisterForGame();

        Application.Run(userInterface);
    }
}

The only differences from the previous ConsoleUI example are the call to create the UI instance and the WinForms-specific calls to the Application class. Everything else is identical.

Summary

The lack of routed messages initially seems like a big limitation of the message bus approach. However, following the SOA analogy that started this series of posts, we can simply introduce a router to add the missing functionality in a way that respects the O in SOLID.

The Nought and Crosses implementation then shows the router and the rest of the message bus in action in a real, albeit small, example.

In-Process Message Bus

In my last post I discussed the idea of designing single process applications in a way that mimics a SOA i.e. the application is decomposed into services that communicate solely via asynchronous messaging. As promised, here I’ll discuss the key concepts in the proof-of-concept implementation. If you want all the details then take a look at the source, which is a mixture of F# and C# code.

IMessageBus

Firstly, the message bus interface has been split into an IMessageDispatcher and an IMessageBus:

type IMessageDispatcher =
    abstract member Publish : 'TEvent -> unit
    abstract member Send : 'TRequest -> Task<'TResponse>

type MessageProcessingMode = 
    | Sequential = 0
    | Concurrent = 1

type IMessageBus
    inherit IMessageDispatcher
    abstract member RegisterEventHandler: IEventHandler<'TEvent> -> MessageProcessingMode -> unit
    abstract member RegisterRequestHandler: IRequestHandler<'TRequest, 'TResponse> -> MessageProcessingMode -> unit

IMessageDispatcher is only concerned with dispatching messages to the correct recipients; IMessageBus augments this with the ability to register message handlers. The RegisterEventHandler and RegisterRequestHandler methods now take a MessageProcessingMode that specifies whether the handler can process messages concurrently i.e. whether it is thread-safe.

Services will typically take a dependency on IMessageDispatcher, as they just need to publish/send messages rather than register new handlers.

IMessageQueue

Next we need to wrap each service in a message queue that can forward messages to the correct handler implementation whilst ensuring that the MessageProcessingMode is enforced:

type IMessageQueue = 
    abstract member Publish : 'TEvent -> IMessageDispatcher -> unit
    abstract member Send : 'TRequest -> IMessageDispatcher -> Task<'TResponse>
    abstract member Service : obj

The reason for IMessageDispatcher appearing in the method signatures is so that the queue can publish an ExceptionMessage if the handler throws an exception. This makes it possible for a global exception handler to deal with all exceptions.

IMessageQueue Implementations

There are two implementations of IMessageQueueMessageQueue and NullMessageQueue. MessageQueue, as expected, enforces sequential processing of messages via an F# agent; NullMessageQueue is a simple pass-through to the underlying handler (i.e. it allows concurrent message processing) that can be used as a performance optimisation in the case where the handler is known to be thread-safe (i.e. the handler was registered using MessageProcessingMode.Concurrent).

MessageQueue

type internal AgentMessage =
    | AsyncAction of (unit-> Async<unit>)

type internal AgentResponse<'T> = 
    | Response of 'T
    | Error of exn
                
type MessageQueue(service : obj) =
    let agent = 
        Agent.Start(fun inbox ->
            let rec loop () =
                async { 
                    let! AsyncAction(forwardMessageToService) = inbox.Receive()
                    do! forwardMessageToService()
                    return! loop() 
                }
            loop())
    
    let publishExceptionAndReply e (bus : IMessageDispatcher) (replyChannel : AsyncReplyChannel<AgentResponse<'TOut>>) = bus.Publish (ExceptionMessage(e))
                                                                                                                         replyChannel.Reply (Error(e))

    let sendRequest (request : 'TIn) (replyChannel : AsyncReplyChannel<AgentResponse<'TOut>>) bus (service : obj) =
        async { 
            let handler = service :?> IRequestHandler<'TIn, 'TOut>
            try
                let! response = Async.AwaitTask (handler.HandleRequest request)
                replyChannel.Reply (Response(response))
            with
            | :? System.AggregateException as ae -> publishExceptionAndReply ae.InnerException bus replyChannel
            | e -> publishExceptionAndReply e bus replyChannel
        }
    
    let publishEvent (event : 'TIn) (bus : IMessageDispatcher) (service : obj) =
        async { 
            let handler = service :?> IEventHandler<'TIn>
            try
                handler.HandleEvent event
            with 
            | e -> bus.Publish (ExceptionMessage(e))
        }
    
    interface IMessageQueue with
        member x.Service = service

        member x.Send<'TIn, 'TOut> (request : 'TIn) bus = 
            let resp  = agent.PostAndAsyncReply<AgentResponse<'TOut>>(fun replyChannel -> AsyncAction(sendRequest request replyChannel bus service))
            Async.StartAsTask (
                async { 
                    let! res = resp
                    match res with
                    | Response r -> return r
                    | Error e -> return (raise e)
                }
            )

        member x.Publish<'TIn> (event : 'TIn) bus =
            agent.Post (AsyncAction(publishEvent event bus service))

MessageQueue‘s agent receives messages of type AgentMessage and replies with messages of type AgentResponse. AgentMessage is just an async computation that the agent can execute. The exact computation is specified by the sendRequest and publishEvent methods, but they both forward the original message to the correct message handler implementation and deal with responses/exceptions. AgentResponse contains either the successful response or the failure exception, and is a useful way to get around MailboxProcessor’s strange exception handling behaviour.

NullMessageQueue

type NullMessageQueue(service : obj) =
    let publishExceptionAndReply (e : exn) (bus : IMessageDispatcher) = bus.Publish (ExceptionMessage(e))
                                                                        raise e

    interface IMessageQueue with
        member x.Service = service

        member x.Send<'TIn, 'TOut> request bus =
            let handler = service :?> IRequestHandler<'TIn, 'TOut>
            let handleAsync = async { 
                                  try
                                      let! response = Async.AwaitTask (handler.HandleRequest request)
                                      return response
                                  with
                                  | :? System.AggregateException as ae -> return (publishExceptionAndReply ae.InnerException bus)
                                  | e -> return (publishExceptionAndReply e bus)
                              }
            Async.StartAsTask handleAsync
            
        member x.Publish<'TIn> event bus =
            let handler = service :?> IEventHandler<'TIn>
            let handleAsync = async { 
                                  try 
                                      handler.HandleEvent event 
                                  with
                                  | e -> bus.Publish (ExceptionMessage(e))
                              }
            Async.Start handleAsync

NullMessageQueue is just directly forwarding messages to handlers without involve an F# agent. However, to ensure that exceptions are handled in the same manner as MessageQueue, the invocations need to be wrapped in async computations.

Architecture

So, the updated diagram looks like this:

When handlers are registered with the message bus, the MessageToQueuesMap is told to add the required message queue to the collection of queues that process the given message type. Then, when the message bus receives a message it asks the map for the collection of queues that the message should be forwarded to. Events can be forwarded to multiple handlers (e.g. ServiceA and ServiceB both implement IEventHandler<EventA>),
but requests must only have a single handler.

Note that each service can be wrapped in at most two IMessageQueue instances – one MessageQueue and one NullMessageQueue. All messages that need to be processed sequentially go through the MessageQueue, and all messages that can be processed concurrently go through the NullMessageQueue. The MessageQueueCache (not shown) is responsible for providing the correct queue(s) for each service, and is used by the MessageToQueuesMap during handler registration.

Load Balancers

If a message handler cannot handle concurrent messages, it may by swamped by high message volumes whilst not utilising the available cores. As mentioned in the previous post, this can be solved by using a load balancer. There are two versions, one for handling events and one for requests. Both make use of Tomas Petricek’s BlockingQueueAgent class, which enables Producer/Consumer scenarios.

Rather than listing the code here, I’ll point you to the EventLoadBalancer and RequestLoadBalancer.

Wrapping Up

This post is already long enough and I’ve delayed publishing it for too long, so I’m going to defer further discussion for the next post. There I’ll discuss the pros and cons of the current implementation and also compare the concept to a pure Actor Model.

Honey, I Shrunk the SOA

I’ve recently been thinking what would happen if we applied the principles of SOA (done properly, using asynchronous messaging) to the design of code running within a single process. In other words, the code would consist of independent services that could only communicate asynchronously via some kind of message bus. What would this look like? Would it have any benefits?

Before I go any further, I should point out that I did some research and discovered that Svein Arne Ackenhausen had not only been thinking along these lines, but was also using them in production. His blog post summarises the benefits as he sees them, and he linked to his standard implementation. However I’ve not been able to find any other articles discussing these ideas, so I thought I’d write up my thoughts in the hope that I can get some useful feedback.

Svein’s implementation is a very nice, simple approach (a good thing!) which clearly demonstrates that there aren’t any great technological barriers to adopting this design pattern. However, I think it may benefit from some additions.

Firstly, as Svein mentions, stateful services have to be modelled very carefully because the service can be handling multiple messages concurrently. What if we sidestepped this problem by combining the message bus concept with the Actor Model so that each service behaves as an actor that processes messages sequentially? Now we can use stateful services where appropriate without having to worry about concurrency.

Secondly, it only really deals with publishing events: there is no concept of request/response. We could mimic request/response by convention (handlers of IFoo must themselves publish a message of type IFooResponse in return), but as Svein pointed out in his blog post, one of the benefits of this approach is that:

By making sure that your code feature produces an output in the shape of a message you have made that code feature a stand alone piece of code. It can now make sense beyond the contract that would have otherwise been passed to it. Being a stand alone piece of code it becomes a natural place for integration. Integration that would happen through consuming a message or producing a message that other participants can consume through the message dispatcher.

To maximise this benefit I feel we should be making explicit the difference between publishing an event and sending a command or querying for data. This is something that, for example, NServiceBus makes explicit via the Publish() and Send() methods on its service bus interface.

So what would such an API look like? First we need the message handling interfaces that services can implement:


public interface IEventHandler<TEvent>
{
    void HandleEvent(TEvent message);
}

public interface IRequestHandler<TRequest, TResponse>
{
    Task<TResponse> HandleRequest(TRequest message);
}

By returning a Task the IRequestHandler will integrate nicely with the async features of C# 5.

Next we need the message bus interface:

public interface IMessageBus
{
    public void RegisterEventHandler<TEvent>(IEventHandler<TEvent> handler);
    public void RegisterRequestHandler<TRequest, TResponse>(IRequestHandler<TRequest, TResponse> handler);
    public void Publish<TEvent>(TEvent message);
    public Task<TResponse> Send<TRequest, TResponse>(TRequest message);
 }

Then at the application root we can configure the system by registering services with the message bus:

var serviceA = new ServiceA; // implements IEventHandler
bus.RegisterEventHandler(IEventHandler serviceA);

var serviceB = new ServiceB; // implements IRequestHandler
bus.RegisterRequestHandler(IRequestHandler serviceB);

And services can interact with the bus like so:

public async void DoStuff()
{
    // some actions...

    // this will send the ReqA message and asynchronously await the response
    var result = await bus.Send(new ReqA());

    // do other stuff with the result...
}

Whilst it is a nice idea to avoid concurrent message processing in the services, we need a way of handling the situation where the service cannot process the messages quickly enough. The solution comes from considering the SOA approach: simply add multiple service instances behind a load balancer! For example:

public class EventLoadBalancer : IEventHandler<TEvent>
{
    public LoadBalancer(Func<IEventHandler<TEvent>> slaveFactory)
    {
        // set up appropriate queues etc to hold slave instances
    }

    public void HandleEvent(TEvent message)
    {
        // forward message to chosen slave instance
    }
}

Because the load balancer is itself an IEventHandler<TEvent>, we can simply pass it to the RegisterEventHandler method on the message bus instead of passing the service instance.

So far, so theoretical. How can we implement the actor functionality? Luckily, F# already supports agents (F# terminology for actors) via its MailboxProcessor class. So all we need to do is place an F# Agent between each service and the message bus (this can be done by the RegisterEventHandler and RegisterRequestHandler methods of the message bus):

So, the F# Agent will be responsible for forwarding the message to the appropriate message handler interface of the service and it also ensures that the service does not process multiple messages concurrently.

This approach could be the high level architecture, and would in no way constrain lower level design choices. So, individual services could be implemented in a traditional OO manner, a pure functional manner, or anything in-between. A service could even be decomposed into sub-services and use an internal message bus.

In the next post I’ll look in more detail at a proof-of-concept implementation. In the meantime, I’ll point out a couple of things I found out whilst writing this post:

  1. The next version of NServiceBus will likely have an in-process mode. It will be interesting to see what form this takes.
  2. Alan Kay, who coined the term “object oriented” believes that the messaging between objects is far more important than the objects themselves. Maybe we are heading back closer to his original vision?

Reactive Asynchronous Batch Logging

Update: The Jeffrey Richter post I mentioned has gone missing from his blog – a copy can be found here.


Jeffrey Richter recently blogged about an interesting threading problem involving batching up a set of log entries in memory until either a certain amount of time has elapsed or the size of the batch reaches a given limit and then flushing the entries to storage. He provided an intricate solution involving a SpinLock to avoid blocking threads.

Reading about the problem made me think that, if performance is not critical, there must be a simpler solution. It sounded like something that the Reactive Extensions should be able to handle. Sure enough, a bit of digging around (I was aware of the technology, but had never used it) yielded the Observable.Buffer extension method.

All that was left was to convert calls to the Log(string message) method into events, which in turn can be converted into an Observable that the Buffer method can operate on:

namespace ItWorksOnMyMachine
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.Reactive;
    using System.Reactive.Linq;

    public class RxLogger
    {
        private event EventHandler<LogEventArgs> MessageLogged;

        public RxLogger(int maxCount, TimeSpan maxInterval)
        {
            var obs = Observable.FromEventPattern<LogEventArgs>(e => this.MessageLogged += e, e => this.MessageLogged -= e)
                                .Buffer(maxInterval, maxCount)
                                .Subscribe(WriteLog);
        }

        private void WriteLog(IList<EventPattern<LogEventArgs>> events)
        {
            // Write messages to storage
        }

        public void Log(string message)
        {
            MessageLogged(this, new LogEventArgs(message));
        }

        private class LogEventArgs : EventArgs
        {
            internal string Message { get; private set; }

            internal LogEventArgs(string message)
            {
                Message = message;
            }
        }
    }
}

A production implementation would need to consider disposing of the Observable, but even allowing for that, the solution is short and sweet.

Just like LINQ, all .NET developers need to be aware of the capabilities of Reactive Extensions. It is a game changer.