I'm beginning to think we need another word after "Enterprise Service Bus" (ESB). The problem is that some people think that an ESB is a product — evidently they believe you go and buy one and then you are all set. Your friend down the street also buys one and you both have the same thing. This is wrong. An ESB is not like a simple consumer item where two people can buy the same model and it fully meets all of their individual requirements.

	express delivery
	• print  • comment
	An ESB is something you build for your enterprise or organization to give you the connection architecture you need to meet your IT and business goals. Dr Bob Sutor is director of WebSphere Foundation Software at IBM. This is an abridged version of an entry originally published in Bob's weblog.
	Glossary terms: ESB, endpoint, lookup tool Sponsored links: your text link here

An ESB is something you build for your enterprise or organization to give you the connection architecture you need to meet your IT and business goals. It can be built incrementally from multiple products and it needs to support the performance, reliability, and range of protocols that real, non-toy infrastructures require. If you have enterprise messaging products in place now or are about to install them, you have an ESB and a strong basis for future expansion and use of developing standards. To put it bluntly in IBM terms: if you use WebSphere MQ and other WebSphere brokers or integration servers, you have an ESB today.

Here's an analogy: our house was built in 1820, well before houses were wired for electricity. There wasn't much in the way of indoor plumbing in those days either, but that's another story. When it first became viable to wire houses, it was done with relatively primitive technology. The life of the wires was supposed to expire sometime in the 1930s. In our previous house I was replacing this old kind of wiring with the new style well into the 1990s. I'm sure some of it is still there, but we moved, so it's not my problem any more.

Over time, people upgraded the wiring. In theory, when new electrical codes come in (think new standards), everyone is supposed to rush right out and replace all the old stuff so the house doesn't burn down. In practice, this is done incrementally. In the meanwhile, the electrical system keeps working.

So although I've used a wiring example, there are a few concepts here that we can relate to IT:

• No one ever ends up with the original connectivity infrastructure that may have been planned on day one, because new requirements come along [more electrical appliances and the resulting need for additional or upgraded wiring].
• Scalability is very important: you need an infrastructure that can handle the necessary throughput without starving critical business applications the connectivity they need. [You don’t want your freezer to not work properly because you overloaded a circuit.]
• The infrastructure needs to be incrementally extendable and compatible with what was previously installed. [If you add a new room to your house, you better be able to wire it.]
• You need to be able to support a wide variety of qualities of service.
• Upward compatibility for applications is important [the appliances I bought ten years ago better still work with new wiring]
• Standards are always being created and we need to be able to support the new ones and the old ones, assuming they have not been supplanted for safety reasons. The implementation of the standards has to be accomplished in an evolutionary way to be practical. [When I was young we didn’t have the GFCI safety outlets for locations outside or near a wet area like a sink or shower.]

Think of this home wiring example when you ponder ESBs. They are not a scary, futuristic topic. We and others in the industry have started to use to term in an umbrella way to systematically simplify how we talk about enterprise connectivity that includes: features for reliable message delivery, support for both new and legacy protocols and transports, data transformation, logging, high availability subject to connection requirements (that is, always connected, sometimes connected, rarely connected), and so on. We need this to support service, event, and traditional messaging infrastructure. It's easier to say "ESB" than everything else I mentioned in this paragraph.

Ideally, we could take some of the processing that originally had to take place at the endpoints and move it into the connection infrastructure (the "bus"). To use another electrical example, the ThinkPad on which I am writing this entry has a power supply that automatically switches between 110 and 220 volts, so I can use the same laptop in the US or Europe without having to remember to push a little switch on the power supply, as users of early computers had to do. That little black box that sits between the electrical outlet in the wall and the plug I stick in the ThinkPad is akin to having intelligent functionality that is on the bus versus being at an endpoint. We've been able to move those smarts away from the endpoint, thereby simplifying it.

In our IT example, if we can do data transformation on the bus, we don't have to teach all the applications or services that plug into the bus to do the transformation. This greatly simplifies the development of the applications. It also means that we can go to one or more designated places on the bus and add new transformations. Moreover, we can upgrade the physical servers on which the transformations take place in order to get better performance and thus scalability. Pretty cool, no?

IBM customers who have been using WebSphere Business Integration Message Broker (and its otherwise branded predecessors) connected to applications via WebSphere MQ have been able to do this for years. These same products have been incrementally adding support for XML and web services. IBM will continue to add features to our WebSphere products, as appropriate, to support the new standards. This means that the "bus" will support all the important things it does now, plus the new stuff as well.

More on this topic