Almost a year ago I wrote a post called Why I Love CQRS. Little did I realize how far that post would go. It ranks # 1 in Google for the term CQRS and # 2 in Bing. Since that same time I have been wanting to post my thoughts on NServiceBus…and here they are:
From the Mind of Udi Dahan
For anyone that has had the privilege of listening to Udi Dahan it becomes immediately apparent that he knows what he's talking about. I had the opportunity to attend his week-long course on Advanced Distributed System Design with SOA & DDD. If you are deciding where to spend your training budget, this is the one. It beats any technical or programmer conference hands down. I had the opportunity to eat breakfast with Udi every morning that week. It wasn't a planned event, it just kinda happened. We both showed up to breakfast at the hotel at the same time each morning.
From the face time that you have with Udi, you can literally see and feel the breadth and wealth of knowledge being brought to bear on the problems and issues at hand. Further, the methodical way in which he discusses, understands, and then helps bring out the solution show that these are definitely not the quick-fix, aspirin and band-aid solutions. They are real, fundamental solutions that cut straight to the heart of the problem and treat it at the root rather than the traditional hacking at the leaves that you find by throwing technology at the problem, e.g. "just add caching", etc.
NServiceBus was designed around the fallacies of distributed computing and faces each fallacies head-on rather than trying to sweep the them under the rug and hide from them while pretending that they don't exist. It is only by acknowledging and addressing these fallacies that our systems become truly and effectively distributed. This is one the foundational principle of NServiceBus. It's not just about plugging in the WCF MSMQ binding and somehow magically request/response will bring scalability.
In a nutshell, all of the learning and hard lessons discovered through the school of hard knocks and best thinking of distributed systems (rather than whimsical, so-called vendor best practices) are baked into the heart and core of NServiceBus.
vs. Web Services
This one almost doesn't deserve the effort it takes to type. Once you take the "red pill" you'll never see the world the same again. For me, it was going to Udi's class. Previous to going to his class I had already done a decade of web services using SOAP and REST and I kept running into the same types of problems over and over again. I've read all of the best practices of the vendors and so forth, but the thing that always bugged me was how everything related to these "best practices" (if it's even appropriate to call them that), always pointed us back to purchasing more licenses—such as database licenses, OS licenses, etc. If you want an eye opener and sample of what Udi brings to the table, take a look at his Reliability, Availability, and Scalability webcast. The biggest problem with with web services is that they run afoul of practically all of the fallacies.
So where do web services fit in? As integration points with 3rd parties that connect across the web. They've worked great in that arena and will continue to work well into the foreseeable future. Furthermore, a "web service" AJAX call from a browser into a service may also be appropriate.
vs. WCF
Essentially WCF is just a way of wrapping all of Microsoft's myriad of integration and communication technologies under one API. The problem is that all of these technologies, with the exception of MSMQ, were built upon the paradigm of RPC—remote procedure call. Essentially, it's all about blocking communication. Could you imagine a world in which you called someone on the phone and waited on hold until you received the information you needed? RPC is just like that. Your servers are at 0% CPU, but you have no threads left to serve because they're all blocked waiting for remote services to respond. The MSMQ binding helps, but not if you use it in a synchronous blocking manner with an RPC-type interaction.
vs. Microsoft BizTalk
This one is almost the same as web services, except that we're headed in the right direction. Now, at least we're headed down the road toward messaging. The only problem is that all of our business logic is centralized. But wait, I thought we wanted to centralize business logic, right? Wrong. Yes, we do want to centralize our business logic, but we want to do it at the "business service" level, rather than at an infrastructure and technical level. Furthermore, a broker is NOT a bus. A broker is a single point of failure and a bottleneck in your system. If you are using it as an integration point between multiple business services then that's bad. Despite Microsoft's attempts to rebrand BizTalk as a "bus", it definitely ain't. It's based upon a fundamentally different paradigm. Don't be fooled into purchasing more licenses than are absolutely necessary.
On the other hand, that's not to say that you can't leverage BizTalk if you already have already forked out the cash for licenses. Udi has an excellent article about how to leverage BizTalk.
vs. MassTransit & Rhino Service Bus
Let me first start off by saying that I am exceedingly glad that these two buses have appeared on the scene. Dru Sellers, Chris Patterson, and Oren Eini have made significant contributions to the open source community and as a result of their efforts everyone has benefited. In fact, when I first started doing publish/subscribe, I went with MassTransit because the API was clear, concise, and code-driven. NServiceBus, which was still in the 1.x phase had XML-driven wire-up (ugh!) and was still heavily leveraging Spring.NET to do injection. As a result of MassTransit, the interface and "host" environment used by NSB have been significantly enhanced and the .NET community in general has a better understanding of messaging.
Okay, now the complaints. To be honest, I don't have anything to complain about. We currently have a few places that actually use MassTransit in production and I have been extremely pleased with how those places have been performing and behaving. At the same time, MassTransit was started as a project to help its authors learn messaging. Dru and Chris have said this multiple times. Effectively, it's been a learning experience for them. I'm going to be the first one to say that every time I have written a piece of software I have learned a lot by writing the software. The key point that I'm trying to drive home is that NSB came about because there was a very specific need that Udi had with his clients and he was able to fill the void after waiting (and waiting and waiting) for Microsoft to release something in the publish/subscribe space. In contrast Dru and Chris, who also had a need, created their implementation as a work-in-progress to learn about messaging.
Despite all of this, I am also going to be the first to say that even if you do choose MassTransit, you're making a smart move as compared to all of the other options that I have previously mentioned.
One other aspect of this deserves some attention, and that is community. And this is where NServiceBus really starts to shine. In the .NET world, there are pretty much these three implementations. Java has a few and I'm not sure what exists on the dynamic language side of the fence. But in .NET land, NServiceBus takes the cake with regards to an active community. It has loads of documentation and a thriving Yahoo Group. There is talk of creating a tiered license structure for NSB to make it a for-pay option to those companies that demand support contracts while still making it free for others. This is a significant step forward in the maturity of an open source library and virtually guarantees the viability of the library beyond Udi. Effectively the library is now "bigger" than he is—and he's a tall guy.
Pluggability
One other key pieces of the puzzle is the pluggability of NServiceBus. In almost any way possible you can adapt it to work around your infrastructure requirements. For example, you can plug in your own message queuing infrastructure if MSMQ isn't working for you or you decide that ActiveMQ, etc. is a better fit for your organization. If you need a different serializer, just plug it in. If you need to use something else besides a relational database for your subscription storage or your saga storage, just plug it in.
Conclusion
NServiceBus has as its foundation the fallacies of distributed computing and the understanding of Udi Dahan. At one point it could have been considered a simple and fun, single-developer project. But no longer. It has long since crossed the chasm that threatens obsolesce and deprecation, the chasm which few open source libraries ever cross. It has now become a serious application framework. By letting NServiceBus guide your application development toward proven concepts, such as publish/subscribe, it has the ability to revolutionize your development methodologies within your organization and drastically reduce costs associated with active development, integration, and maintenance of your enterprise systems.