NServiceBus

For the past year our team has been looking high and low for a solution to deal with the challenge of sporadic heavy processing while trying to keep things simple.

We now have a stable and robust system that allows us to serve thousand of concurrent connections without any components in the chain even breaking a sweat.

Just remember one thing, nServiceBus will NOT fix your bad code - it will however run it faster, in parallel and within transactions.

nServiceBus does a great job by hiding the complexity of the management of messaging in an application : transactions, durability, reliability etc. We can think it’s simple but it’s not. What it’s easy is the setup of nServiceBus: some configuration file, writing a message handler and you are done. I like the idea that you can focus on your business as developer: writing code for your application not the infrastructure. Coming from the J2EE “world”, nServiceBus reminds me a lot JMS with annotations.

nServiceBus is used by a web application to handle registration confirmation, notifications, statistic gathering .We have a lot interactions with Twitter, Facebook or by email and be able to have messages hold on an error queue when theses external systems are down and resubmit them later without any difficulty was very attractive.

I think that there’s room for improvements for the documentation but the user group is great (even if it’s not simple to search the yahoo archive …) and you can get an answer very fast.

We started looking at how we could improve our system robustness and introduce realtime reporting without increasing load on our OLTP databases. We also had some challenges to deliver consisten performance in some sub systems regardless of the overall loading.
It took a few weeks to grok the concepts involved in messaging but our devs needed only a week to implement a pub sub solution which is testament to how straightforward nServiceBus makes the coding.
We have just started our nServiceBus journey but already are excited about what it has to offer.

I can't speak long enough about my true appreciation for this framework. We all have 'default' positions when it comes to design considerations and technology choices and NServiceBus is currently #1 for me when it comes to picking a safe, scalable way to do messaging behind the corporate firewall. If you have struggled with the (over) complexity of other messaging frameworks then I would implore you to take a lingering look at NServiceBus. Every developer that I introduce it to feels a sense of well being and calm once they start using it, not to mention the great results they have been able to achieve. The team I currently work with are achieving amazing results and saving their business lot's of money ; needless to say they are popular in the office.

NServicebus framework was embedded in several conduit.com subsystems.
The framework proved itself as a reliable and robust infrastructure for our runtime load-intensive production distributed environment.
NServicebus is straightforward to use, easy to configure and adapt for specific needs and contains great features (Saga, Distributer and more) that are very useful and powerful.

Misha Haron
Software Engineer
Conduit.com

I've built an rpc-like communication layer that translates method calls to messages.
The messages are sent using nServiceBus over MSMQ transport because the one-way/disconnected nature of it fits me better than remoting or sockets.
The reason I don't use MSMQ directly is because I need to support clients that wish to work using different transports (e.g. rendezvous) and the abstraction that nServiceBus uses (ITransport) fits great.
I could've used WCF but the callback mechanism there is cumbersome and it only works on OS > WinXP and we still use W2K.