NServiceBus - Makes Building Enterprise .NET Systems Easier

NServiceBus is an open source communications framework that will help guide developers who are trying to build enterprise .NET systems, without falling into many of the typical pitfalls.  It provides scalability critical features like publish/subscribe support, integrated long-running workflow and deep extensibility.  According to its creator, this makes an ideal foundation for building distributed application.

NServiceBus was first released in January 2006 and was deployed in a large-scale distributed system in March of 2006.  InfoQ had the opportunity to speak with Udi Dahan, creator of NServiceBus.    

The reason for its creation:

There were two major forces that drove me to write NServiceBus. First of all I wanted to formalize the way Service Layer classes were written when using asynchronous messaging (regardless of Web Services). And second I wanted to formalize a communications API which supported publish/subscribe semantics so that I could freely move between transports – whether they inherently supported publish/subscribe or not.  It was also very important to me to not use a centralized broker, otherwise I couldn't have supported the high levels of scalability needed.  Finally, I made the step of formalizing the way long-running workflows and orchestrations connects to asynchronous messaging.

For any developer who architects using SOA principles, on the basis for using NServiceBus over some other methodology or some other so-called enterprise service bus:

NServiceBus makes it difficult to work in ways that will hurt your scalability. Since the asynchronous messaging patterns are brought to the fore, developers will, by default, avoid the temporal coupling so prevalent in most Web Service implementations. Other methodologies make so many other options just as easy to use that developers can make mistakes that will hurt their scalability and availability and only find out about those mistakes in production .

Another thing NServiceBus does differently is to totally isolate all workflow code from all technologies. This makes it easy to unit-test workflow classes, making it possible to iterate quickly on the development of key business processes. These portable .NET POJOs give developers the flexibility to host their workflows in whatever runtime they want.

Having noticed NServiceBus is built with MSMQ in mind or as an option, when asked why this choice of direction:

The core of NServiceBus is not dependent on MSMQ. The extensibility points of NServiceBus allow you to plug in your own communication transport, subscription storage, and workflow persister. I've already implemented a transport over MSMQ, and another over WCF's NetTCP binding. Developers can use those as-is or write their own. Many of the SOA products currently out there are much more tied to HTTP, so this is something of a break from the common practice.

I chose to use MSMQ since it is one of the two main Microsoft communications technologies that enables parties to communicate in a disconnected fashion (SQL Server Service Broker is the other). MSMQ has a much more accessible API in that it is directly available as a part of the .NET Framework whereas Service Broker currently isn't. I consider disconnected communications a critical part of any SOA infrastructure since the Tenet of Service Autonomy does not allow us to assume that the service with which we wish to communicate is currently available.

NServiceBus is an open source product licensed under the Creative Commons Attribution 3.0 License .  IT is packaged as a set of .NET assemblies which can be hosted in any application or clients licensed.

Since the interview was brief, we asked Udi what information he would like to pass on to readers who were not very familiar with service-oriented  architecture (SOA) or wanted to learn more about implementing SOA: 

If you're getting involved in developing service-type applications and aren't familiar with SOA you need to understand that it is significantly different from what you've done so far. You do not just slap some attributes on the same kind of code you've always written. Before getting bogged down in the specific technology you're using, take the time to understand the higher level messaging patterns services employ - they can save you from a serious rewrite.

Udi was recently interviewed on DotNetRocks about all things SOA including some discussion about NServiceBus.  You can learn more about Udi at his blog.