John Chamberlain |
Developer Diary |
Developer Diary · You Heard It Here First · 26 December 2003 |
Waiting for Web Services |
The web services jihad ambles on without result. The original fanfare promised a world where the web was bristling with commercial interoperability and consumer nirvana. The user could hop on and instantly find the catalog of any business and access any information about any product. And if that product was a software product they could instantly use it using the same magical web services client. It was like the computer in Star Trek--you just ask it for what you want and whether it's a ham sandwich or information on the Antares group you have your answer (or lunch). The reality is that years later nothing has happened. A few banks have eeked out web services interfaces that are used entirely internally at great expense. Why is nothing happening?
Historically the roots of web services can be found in DCOM--Microsoft's convoluted attempt at distributed object systems. The idea is that a bundle of logic, an object, on one computer could talk to another on a different machine. Instead of using two different programs talking using a protocol (like say a web browser talking to a web server), in DCOM the program would effectively span many machines at the same time, kind of like fungus. Unbeknownst to many people fungus grows in huge continuous communities in the soil sometimes stretching for miles. Mushrooms are actually the sexual organs of the fungus. Each mushroom is not a separate fungus, but in fact is just a part of a huge body that mostly lies beneath the ground and includes many other mushrooms. The DCOM idea is the same, you have a gigantic program that spans many computers and just sprouts mushrooms where it needs to. Unfortunately DCOM never caught on. As one of the many unfortunate programmers forced to try to implement DCOM I can tell you exactly why: it just didn't work. The first problem was that there was no discovery process so that knowing exactly where the "enemy" machine was located presented a formidable problem. Most programmers solved this problem by hardcoding the IP address of the other machines into their programs--not exactly very flexible. After you got past that one, problem two was the crashes. DCOM involves wrapping an object up, sending it across a wire, and then unwrapping it again and running. The only problem was when you did step three often the result would be the crash of the lucky computer receiving the transmission. Analyzing the incredibly obscure and multifold reasons for this would be sheer agony for me so I will leave the details to the reader's imagination. The third killer feature of DCOM was the mind-numbing level of administration needed to enable it. All kinds of settings and registry entries needed to be perfectly in place on all the machines in question. This meant writing incredibly complicated installers to configure the lucky DCOM recipients, and if anything changed on a machine, watch out because it was GPF time. I think you get the idea. DCOM no worky. DCOM Next Generation: CORBA
When Java rolled around naturally everyone wanted to repeat DCOM's abyssmal failure so they invented CORBA. CORBA is just like DCOM except that instead of wrapping up evil little Microsoft objects you wrap up good, clean Java objects. Unfortunately CORBA never caught on. As one of the many unfortunate programmers forced to try to implement CORBA I can tell you exactly why: it just didn't work. The first problem was that there was no discovery process so that knowing exactly where the "enemy" machine was located presented a formidable problem. Most programmers solved this problem by hardcoding the IP address of the other machines into their programs--not exactly very flexible. After you got past that one, problem two was the crashes. Yada, yada, yada, CORBA no worky either.
Final Fantasy: Web Services
DCOM was entirely a Microsoft venture and CORBA was primarily a Java effort. Now in a final battle for supremacy we have [***fanfare please***] web services, TaDa!, in which both teams literally go for broke head to head. If you haven't figured out the outcome yet I suggest you take some ginseng or something and read the previous two paragraphs again. Microsoft has fired the most recent salvo in this war with "Indigo", a cool-sounding code name for their "Longhorn" web services integration. The idea here is to inextricably link web services security, transactions and who knows what else to semi-secret APIs and lock lucky web services users into the Windows platform. According to Microsoft this will be very convenient for the users. Anyway I can hardly wait for the response from the Java camp.
When I was a kid I was forced to read (among other things) an incredibly boring and stupid play called "Waiting for Godot". Not only is this play totally pointless but is cleverly constructed to be well beyond the ability of most children to understand so that they suffer as much as possible reading it. I may have been scarred, but now after all these years I think I am slowly starting to understand the twisted thinking behind that stupid play.
|
return to John Chamberlain's home · diary index |
Developer Diary · info@johnchamberlain.com · bio · Revised 26 December 2003 · Pure Content |