Enterprise Service Bus, .NET Service Bus, NServiceBus and the wheels on the bus

Question

Enterprise Service Bus (ESB), .NET Service Bus (Windows Azure AppFabric Service Bus), NServiceBus, RhinoServiceBus, MassTransit and so on.

I'm trying to understand what each of these technologies have in common or not in common.

I attended Juval Löwy's presentation on the .NET Service Bus earlier today and he stated that the .NET Service Bus could be used as a poor man's version of an ESB, so I would take that to mean that the .NET Service Bus is NOT an ESB, are any of the others a true ESB?

If any of the others are a true ESB what would make them a true ESB as opposed to the .NET Service Bus?

Answer 1

I agree with the other poster: ESB is a bit like SOA, a general definition that is used mostly as a marketing selling point than as a strict standard you must satisfy.

From Wikipedia:

Commentators disagree over whether to define an Enterprise Service Bus (ESB) as an architectural style, a software product, or a group of software products. While use of an ESB certainly implies adherence to a particular architecture, the term “enterprise service bus” almost always denotes the software infrastructure that enables such an architecture, and in essence, the ESB is considered a platform to realize a service-oriented architecture.

An ESB brings flow-related concepts such as transformation and routing to a Service-Oriented Architecture. An ESB can also provide an abstraction for endpoints.

ESB as a term seems to have been coined by Dave Chappel, who is (was?) technical evangelist for Sonic Software (and author "Enterprise Service Bus" - O’Reilly: June 2004, ISBN 0-596-00675-6). I have read the book and have attended a couple of seminars by Chappell, and I am afraid that the book itself is not much of help in helping you decide if Product X is a "true" ESB.

In general you should look for something message based (this was the original intent, apparently, even if some other companies, like webMethods, use the term for their product, which is more webservices-oriented).

The idea is to have all the "services" in your IT infrastructure being able to receive and send messages to each other. The ESB provides the routing, and has interface endpoints so that if your original application worked - for example - by invoking a JSP page via HTTP post, you have a small program that can receive a message, use its payload to post it via HTTP, interpret the result and build a message response with these.

Basically, imagine that instead of using webservices for everything, you use message queues, building routing stations, and interface between message queues and other systems. This is an ESB.

---

This is lengthy, but instructive: https://gist.github.com/chitchcock/1281611

(an article by Steve Yegge about how Amazon moved to an "API for everything" policy).

Answer 2

I think you need to understand that ESB is more of a marketing term than a technical term. Many vendors are presenting technologies under that banner.

The thing to look at is the Bus Architectural Style, in which event sources and sinks collaborate. NServiceBus, RhinoServiceBus, and MassTransit have the concept of publishing and subscribing to events built in - the .NET Service Bus does not.

The differences between the above three are more in form than in function - stability, documentation, community, etc.

Hope that helps.