Contents

• Getting Started
•     Overview
•     Architectural Principles
•     Transactions

• Samples
•     Web App Integration
•     Web App - Asp.Net Mvc3 Integration
•     Encryption
•     Full Duplex - Request/Response
•     Generic Host - Logging
•     PubSub
•     Versioning
•     Message Mutators
•     Unobtrusive
•     Data Bus
•     Scale Out

• Day to Day
•     Dependency Injection
•     Support for child containers
•     Logging
•     Messages as Interfaces
•     Introducing IEvent and ICommand
•     Unobtrusive mode messages
•     Unit Testing
•     One way/Send only endpoints

• Hosting
•     In Your Process
•     NServiceBus Host
•         Profiles
•     32-bit (x86) Host Process

• Management and Monitoring
•     Auditing
•     Monitoring
•     Msmq Information

• Scaling Out
•     Performance Information
•     Multi-Site with the Gateway
•         More about the Gateway
•     Multi-Server with the Distributor
•     Unit of work in NServiceBus 3.0
•         Unit Of Work implementation for RavenDB

• Publish-Subscribe
•     Overview
•     API and Configuration

• Long-Running Processes
•     Sagas

• Customization
•     Customizing Configuration

Overview

Designed for collaboration between business-oriented services,
NServiceBus is not a replacement for RPC technologies like WCF.

Successful SOA and DDD projects use a mix of approaches
and technologies - not just NServiceBus for communications.

Here you'll find the similarities and differences
between NServiceBus and its Microsoft counterparts.

Closer to WCF than to BizTalk

When many people hear the term "service bus" they picture a central box which all communication goes through, like BizTalk. That's actually a description of the Broker architectural style, not the Bus architectural style. A bus isn't necessarily a physical entity. In that respect, NServiceBus is more similar to WCF than it is to BizTalk.

There is no physical WCF one can point to in the network topology. WCF is part of the infrastructure that is run in-process with a given application's code. NServiceBus is the same.

Just like you can write your own host process and activate WCF explicitly within it, you can do the same thing with NServiceBus. The bus in NServiceBus is something virtual - the collection of framework objects running in the various applicative processes. You can think of it as a kind of peer-to-peer mesh that runs alongside your code as illustrated in the following diagram:

While there are additional stand-alone processes that come with NServiceBus (distributor, timeout manager, proxy, and gateway), they don't change this deployment model.

Similarities - the next generation

The similarities between the platforms continues into their next versions. The coming Windows Server "Dublin" technologies found in .net 4.0 bring a standard host for WCF/WF applications, message forwarding services, and scaling out stateful workflow applications. While version 1.9 of NServiceBus already provided scaling out long-running business processes, version 2.0 comes with a standard host also with the ability to run as a windows service, console, and forms application. In 1.9, the NServiceBus Proxy supported request/response message forwarding and in 2.0 will be able to forward publish/subscribe messaging as well.

What's the difference?

The principles which make NServiceBus as robust as it is are decades old. Proven to hold up through countless technological shifts, the queued messaging on which NServiceBus is based is more than just an implementation choice, it's a primary architectural concept. There's no such thing as a blocking call in NServiceBus.

As a general purpose communications technology, WCF does not enforce the queued messaging paradigm - NServiceBus does, and the architectural implications are profound.

When developing systems according to the traditional RPC techniques that WCF supports, it simple and straight-forward to get something working. That's when the problems start. Scalability and fault-tolerance are inherently hindered by RPC principles. At that point, it is close to impossible to solve these problems and even throwing more hardware at it has little effect. While WCF doesn't force developers down this path, it doesn't prevent them from doing so either. NServiceBus directs you away from these problems right from the beginning.

Scalability with One-Way Messaging

In this presentation, Udi Dahan explains the relationship between reliability, availability, and scalability and why architects should first focus on reliability.

After all, a highly available and scalable service that produces unreliable results isn't very valuable.

Throughout the presentation, the value of queued messaging is underlined and the way it handles various failure scenarios is discussed.

Although the recording missed the first 5-10 minutes, the core message has not been lost.

Adoption and climbing the learning curve

While it does take some getting used to, code written using NServiceBus is quite a bit simpler and shorter than before, not to mention much easier to unit test. An architect in the financial services domain had this to say:

"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."
-- Charlie Barker

Next Steps

Go download NServiceBus...

or learn more about publish/subscribe messaging.

Or take a look at the differences between NServiceBus and WCF, BizTalk, and WebSphere or Sonic