The Enterprise Service Bus (ESB) is a term coined a few years ago by industry leaders to describe a new type of middleware, one characterized by a focus on services and Service Oriented Architecture (SOA). Even before this term emerged I had been working on XML Web Services and integration at the IBM Hursley laboratory, the home of the MQSeries product (now renamed WebSphere MQ). I have spoken to many customers who were in the early days of integrating J2EE with other systems including mainframes, Windows, Web, SCADA, control systems and others. One of the strong themes that I had heard again and again was that leading customers incuding major banks, insurance companies, and telcos were moving from opaque data formats to well-defined XML messages with uniform schema. Effectively the move was from binary and delimited formats such as CSV to structured and standardized data interactions. Another way to look at this was as a move from message-oriented to service-oriented.
By pushing a common format throughout the enterprise and making endpoints deal with that format, architecture forced three key outcomes:
This model is what we now call SOA although, the term was just emerging at the time. The idea of a uniform communications system with every party talking in a common format where anyone could connect to anyone else – well of course that is a “bus”.
Since then many companies have offered a category of products known as an Enterprise Service Bus. In fact, my company – WSO2 – does as well. But the definition and vision of an ESB has moved away from its earlier vision. The vision now seen as an “ESB” involves a centralized integration platform. For a simple example, let’s look at how the Java JBI model is commonly used. This model is promoted as a Java standard for ESBs. In JBI, what is the “bus”? Effectively the bus is a virtual construct within the Java runtime called the normalized message router. So the commonality happens inside the JVM while on the network, the interactions remain in their existing formats. Adapters known as binding components transform from legacy formats and protocols into a common format.
So what is different between this model and the model I discussed before? Fundamentally, the difference is that the conversion from internal formats and models to the common uniform model happens in the center – in the “ESB” – and is not owned by the application owners. This is actually an Anti-SOA pattern. The single most important aspect of SOA is ownership. The point of a service provider – in real life as well as IT – is that they take full ownership of the problem domain. When I get into a taxi in London or New York, I have a base expectation that the taxi driver speaks English and knows how to get where I want to go. If I have to step into a taxi with a phrase book and map and manage my own route then the Taxi service isn’t offering me a properly encapsulated service. Likewise, if I have to send COBOL fixed format messages to a CICS Mainframe using a special gateway that talks SNA, then that is not a cleanly encapsulated service since the use of the service has pushed me to install, configure, manage and understand software and mappings that really are hidden away at the mainframe. Providing a centralized broker that encourages users to keep their existing middleware and protocols definitely makes life easy, but it doesn’t help foster the right ownership and encapsulation that is the point of SOA. Instead it forces a central ESB team to understand and deal with every different application, format and protocol in the enterprise.
Well, if you think back a few years, you will remember that when the SOA and ESB terms were first launched the predominant integration product was the Enterprise Application Integration (EAI) hub. The vendors of those products were – for the most part – caught on the hop. Gartner and other industry analysts started telling the marketplace that an ESB was an essential integration middleware but they didn’t have an ESB to sell. So they quickly added some XML and Web service adapters into their EAI hub and branded that as an ESB. As a result the market has swayed extraordinarily by a set of products that encourage centralized integration. Think of Web services as lipstick and the EAI hub as a nice little porker.
If you look at the original picture of an ESB, it’s not even clear that you need any “ESB” product to implement it. In that story, the ESB was a virtual construct made up of the various applications communicating via a uniform set of protocols and schemas. In fact this is exactly the approach supported by the REST model.
If that’s the case, why have I created a product called the WSO2 ESB? Because I still think there is a place for some runtime infrastructure that supports your SOA.
Here is my simple list of facilities in an ESB runtime that encourage SOA:
Message routing and distribution. The applications shouldn’t have to have hard-coded destinations for messages or services. The ESB can help in two ways – by supporting virtualization (mapping logical destinations to real destinations) – and by supporting event architectures, where the publisher doesn’t need to know about the subscribers.
It’s worth noting that all these features can be handled in a distributed fashion as well as a centralized one – there is nothing inherently hub-like in this model, and that is a key attribute in deciding whether your approach is foster SOA or inhibiting it.
There is one more component that is essential to promote “real” SOA, and that is a Registry and Repository. This is the only aspect that I think can be centralized – though a proper solution should support federation and distribution. If SOA is about encouraging ownership of services and re-use, then it follows that the rest of the enterprise needs to be able to find those services and use them. A well-structured catalogue of services, schemas, requirements and capabilities is absolutely essential to enabling application owners to offer clearly defined and open interfaces.
As a last word, I’d like to point out that many of the ESBs out there can support this approach to SOA and believe that the makers of those ESBs will be happy to point that out. And even JBI, a point that I've picked on earlier, can be deployed in this model. On the other hand there are some ESBs, that of course include the ESBs that I work on (Apache Synapse and WSO2 ESB) that are designed from ground up with this perspective. The fundamental architecture and design is based around the simple idea of a true SOA – one in which the owners of services take responsibility for offering a clean, simple and universally accessible interface to their services.
It is time to reclaim the idea of an ESB to what it should be, a distributed network of services which are universally accessible using standard protocols and well defined interfaces.
Co-founder and vice president of technical sales at WSO2, Paul Fremantle was a Senior Technical Staff Member at IBM for 9 years. At IBM, Paul created the Web Services Gateway, and led the team that developed and shipped it as part of the WebSphere Application Server.
Paul Fremantle, paul at wso2.com