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 want some pointer as I am just started looking into different ESB products and what they are able to do or not.

Verner

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.

Phycomycete

I fundamentally disagree. To say there are brokers and ESBs is not only grossly oversimplified, but it's also incorrect. A service bus provides platform and transport neutral mediated connections between services and consumers. An enterprise service bus does so in an enterprise-grade manner. – Stylize

One example that fits your definition of the service bus very well is ethernet. However, I don't see how you could deploy ethernet on a single central server (broker) and get all the other services communicating, without first deploying ethernet locally on every server connected to the system. – Phycomycete

I do agree about the difference between a simple service bus and an enterprise service bus. The qualities that make a bus an ESB are exacly what you said in your update. However, a bus will always be distributed, never cetralised. A bus is an anti-broker. – Phycomycete

I can completely see where you are coming from and I agree that having a centralised point where all messages pass through and subscriptions etc are managed is a bad idea. However, many broker models support high availability which means they are distributed in a certain sense. It's just that as you say, the bus has a centralised manifestation rather than a distributed one. I much prefer the non-broker model, I just don't see that it invalidates a product from being used as a bus. – Stylize

distributed != highly available – Phycomycete

Distributed in this context mostly means partitioned, which doesn't say anything about availability. – Phycomycete

Point taken. Removed downvote and added upvote. Federated is a much better word and is what I meant by "distributed in a certain sense" – Stylize

Having an enterprise support does not make NSB an ESB. It still does not help me implementing an EAI solution to connect my services. There are more to EAI than messaging: routing, translation/transformation/conversion, policies, rules. Products like Mule, Tibco, OpenESB for instance, come with a lot of ootb adapters, rules, and orchestration tools that specifically make life easier in a wide range of EAI scenarios (SAP, Siebel, WS-*, SFTP). So until NSB offers these integration features, it's hard to think of it within EAI context. – Shaum

@Shaum - I'm not sure how I'd use NSB for integration scenarios either. The bus, in this case, is a much lower level component that is used for faring messages and processing them. It's natively distributed, which goes against the usual broker architecture. Looking at en.wikipedia.org/wiki/Enterprise_application_integration - the EAI system acts as the go-between or broker between multiple applications. EAI uses a broker to communicate using different technologies. A bus can be one of those technologies and definitely is not a replacement for a EAI broker. – Phycomycete

I believe that a bus architecture implies distributed deployment of infrastructure and logic. Broker architectural style centralises the infrastructure and logic. It's more about being centralised or decentralised, and an architectural style, rather than a particular product or name. – Phycomycete

I don't think the distinction between bus and broker is relevant to whether NSB is an ESB. Bus and borker don't need to be one or the other: it's common to have both. Most ESB implementations typically (but not necessarily) use message-brokers (e.g. AMQP) either as its transport layer, and/or as one of the integration endpoints. – Shaum

Perhaps you were referring to integration-broker, which is indeed very similar to ESB. According to wikipedia (en.wikipedia.org/wiki/…), an ESB allows its functions to be broken into its constituent parts, and deployed separately. In practice though, this distinction may mean very little (many integration brokers, e.g. IBM's WIMB, has been rebranded to ESB: WESB). Note that IBM acquired the inventor of ESB: Candle's Roma. At any rate, none of these is relevant to NSB, which isn't really an integration software, one way or the other. – Shaum

Probably there are different definitions of the term ESB (as for every term in computer science and related subjects), but this quote from Udi Dahan's blog (the author of NServiceBus) and the fact that he tags his blog posts with ESB suggests that he considers NServiceBus as an ESB: "NServiceBus was chosen as the ESB for one of our core insurance systems" (udidahan.com/2012/03/30/nservicebus-in-insurance-testimonial) – Lamp

Answer 2

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.

Shaum

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.

Anchylose

Answer 4

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.

Christ

Yes, Biztalk is closer to an ESB than NServiceBus is. Biztalk is very much a relevant tool in the context of software integration. NServiceBus on the other hand is not designed/intended to be an integration middleware in any way, e.g. the first point is a very important one in any integration tool (Protocol Bridging, Data Format/Model transformation) – Shaum

NServiceBus solves a different set of problems - eg. decentralization. Protocol bridging, Model transformation and Data Format are left for the User to handle. – Christ

Answer 5

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.

Stylize