Why I have already stopped working on NServiceBus again

Posted on by mookid8000 1 Comment

In my previous blog post I announced that I had joined the NServiceBus core team on September 1st, and at the time of writing, I have been working with them part time for two months.

I have already decided to stop working on the NServiceBus core team again though (as of November 1st), and in this blog post I’ll try to explain why.

In the beginning, I was really excited about getting to work with the awesome team that Udi Dahan has assembled to work on NServiceBus, and of course also to get to work with Udi himself, whom I admire and whose work I have followed closely during the last 5 years or so.

I knew that joining the NServiceBus team would mean that I would have to give up working on Rebus at some point, but I thought that that would not be a problem for me.

When work started though, I did have a slightly uneasy feeling, and it was hard for me to get excited about the actual work we were doing. I originally attributed that to the fact that I was working part time and thus had to do a lot of catching up every time I finally had time to work.

But I have come to realize that the reason I was not that motivated was that I was missing Rebus. And I realized that I felt odd because I was being the least enthusiatic person on a team where everyone else radiated pure excitement.

I really really want to be excited about the work that I am doing, and I know that I am usually capable of mustering tremendous excitement whenever I get to focus on some project or task that makes sense to me – but I’m afraid that I would not be able to generate that level of excitement for NServiceBus.

Therefore I thought that it would be most fair to everyone that I would stop working on NServiceBus and leave that space for someone who can be truly passionate about it.

This means that I’m back doing full time Awesome Stuff at d60 again, although my role will probably be twisted slightly away from consulting towards something with Rebus and messaging, some R&D, some Windows Azure, and possibly some other stuff that I will probably get back to in future blog posts 🙂

Exciting times!

Posted on by mookid8000 Leave a comment

Preface

Back in 2011 I had worked with NServiceBus for a couple of years, and I was very happy about using it. I became sad though, when NSB version 2.5 was announced, because Udi had decided that NServiceBus would go away from the ultra liberal Apache V2 license, to requiring a paid license to use it in production.

I wasn’t sad because I thought that NServiceBus wasn’t worth the money. I was sad because I knew that the money aspect – just the fact that there was a money aspect – would suddenly become a barrier for me to introduce NServiceBus into future small to medium-sized projects.

I also realize that the money aspect was probably the one thing what was missing for NServiceBus to be looked at with greater seriousness by many companies worldwide, so – from a business perspective – I totally understand the move. It just didn’t fit my plans of building cool distributed stuff, made entirely from free frameworks and libraries.

Taking matters into my own hands

Therefore, on September the 11th 2011, I made the initial commit to the Rebus repository and laid the ground for what I wanted to be a kind of “lean NServiceBus little brother”, an NServiceBus stand-in that could be used in small systems until they became serious enough to warrant the license fee.

From the outset, Rebus mimicked NServiceBus’ APIs, and would even be able to read and understand NServiceBus endpoint mappings, so as to make porting systems back and forth between Rebus and NServiceBus easy.

Rebus turned out to be pretty neat though, and it didn’t take many alpha versions before money was suddenly being moved around by Rebus. And a few versions after that, Rebus would help some people control a couple of power plants. At that point, I hadn’t even had the chance to use Rebus to build something real myself, but other people were happily using it to solve their messaging problems.

Today

Fast forward two years, and I’ve helped build several systems with Rebus, and I get to go to conferences and talk about it, and a big part of my daily work is to help my awesome colleagues at d60 build systems using messaging.

All is peace and quiet in Rebus-land, and then – BAM!1 – I get an email from Udi saying something along the lines of: “Have you considered turning to the dark side?” – where Udi invites me to become part of the NServiceBus core team…………!!

I did not see that one coming.

AND like that, I’m in a huge dilemma – because I really love working at d60, and I love my awesome colleagues, and I love the spirit that we have succeeded in building in the company – so it pains me to think that I would no longer be part of the d60 project.

On the other hand, I realize that this an immensely awesome opportunity to

  • get to work with Udi, whose work I have admired for the last 5 years, and
  • get to work with some of the most talented .NET developers on the globe to
  • help building a messaging library, full time, as my day job – a task that I apparently think is fun enough that I will do it while doing the dishes, while sitting up at wee hours, again and again at our monthly hackernights, etc.

Therefore – a tough decision, but an obvious one. So of course I accepted Udi’s invitation!

So how’s that going to happen?

