nServiceBus - The Good and the Bad

Created 23 November 2009 12:56

We've been using nServiceBus at work for the last week or two to send messages between a client and server in a (hopefully) robust fashion.

As a tool, I really like nServiceBus. Once you have it up and running, the use of MSMQ is just brilliant - force a crash in your application and when you start up again they're just there still, ready to be processed - right out the box. Wrap them in a transaction (MSMQ supports MSDTC) and anything goes wrong, the sending of the message gets rolled back. Awesome stuff - it's definitely something I will use again.

But that's not the point of this post. I'm going to point out all the BAD stuff - in the hope that someone else doesn't have the same fights I did. Let me say upfront that I recommend using it - just be aware that the document isn't just bad, it's DISMAL. The author seems to assume that we all understand how the bus works and how to use it - methods are undocumented and even the documentation on how to get it up and running is hopelessly inadequate. So, here goes.


The nServiceBus site does have some documentation regarding publish/subscribe scenarios at http://www.nservicebus.com/PubSubApiAndConfiguration.aspx. However, the way it's worded just didn't make sense to me, and it was Rohland who finally worked out what the hell they mean.

Exhibit A

The above configuration specifies the INPUT to your assembly's message handler. In this example, the application using this configuration will listen for messages on the MSMQ "myqueue" on the local machine. It will NOT place messages on that queue - this is the queue it will pick messages up from.

Exhibit B
  <UnicastBusConfig DistributorControlAddress="" DistributorDataAddress="">
      <add Messages="My.Messages" Endpoint="somequeue" />

This configuration specifies where your application will publish messages TO! In this example, any messages in the "My.Messages" assembly will be placed on the "somequeue" MSMQ on the local machine. You can specify message types instead of assemblies if you want to. I quite like this - it makes it very easy to publish different messages to different queues, and it's all configurable. Also note that the end point doesn't have to be local - you can specify remote machines as per the nServiceBus documentation.

Message Handlers

In order to receive messages, your assembly that handles those messages needs to incorporate a message handler class, with support for the message types you want to receive. For example, if you want to subscribe to message types "A" and B", you can create a message handler like so:

public class MessageHandler : IMessageHandler<A>, IMessageHandler<B>
    public void Handle(A message)
        // handle messages of type A

    public void Handle(B message)
        // handle messages of type B


You don't hook this class up anywhere - nServiceBus will find it and instantiate it. I don't like that. It makes it really easy to make mistakes - make a typo on your namespace and your event handler is never invoked, and you sit there scratching your head wondering why until you finally realise your config is fine, and your typing sucks. Another downer is that this is running on a separate thread to your application, so you need to invoke a delegate on appplication's main thread to handle the code, which can be a little iffy in forms development - you need to write code like the following to get a handle on the form that you want to use, like so:

FormMain fm = FormMain.GetInstance();
fm.Invoke(fm.AddInboundMessageHandler, message);

Enumerations and/or More Complex Data Structures

One problem I found, when using version 1.9, was when sending an enumeration of custom objects via a message. My message class contained an array of custom objects, which themselves had two properties: a string property and a byte array property. Nothing complex here. However, when I picked up the message on the subscriber, the collection was there, with the correct number, but the properties of the objects in the array were always null. I just couldn't get this to work at all. Converting the array to a dictionary was even worse - I got exceptions from nServiceBus, which seemed to fall over on some rather dodgy reflection code.

One thing I did find out is that your sub-entities do need to have a default, parameterless constructor, which makes sense as nServiceBus needs to recreate the serialized objects from the queue on the other end. However, try as I might, I never got this working on 1.9. Upgrading to version 2.0, however, and it all started working. I did try converting my array into a typed list for convenience, but this didn't work off the bat and wasn't that important to me so I reverted back to an array.

That's all I can think of for now - I'm sure I'll update this post in the future.


When I started looking at this there was NOTHING out there - but people are certainly using it. Her are some decent articles on nServiceBus:

