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:
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
or learn more about publish/subscribe messaging.
Or take a look at the differences between NServiceBus and WCF, BizTalk, and WebSphere or Sonic