Luckily, d60 have been nice enough to make an agreement that I can start working on NServiceBus right away, ramping up my efforts over the next 6 months while I ramp down my d60 activities. I will not ramp all the way down though: I’ll continue to hang out at the d60 office and help d60 make cool distributed stuff with messaging, participate in brown-bag meetings, etc. I’ll just spend most of the time working with the NServiceBus core team.

But what about Rebus?

There’s no doubt that I will concentrate my efforts on NServiceBus now.

But Rebus still exists! Noone can deny that 🙂 And Rebus has gained traction in places, in big as well as small companies that will most likely NOT readily replace it with something else, so I expect Rebus to continue to be refined and be maintained by its community for a long long time.

I’ve agreed with Asger Hallas, whose contributions to Rebus throughout the last two years have been invaluable, that he will be the new Rebus lead.

Asger has contributed with code in the form of all of Rebus’ RavenDB integration and several improvements, and he has contributed with excellent insights into the technical challenges of building a messaging library, and our lengthy discussions have brought much awesomeness to the table. I can think of no better person to continue the direction in which Rebus is heading.

I’m a Rebus user – should I be worried?

I don’t think so. If Rebus can make your endpoints communicate now, Rebus will still be able to make your endpoints communicate in the future. Rebus has never had an ambition to become bigger than it is right now, so if you’re satisfied now, chances are you’ll be satisfied tomorrow as well.

I’m still gonna be around!

Also: I’m not going away! I’ll still be around for helping out if you have trouble with using Rebus. I have just been given the opportunity to focus on helping a great team improve the most popular .NET service bus framework, which I hope will teach me a lot about messaging and hopefully turn out to be beneficial for NServiceBus as well.

So, please don’t hesitate to contact me if you have any questions regarding Rebus down the road. And in the future, I might be able to answer a few questions about NServiceBus as well 😉

Cheers!

Edit: If you’re interested, check out Udi’s perspective on this.

Rebus and message expiration

Posted on by mookid8000 Leave a comment

If you have worked with NServiceBus, and you’ve tried Rebus as well, you might be wondering where that nifty [TimeToBeReceived] attribute went? You know, that attribute that you would decorate your messages with when you wanted to have MSMQ expire the messages for you to prevent your queues from clogging up with irrelevant messages if the recipient was down.

The answer is: There’s no such attribute in Rebus! And that’s because that would require your messages assembly to reference Rebus, and that should not be a requirement. Rebus allows your messages to be POCOs, so your messages assembly should be allowed to stay “plain” in that POCO sense.

How to set time to be received then?

With Rebus you set the time to be received property of your messages by attaching a special Rebus header to your messages: Headers.TimeToBeReceived. The value must be a HH:mm:ss string, e.g. "00:01:30" to set a 1 minute and 30 seconds expiration timeout on a message.

E.g. like so:

This header will be detected later on by the transport implementation (e.g. MsmqMessageQueue), which will use the approproate settings when sending the message.

In MSMQ’s case, the message will then be deleted by the queueing system when the timeout expires, which is a nifty feature that can be used to avoid flooding the queueing system with expired and irrelevant messages.

But doesn’t that require a lot of tedious manual work?

Yes – which is why I suggest you use some of the nifty hooks in Rebus to reduce the amount of tedium involved. More on that in the next post.

Announcing: Rebus

Posted on by mookid8000 3 Comments
Preface

Friends and acquaintances might know that I’ve spent the last 6 months or so of my pastime, hacking on something I call Rebus. To cut a long story short, I can tell you that I am a happy NServiceBus user who became very sad when NServiceBus went from being free to requiring a commercial license – not because I think NServiceBus isn’t worth spending money on, but because I think it hurts the adoption of NServiceBus.

Speaking for myself, I have already refrained from using NServiceBus in a couple of smaller projects, where it would otherwise have been an awesome addition.

I seriously considered forking the 2.0 version of NServiceBus, which is licensed under Apache v. 2.0, but I was overwhelmed by the sheer size of the project. This led me to re-implement my favorite features of NServiceBus as Rebus, trying to focus and stay lean along the way.

And here it is: Rebus

Rebus – the core – depends on .NET 4 only. And since .NET 4 has MSMQ, ADO.NET, and binary serialization, you get to send and receive messages transactionally and persist your stuff in SQL Server without anything but Rebus core.

3rd party integration (like e.g. MongoDB, NewtonSoft JSON serializer, etc) is provided through small, dedicated add-on projects. This granularity makes it easier to manage your own dependencies.

