I'm beginning to think we need another word after "Enterprise Service Bus." The problem is that some people think that an ESB is a product and that causes confusion. 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 is fully meets all of their individual requirements.
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 than 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 called "knob and tube." The positive and negative wires were separate, often running down different sides of the wood joists in ceilings and the studs in walls. Where you needed to affix a wire, you used a ceramic knob that was screwed or nailed to the wood. Where you needed to go through a joist or stud, you drilled a hole, put in a ceramic tube, and then ran a wire through that. Aside from not being grounded, the life of the wires was supposed to expire sometime in the 1950s. 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.
Aside from the wires, the knobs, and the tubes, there were differences in how you wired a house then versus now. For one, you were lucky if each room had a single outlet (ungrounded, of course). The types of appliances were much simpler back then, and I would wager that most of them were lights. Over time, people upgraded the wiring and added in radios, refrigerators, microwaves, and computers. You can now even use household wiring to create a home network, something no one imagined when those first knobs and tubes were put in.
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, to at least give you time to figure out if you really need to tear down that ceiling or wall to get the new wire through. In theory, you could just poke a hole and run a wire. Old houses are notorious for having obstructions that you would not have guessed were there. In the meanwhile, the electrical system keeps working. Doing it incrementally allows you to budget for the work as well.
In the process of upgrading an electrical system you should probably add more outlets (most modern houses have outlets every six feet or so), and you may need to run a new electrical service to the house to get more amperage to power all the things plugged into all those shiny new outlets. The cost can quickly add up.
With the possible exception of brand new cookie-cutter development houses, condos, or apartments, residences have different configurations of electrical wiring. You don't go to a hardware store and buy a completely preconfigured set of wires that exactly fit the new power requirements and your house's architecture. You or your electrician (think consultant) buys a long length of wire and then cuts it to the pr
oper length to connect to some appropriate point in the existing wiring infrastructure. As part of this, you probably installed a new junction box and outlet. Even then, there are some choices to make because you may need to put in a GFCI outlet if the location is outside or near a wet area like a sink or shower. There are a few more variables, but I think you get the idea.
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 - we won't even get into fire dangers.]
- 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, though it is now relatively simple to install them. I'm assuming you know what you are doing or have a licensed electrician do it for you!]
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 talk about how we 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. This means that, assuming I have the proper adapter, I can use the same laptop in the US or Europe without modifying the computer in any way. Users of early computers may remember a little switch on the power supply that you had to push one way or the other for either of the voltages. By the way, it is a really bad idea to plug a 110 volt device into a 220 volt electrical service.
Anyway, the 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 perform
ance 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. We 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.
So what do we call this concept to get people away from this single product notion? Here are some possibilities, and I'm only going to consider adding one or two words at the end of "Enterprise Service Bus," lest we confuse people even more:
- ESB Architecture (yuck - hard to talk about with SOA in the same breath)
- ESB Pattern
- ESB Infrastructure
- ESB Implementation
- ESB Network
- ESB Blueprint
Please let me know if any of these ring true to you or if you have better suggestions (I hope you do).
Incidentally, I'm writing this on a plane flying from Paris to Boston. I'm returning from a quick trip to Europe where I spoke at the XML & Web Services conference and with analysts and the press in London and Montpellier. It was good to see Patrick Gannon and Carol Geyer, some of my old friends from OASIS, even though I insisted on giving them grief over ebXML.