What is an ESB?
I recently had a comment attached to one of my posts regarding ESB suggesting that it needed to be translated into English - so that’s what I’m going to attempt to do here. An ESB is a fairly new and complex concept, and the definition is far from fixed, so don’t be surprised if you see some disagreement. As with many things, though, it’s also a generalisation and aggregation of some other concepts that already exist, so be aware of that too.
An ESB is a fairly abstract architectural idea, but I’d best describe it as ‘a place where messages are stored, routed, modified, created, and destroyed’. It’s probably easiest to describe this with some history (so apologies if you know some of this already), and I’m going to use IBM’s products as examples, simply because they are what I know best.
Enterprise messaging has been around for some time. IBM’s classic product in this area is WebSphere MQ (formerly MQSeries). MQ runs as one or more servers, which contain queues. Messages can be placed on queues by applications (originally using MQ’s own MQI API, now using industry-standard JMS). Other applications can retrieve messages from the queues using the same APIs. This allows data to be easily moved asychronously between platforms, systems, etc. One of the key points about products such as MQ is the way that the messages are treated - typically with ACID properties similar to the way databases treat data. This means you can be confident that once a message has been sent, it will eventually reach its intended destination (or somewhere that it will be noticed). This provides a reliable base for integrating different applications (the original attraction of messaging systems like this). Originally, messages were typically in a proprietary format, but they are often now in XML with an associated Schema.
It was shortly realised that it would be useful to add some form of brokering. IBM’s product in this area is called WebSphere Message Broker. Typically, it is used to build on the capabilities of MQ. It allows you to develop (normally without programming) ‘flows’ that pick messages off queues, transform them, route them, etc., then place them back on other queues. Message Broker also allows one to work with adapters, meaning that flows can input from, or output to, things that aren’t queues. In this respect, Message Broker is essentially a generalised MQ application.
Later on, IBM released a new messaging engine, similar in some respects to MQ, as part of WebSphere Application Server (WAS). It is formally called WebSphere Platform Messaging and is part of the J2EE standard which WAS conforms to. Many other application servers also exist, with their own JMS engines, some open-source.
In recent years, web services have started to come to prominence, particularly as part of creating a Services-Oriented Architecture (SOA) for an organisation. They utilise a slightly-different, but related, model for integrating applications from that of enterprise messaging. Typically, an application makes a synchronous request over HTTP, using a message format called SOAP, to a back-end service, which does some work for it. Many services send back responses. These services typically run on application servers.
WebSphere ESB brings together many of these concepts. It contains all the functionality of WAS (including the messaging engine), but also provides ‘mediation flows’. These are similar to flows in Message Broker in that they allow one to pick up messages from JMS queues and modify them, audit them, etc., before passing them on. However, it also allows mediation of Web Services: for example, one could invoke a web service provided by ESB, which invokes another web service, and ESB then does some processing on the result before returning it to the original invoker.
So now we are in a position to define an ‘ESB’ in the generalised sense - in all these interacting systems, it comprises the messaging engines and the brokering and mediation capabilities. The applications that send and recieve messages, provide and invoke services, are those that sit outside the bus. As such, one doesn’t need any particular product to have an ESB (including WebSphere ESB). ESB is often seen as a pattern rather than a product: just a statement that the bus and the applications are distinct. You could build one with MQ and Message Broker (or even MQ alone if you didn’t want brokering capabilities). WebSphere ESB simply provides extra mediation capabilities, including the ability to mediate web services, without doing a lot of leg-work.
It’s worth clarifying that an ESB doesn’t necessarily have to have anything to do with multicast (although some ESB systems do include the notion of splitting and aggregating messages, which has some similiarities).
This is a large and complex topic, so it’s hard to do it justice in a blog post, and I’ve simplified vastly on some topics above. In particular, I haven’t really discussed any business process management. But I hope I’ve cleared some things up. If you’re interested in learning more, the following might help:
-
Chapter 2 of SOA with an Enterprise Service Bus in WebSphere Application Server V6 - descriptions of both SOA and ESB.
Alternatively, as always, please post a comment and I’ll do my best to answer it.
Comments