Is NServiceBus an ESB at all

Question

Is NServiceBus a ESB or lightweight ESB at all? or is it more like WCF with durable/ reliable messaging? It looks to me more like a messaging framework than ESB.

just wa

Answer 1

NServiceBus is definitely an ESB. Full Stop.

Enterprise Service Bus, a Bus, meaning a thing that allows, by design, for components of a system to be distributed and work independently. The bus itself is also distributed. A failure of one component or service doesn't affect the availability of other components connected to the bus.

The opposite of a bus is a broker. A broker presents a single point of failure in a system. Things like MS BizTalk are brokers, not ESB.

UPDATE
Just to elaborate a bit on the enterprise support in NSB
- supported messaging patterns are one-way fire and forget (durable and express), correlated request-response, publish-subscribe. Everything else can be built on top of that.
- transactional message processing and automatic retries
- load balancing with a distrubutor
- configurable auditing and monitoring with performance counters
- built-in long running process management
the list goes on ... making NServiceBus an ESB

Some message broker products can be deployed in a 'federated mode', which makes those deployments decentralised. The decentralised deployment type aligns well with the bus architecture style. So, I guess, it depends. However, a centralised deployment is just an enterprise service broker, not a bus.

Answer 2

Your question is a little open ended. It would probably be better to outline what features you require from an ESB and then ask if NSB supports them.

UPDATE

I feed I ought to update my answer in response to Chris's answer.

Although convenient, it's erroneous and unhelpful to create two categories, Bus and Broker, such as Chris argues.

A service bus provides transport and platform neutral, mediated connectivity between services and their consumers. Under this definition, products which use the message broker model can also be used as a service bus.

An enterprise service bus provides this connectivity but can also add enterprise-grade mediation such as:

• Built in support for message exchange patterns
• Centralised monitoring
• Service load balancing and instancing
• Automated failure and exception management
• Service metadata discoverability
• Retry on failure
• ...and many more

I think therefore when you are choosing a tool set you should first of all decide which kinds of features you require and then you can choose the product which most fits your needs.

Answer 3

Well I think nServicebus is certainly a ServiceBus, not sure you can call it an "Enterprise" ServiceBus without spending hundreds of thousands on it. Seriously though, you need to think through whether you really want an ESB or not. Most of them promise a wealth of riches, but deliver a lot of overhead, and it can be very difficult to realize the value. I have used WSO2 in a big enterprise, where it was one of our 3 ESB's. Very enterprisey, run by the OPs team, and a real pain because we had to deal with another team to set up and run our system. Other issues include the so called features like message routing or message translation. Sure the product can do those things but it takes you out of your development environment and gives you more pieces to worry about. Code and or configuration get spread into more places, more things to manage more things that can go wrong. That’s something I do like about nServiceBus it is very accessible to the developer. Another implementation I like is the Azure ServiceBus. Obviously it is not as full featured and it’s probably not what you are looking for, but I love the Developer accessibility and self-service nature, and those are traits I would be looking at.

Answer 4

No, I would not think of NServiceBus as an ESB product, nor is it categorically an EAI tool in general.

If we're to find a comparison with other tools out there, NServiceBus is closer to the like of JMS api (e.g. spring-jms) and AMQP. It's a framework to help you with interacting with message-queues and implementing common messaging patterns within your application (e.g. pub/sub, request/reply, dead-lettering, "saga") using a friendly programming syntax.

Whereas an ESB product as traditionally known within the EAI industry, is a platform that facilitates the integration of many heterogeneous applications in an enterprise environment. Although different ESB products offer different features, they all share certain features in common that make them useful, the main ones being their wide range collection of connectors to various open and proprietary protocols and services (including message-queues, but also other things e.g. WS-*, sftp, SAP, Siebel, rdbms, xmpp, websockets/comet, corba, edi), and a full set of ready-to-use implementations of Enterprise Integration Patterns (as per the black book) so you don't have to reimplement them yourself in order to orchestrate complex integration logic such as transformations, conversions, routing, prioritization, business-rules, policy enforcement, validations, duplicate detection, ETL, and generally moving data around between applications.

NServiceBus provides no feature that's remotely related to performing any integration work, nor is it ever designed for that. It's something you'd use to implement messaging patterns within your application, but won't be something you'd pick up for an EAI project.

Answer 5

Enterprise service bus is a compound SOA pattern. If you look into Thomas Earl's books here are the patterns that ESB includes

1. Broker (Protocol Bridging, Data Format and Data Model Transformation)
2. Intermediate Routing
3. Asynchronous Queuing
4. Reliable messing
5. Event Driven
6. Policy Centralization
7. Rules Centralization

NServiceBus to my knowledge (limited) does apply some of these patterns - rest (ex: Rules Centralization and Policy Centralization) are expected to be implemented by the user. By this definition, BizTalk is also an ESB.

An important thing to keep in mind, is that by using NServiceBus or Biztalk or anything else does not make you SOA. In fact, if not used properly, you might find yourself tied to a vendor, defeating the first principal of SOA - Vendor neutrality.