Udi Dahan on 24 November 2009 at 12:20
Matt,<br /><br />Have you seen what&#39;s currently online at NServiceBus.com? <br /><br />There&#39;s a FAQ outlining many of the points you mentioned here:<br /><br />http://www.NServiceBus.com/Documentation.aspx<br /><br />Are there other open source service buses with better documentation - something that could be emulated?
Matt Salmon on 24 November 2009 at 13:50
Hi Udi<br /><br />Thanks for responding. I have read the documentation on the site, and although it&#39;s not the worst documentation in the world, I think my problem with it is that it&#39;s only easy to understand once you understand HOW NSERVICEBUS WORKS. <br /><br />Maybe I&#39;m just thick, but it really took a lot of trawling to get my application to work. Admittedly, my application is fairly complex - but I didn&#39;t find the site very useful at in understanding how nServiceBus works. <br /><br />When I go back to the documentation online now and look at it, it makes sense - but as a newcomer to your product it didn&#39;t help me much. Most of the points I mention are documented on your site, but their explanation was not detailed enough for me to really grasp what was going on - it&#39;s too segmented without a decent example of how to bring it all together. The sample code is there for download, but the sample projects contain almost no comments. I learned a lot more from those posts by mookie (I provided a link) than from the nServiceBus documentation - the problem for me was that those articles were only posted a few days ago and up until then I struggled. <br /><br />What you really need is a more organised, central documentation space on your site - currently documentation is spread between various pages that aren&#39;t easy to find. For example, <a href="http://www.nservicebus.com/PubSubApiAndConfiguration.aspx" rel="nofollow">this page</a> is very useful, but is hidden away within the site.<br /><br />To answer your question, no, I&#39;m not aware of any other open source service buses with better documentation - but that doesn&#39;t mean yours can&#39;t be a lot better. I think you&#39;ve got a really great tool here that is incredibly useful and I will definitely be using it in more projects in the future, but the documentation is in my opinion a barrier to entry in terms of people adopting it.<br /><br />If you&#39;re looking into ways of presenting your documentation, I found the <a href="http://www.castleproject.org/activerecord/index.html" rel="nofollow">Castle ActiveRecord documentation</a> very helpful in terms of getting started a few years back, although admittedly their documentation does fall down with more complicated examples.<br /><br />Does that make sense, or do you think I&#39;m off base?<br /><br />Cheers<br />Matt
Udi Dahan on 16 December 2009 at 15:20
Matt,<br /><br />The biggest challenge we have with documentation is that NServiceBus is designed to be a framework for a different kind of architecture than most people are used to. Documenting that architecture has been the theme of my blog for the past several years and I provide 5-day courses teaching it. Besides putting up some recorded presentations on point-topics, the NServiceBus documentation probably won&#39;t ever do justice to the architecture.<br /><br />On the other points you&#39;ve mentioned, yes, work does need to be done - and is being done. Your feedback is valued. For example, the main documentation link now links to all the other pages - any other suggestions you have would be most welcome.<br /><br />One thing you mentioned:<br /><br />&quot;make a type on your namespace and your event handler is never invoked&quot;<br /><br />NServiceBus invokes every handler, regardless of the namespace it&#39;s in. <br /><br />Can you provide some more information on the specific thing you did, and what happened - what worked and what didn&#39;t?
Matt Salmon on 17 December 2009 at 08:11
Hi Udi<br /><br />I absolutely agree with you - it&#39;s difficult documenting what you have - it&#39;s the concepts that are the difficult part to grasp rather than the code aspects of it. <br /><br />Firstly, thanks very much for updating the documentation section on your site - I really think that&#39;ll be a huge helper for anyone starting with NServiceBus. I think one of the difficulties I had was that the fragmentation of the documentation meant it didn&#39;t &quot;gel&quot; nicely - there wasn&#39;t a single reference point to look at when confronted with an issue. I think this will help.<br /><br />In terms of my comment on the typo, I have to admit I have no idea what happened - it was a couple months ago. All I remember was that the solution was to correct a typo in a namespace, and it all started working. This was an issue in version 1.9 though - although I&#39;d love to be able to recreate what happened as it doesn&#39;t seem like it was possible.<br /><br />I think the situation was something like the Assembly was &quot;MyAssembly&quot; with a default namespace of &quot;MyAssembly.Namespace&quot;, and the message handler was in a namespace &quot;MyTypoAssembly.Namespace&quot;. Fixing the typo resulted in the messages popping up. <br /><br />I assume you&#39;re using reflection to iterate through the types, so I don&#39;t see how this is possible. Maybe there was something screwy on my machine at the time, I don&#39;t really think it&#39;s worth looking into. Also, it was version 1.9 and I&#39;ve had no issues with version 2 - I think it&#39;s safe to say it&#39;s either resolved or the problem was a user error (me).<br /><br />When I get some time I&#39;ll see if I can reproduce what I did.<br /><br />Matt
Matt Salmon on 17 December 2009 at 08:15
Udi<br /><br />Another issue we have encountered is debugging with NServiceBus. On a web application, if we fire up a bus instance, our visual studio debugging doesn&#39;t work. We literally have to comment out the service bus instantiation to debug other parts of the application. <br /><br />Have you had any other queries like this? <br /><br />Matt
Udi Dahan on 20 December 2009 at 23:23
Matt,<br /><br />I haven&#39;t heard of anybody else having those issues - maybe post it to the discussion group and see what others say.
Johan on 05 April 2011 at 09:50
Matt,<br /><br />Have you guys resolved the issue with not being to debug in visual studio?<br /><br />Thanks<br />Johan
Matt Salmon on 05 April 2011 at 12:34
Johan,<br /><br />We never got to the bottom of it, and since I posted that comment we&#39;ve started using Visual Studio 2010 where the problem doesn&#39;t seem to occur. Must be some kind of bug with VS 2008 I guess, as I haven&#39;t seen it in ages.<br /><br />Cheers<br />Matt