Update: And since JSON serialization was deemed to be the preferred form of message serialization, it has been ILMerged into Rebus core since right after this announcement. Therefore, JSON serialization is included in the box and is the default.

There’s currently two ways to get started with Rebus:

  1. Instantiate RebusBus manually, filling in the ginormous constructor with implementations for how you want the bus to run.
  2. Use the configuration API.

Let’s try the configuration API – with the following snippet of XML in your app.config:

and the following piece of code in your app:

you should be up and running with a Rebus bus.

That was a small teaser – there’s more blog posts on the way, I promise 😉

So, what’s the state of this?

Well, that’s actually the whole point of this blog post – I’m currently in a situation where I really feel like putting Rebus to some serious use, but I cannot justify foisting it on a client until I have a big project to prove its worth. And I cannot prove its worth in a big project until I have a client I can fob it on.

That’s where you come in! 🙂

You:
  • You’re building something – it’s not totally mission critical, as in human lives depend on it, but it’s still something.
  • You want some nifty service bus technology to help you build a loosely coupled architecture that will allow your project to flex and bend and integrate with stuff in many years to come.
  • You wanted to use NServiceBus because it’s cool, but you can’t afford the cost up front.
  • You’re reading this blog post, or someone you know read it and is now telling you about it…

If that’s you, then you should meet Rebus!

Rebus:
  • Absolutely free to use and abuse.
  • Very very similar to NServiceBus, allowing you to migrate to NServiceBus some time in the future if Rebus is not enough for you.
  • Pretty simple.
  • Comes with unlimited[1. Within reason, of course – I have a day job, a wife, and two kids, so I’m not answering emails 24/7 – but I’ll go to great lengths to help you get a smooth adoption of Rebus – because that’s just how much I care :)] support from its author.
  • Did I mention it was free?
A match made in heaven?

If you have the slightest bit of interest in what I’m suggesting, please contact me – either via email or on Twitter – and then we’ll talk about what Rebus can do for you. Oh, and please don’t hesitate to contact me – even if you’re NOT planning on using Rebus, I’d like to know why you picked NServiceBus, MassTransit, or Rhino Service Bus instead.

If you’re just eager to try it out, feel free to Install-Package -Pre one or more of Rebus’ NuGet packages.

The duality of request/reply vs. publish/subscribe #2

Posted on by mookid8000 Leave a comment

In my last post, I described how the mechanics of publish/subscribe actually mirror those of request/reply.

In this post, I’ll look at the two operation from another angle: What do they mean?

What does it mean when you bus.Send?

Sending means either that the sender wants to

  • Command that another service does something.
  • Request that another service does something, and yields one or more replies[1. Note that the request/reply pattern may impose unwanted temporal coupling in an architecture and should probably be used only in integration scenarios orchestrated by a saga.].

This means that the sender knows stuff about the other service, but that other service will most likely not know or care about who’s sending. In other words, the sender depends on that other service!

What does it mean when you bus.Publish?

Publishing means that the publisher wants to

  • Broadcast an event that contains information on something that has happened.

This means that the publisher most likely does stuff inside itself, maybe updates some internal state, and then goes on and publishes information on some aspect of what has happened. In doing this, the publisher will most likely not know or care about who’s receiving. In other words, the subscriber depends on the publisher!

Summing it up with a picture

Consider this illustration, where service dependencies are shown with arrows:

Again, see how comparing Send to Publish is actually like comparing two mirror images when the other mirror image is upside-down?

The duality of request/reply vs. publish/subscribe #1

Posted on by mookid8000 Leave a comment

A question I often meet in relation to messaging frameworks like NServiceBus and Rebus, is this: Where do messages go?

The confusion often comes from comparing how bus.Publish works with how bus.Send works.

In this post, I’d like to describe the two operations and show that they are mirror images of each other – except maybe not as much a mirror image as a transposition.

Sending messages

In the case where you’re doing a bus.Send(message), the answer is trivial: The message gets sent to the endpoint specified in the sender’s enpoint mapping for that message type. Let’s say our sender is equipped with this snippet of XML[1. The snippet is an endpoint mapping in NServiceBus format, which can also be understood by Rebus when it’s running with the DetermineDestinationFromNServiceBusEndpointMappings implementation of IDetermineDestination] in its app.config:

If we assume that message is an instance of a class from the MyService.Messages assembly, in this case a bus.Send(message) will be translated into bus.Send("my_service", message).

