Open standards, open source, open minds, open opportunities
sutor 120000G8AG 413 Visits
sutor 120000G8AG 157 Visits
I've mentioned before that I'm giving the opening keynote at the WebSphere Technical Exchange in San Francisco. If you were hoping to go but have not registered, I'm sorry to tell you that the event is now sold out. While I'm obviously with IBM and obviously would promote this conference, I hope you do take a look at the agenda and see if this isn't something you might want to attend next time it comes around.
The conference is organized around five tracks this year:
The Web Services track includes the following sessions:
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
So although I've used a wiring example, there are a few concepts here that we can relate to IT:
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
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:
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.[Read More]