Failure is inevitable

In my last article, I introduced the Application Bus pattern, a specialization of the Message Bus pattern. I’m employing an Application Bus in RageFeed, the hobby social networking application I sometimes work on. Today, I’ll show you how the bus utilizes StructureMap for locating message end points and for dispatching messages. I’ll also explain why I chose to build my own bus instead of leveraging an existing one, such as the bus available in MVCContrib.

The RageFeed Application Bus

I showed some of the interfaces from the RageFeed bus last time. It’s pretty barebones, but it supports both one-way and two-way messaging patterns. In one-way messaging, the sender does not require any sort of response or acknowledgement. In two-way messaging (also known as request-reply messaging), the sender sends a message, then waits for a response to be sent back by the message’s handler.

Classes that want to send messages over the bus simply use the IBus interface, while classes that want to receive messages implement one of the two handler interfaces. The registry interface is used by the concrete implementation of IBus to locate message handlers.

IBus is implemented by MessageBus. It’s a trivial implementation, but it has met every requirement we’ve had so far:

As you can see, the implementation really is quite simple: it receives a message, asks the registry for a suitable handler, then dispatches it to the handler. There’s a lot of room for additional features (better error handling, exposing hooks to allow messages to be inspected and/or modified, etc), but we just haven’t had a need for those things yet.

The MessageHandlerRegistry implements (surprise!) IMessageHandlerRegistry, and its job is managing the handlers. For this, it utilizes StructureMap’s IContainer interface:

Again, this class is fairly simple, all the heavy lifting is provided by StructureMap.

By convention in RageFeed, anything that implements either of the IHandle interfaces is automagically registered; there’s no need to manually register anything. This convention is accomplished using a StructureMap registry that scans all RageFeed assemblies and wires up message handlers appropriately:

The “magic,” such as it is, comes from the IAssemblyScanner.ConnectImplementationsToTypesClosing method provided by StrucutreMap. The method connects all concrete types that implement either handler interface to the closed version of the interface. It’s essentially doing this, but for every handler type in the entire project:

As I said in my previous post, message passing is the loosest form of coupling that can be achieved in software: our controllers are completely decoupled from the core domain logic, which means we can easily reuse our core domain in a Silverlight or desktop version of the app. We can also distribute the core logic across logical or physical boundaries to increase scalability without having to modify our controllers.

“But Matt, didn’t you just reinvent the wheel?”

There are indeed open-source Application Bus implementations in the wild now, though I only know of one that has attained any sort of widespread use: the MVCContrib bus. As RageFeed does indeed utilizes MVCContrib, it would have been quite easy to just build on MVCContrib’s bus. However, I really don’t care for the implementation of the MVCContrib bus. First, it requires handlers to be manually registered with the bus:

This is not conducive to the zero-friction development we are attempting to maintain in RageFeed. We could have built a little bit of infrastructure to automatically register our handlers, but that wouldn’t have addressed my next concern: that the bus must create instances of each handler in order to find a suitable handler for a message. You can see this behavior here:

If you have a lot of handlers, this could be expensive, especially if you have handlers that depend on expensive-to-create resources. Sure, you could rework your handlers to lazily-create such resources, but that’s once again taking us farther away from zero-friction development. I wanted a bus that just worked without requiring anyone to write code with regard to how the bus functions.

Note: It’s worth pointing out that MVCContrib’s bus is not trying to be a general-purpose Application Bus. It exists mainly to support MVCContrib’s Portable Areas feature.

Bus.Send(new EndOfPostMessage());

Well, that’s it for this week’smonth’s quarter’s blog post. I’ve shown you a very barebones Application Bus implementation utilizing StructureMap. As RageFeed develops, I expect the capabilities of the bus will grow as we find new ways to utilize it. I’ll be sure to post more when that happens. In the meantime, please share your questions and comments below. Thanks!

About Matt Honeycutt...

Matt Honeycutt is a software architect specializing in ASP.NET web applications, particularly ASP.NET MVC. He has over a decade of experience in building (and testing!) web applications.
He’s an avid practitioner of Test-Driven Development, creating both the SpecsFor and SpecsFor.Mvc frameworks.

He's also an author for Pluralsight,
where he publishes courses on everything from web applications to testing!