Publishing messages

But where do messages go when they’re published? Well, they go to whomever subscribed to that particular message type – and with NServiceBus (and, for that matter, with Rebus as well) subscribers get subscribed by sending some kind of subscription message, which is basically saying: “Hey there, mr. Publisher – I’m some_subscriber, and I’d like to subscribe to MyService.Messages.SomeParticularMessage”.

From this point on, the publisher will store the mapping of the message type along with the subscriber’s address, allowing a bus.Publish(message) method to be implemented something along the lines of

So – how do we understand this on a higher level, allowing us to never ever confuse these things again? Let’s dive into…

The duality

Consider these two sequence-like diagrams:

See how request/reply and publish/subscribe are actually the same patterns? The reason these two are often confused, is that the Send operation is often countered by Publish, when in fact it would be more fitting to see the subscription message (i.e. subscription request) as the counterpart of Send. Thus, Publishing is more like replying. And thus, Send is actually the transposition of Publish.

Now, when you realize this, you’re never going to confuse these things again 🙂 In the next post, I’ll touch a little bit on another difference between Send and Publish.

I will be speaking at Miracle Open World 2012

Posted on by mookid8000 Leave a comment

In April, I will be doing two presentations at Miracle’s Open World conference. It looks like a lot of cool people are going, and it’s my first time at MOW, so it goes without saying that I’m excited about it!

First, I’ll be doing a brand new intro to NServiceBus, which I have used extensively for the last two years. Even though I wish it was free for everyone to use, NServiceBus continues to be an awesome framework, so I’d like to continue spread the word about it – you can read my abstract here: Ride the Bus!.

After that, it seems I’ll be topping off day one with a brand new, condensed, platform-agnostic and pure MongoDB tour – this one will not do the usual “and this is NoSQL, and this is what characterizes a document DB”-intro, this will be full-on and to the point. You can read about it here: So you want to liberate your data?

I hope to see a lot of engaged people there 🙂

How to set the current culture in NServiceBus

Posted on by mookid8000 3 Comments

Today we were experiencing some weird behavior when running an integration test with DillPickle, where – apparently – values of doubles would lose their decimal point when they were transferred in messages from our test to an NServiceBus service.

Stopping the service and inspecting the message in the queue quickly revealed a message that looked somewhat like this:

which is all fine and dandy.

Now, I’m used to being Danish, so I know that we’re somewhat deviant in regards to our decimal point – “,” – so we quickly diagnosed the problem: Our integration tests were running with the invariant culture, to allow us to parse Gherkin files in English and use “.” as the decimal point – but Windows and everything else was running with da-DK, so 13.56 would be improperly deserialized to the value 1356 when it reached our NServiceBus service.

Solution: Normalize the culture of all the processes of our system.

Our first attempt was to modify the culture in our endpoint configuration like so:

but obviously this did not work, because NServiceBus does not deserialize messages on this thread!

Our solution was to create a message module, which seems to get called before transport messages are deserialized, setting the culture in there – like so:

In the future I’ll make sure that the culture is explicitly set in all processes of systems I am building. It’s kind of scary that errors could happen where stuff like “debit account 100.00” could be mis-interpreted as “debit account 10000”!! 😮

Assuring that those IWantToRunAtStartup can actually run at startup

Posted on by mookid8000 5 Comments

When building NServiceBus services based on the generic host, you may need to do some stuff whenever your service starts up and shuts down. The way to do that is to create classes that implement IWantToRunAtStartup, which will be picked up by the host and registered in the container as an implementation of that interface.

When the time comes to run whoever wants to run at startup, the host does a

to get all the relevant instances (or something similar if you aren’t using Windsor…).

If, however, one or more instances cannot be instantiated due to missing dependencies, you will get no kind of warning or error whatsoever! [1. At least this is the case when using Castle Windsor – I don’t know if this is also the behavior of other IoC containers… Maybe someone can clarify this…?] This means that the service will silently ignore the fact that one or more IWantToRunAtStartups could not be instantiated and run.

In order to avoid this error, I have written a test that looks somewhat like this:

I admit that the code is kind of clunky even though I distilled the interesting parts from some of the plumbing in our real test… moreover, our real test is iterating through all the possible configurations our container can have – one for each environment – so you can probably imagine that it’s not pretty 🙂

But who cares??? The test has proven almost infinitely useful already! Whenever something that wants to run at startup cannot run at startup, TeamCity gives us error messages like this: