Let's leave alone the point-to-point and the hub-and-spoke architectures, since it is rather easy to understand them and you have been doing them in one way or another. But when we discuss about ESB and message bus, we need to understand the similarities and differences between these two topologies.
Let us first see how the message bus and the service bus are alike. In fact, both of them are aimed to solve the problem of integration and provide a common communication infrastructure, which acts as a platform-neutral and language-neutral adapter between applications. So mediation is the prime functionality provided by both the architectures. Applications can integrate each other in a loosely coupled manner through this mediator, so that they will not be dependent on each other's interfaces. Last but not the least, using either the message bus or the service bus architecture, you can implement SOA-based integration solutions!
The last statement might be hard to digest—at least some of you might have thought that one is purely SOA-based while the other is not. But the fact is that both the message bus and the service bus helps enterprises to attain an SOA ecosystem, if architected properly, but neither of them by itself will automatically transfer existing non-SOA architecture into SOA-based architecture.
Now, what is the difference between a message bus and a service bus?
Before we dig into the differences let me give you a word of caution. Even though the main differences between a message bus and a service bus will be listed as follows, they may not be very obvious in the first read. Hence, I recommend the reader to go through the subsequent chapters and samples too, and get a feel of how we do things in the "ESB way", and then revisit the given differences.
Note
The main difference between enterprise message bus and enterprise service bus architecture is in the manner in which the consumer or the client application interact with the messaging middleware.
More easily said, than understood! OK, let us worry less (I didn't say "let us worry not"!), understand more.
Service description and service discovery are two key elements to attain higher levels of SOA maturity. Only if something is described, can it be discovered. This is where a service registry is going to add value, there you can register a service description so that some other interested party can discover it.
Let us now come back to our message bus. We earlier saw that message bus applications interact with each other with the help of request-response queues. If you have ever worked in any messaging solution (like JMS) before, then you will appreciate the fact that queues are addressed by themselves, which will not give you any further information about the underlying service. Information on the operations available, or the messaging patterns to expect, or the schema for the types exchanged is never available at the queue-level. In other words, services are not described in a message bus.
What is available is just the messaging counterparts for the put and get primitives so that messages can be sent to and received from the message bus. So consumer or client applications should have pre-awareness of the format of the messages exchanged. This implies everything has to be known before hand—rather, static binding or compile-time binding becomes the norm.
Let us now consider the service bus. We said earlier that many ESB solutions are based on WSDL technologies, and they use XML formats for message translation and transformation. This by itself gives us lot of opportunities for service description and discovery. All the (minimum) details about the service will be available from the WSDL. Hence, message exchange patterns and message formats are readily available. Moreover, the consumer or client applications can discover a matching service from the ESB, given a set of messaging capabilities (WSDL capabilities) they are looking for. I used the term matching service because in an ideal ESB architecture the consumer is looking for capabilities which match their abstract service expectations (interface). It is the role of the ESB to route the requests to any concrete service implementation behind the bus which matches the requested interface.
The next big difference is the type of approach used in each architecture. In service bus architecture we used a standard-based approach. When services are WSDL-based, it brings a time tested and well adopted industry standard to integration. This has a big pay off when compared to traditional Message Oriented Middleware (MOM), because in the message bus architecture the adapters provide connectivity using proprietary bus APIs and application APIs. So, whereas in the pre-ESB world, we have been using CORBA IDL (Interface Definition Language), or Tuxedo FML (Field Manipulation Language), or COM/DCOM Microsoft IDL, and CICS common Area (COMMAREA) as the service definition language, we now use WSDL as the interface in standard-based ESB architectures.
Having looked at a few of the similarities and differences between service bus and message bus, it is time now to look at realities which exist in the industry today. We agreed that an ESB can do lot many things, and for that matter a message bus can too. We then talked about the differences a service bus has to offer.
How mature is the technology today to address these differences? Have we started practical implementations of service bus in a big way yet? The answer to this question is neither yes nor no. The reason is that necessity runs before standards. Rather, when you agree that you need description and discovery along with other features for a service bus-based architectures, the question is, will the existing standards like Universal Description Discovery and Integration (UDDI) alone will help to achieve this? Maybe we need a simple and standard way to specify a pair of request-reply queues along with a HTTP URL (mechanism to specify HTTP URL is already available) in the WSDL itself. This way a consumer or client application can interact in the 'MOM way' through the ESB. Maybe we also need a simple and, again, a standard way to find and invoke a concrete service at the ESB, matching an abstract service interface.
These standards are evolving and are at different stages of adoption. Similar is the case of support for these capabilities across multiple vendors' solutions. Hence, the tail piece is that it is time now to gather all our experience in message bus based architectures, and leverage it to define and demonstrate service bus-based architecture. So, how do we decide that we need an ESB-based Architecture? Read on the next section and you will come to know.