Middleware Matters

Over in his latest blog entry, entitled Slab! Interoperation and evolution in web architecture, Bill de hÓra has written yet another must-read piece. (If you're not subscribed to his blog, then you're missing out on some generally great insights.) I'd like to focus on something he says near the end:

Aside from complications resulting from the strategic and commercial agendas imposed by the industry that have resulted in a plethora of competing and inconsistent web services 'standards', the core technical debate has been arcane. It is not always obvious to outsiders and system stakeholders why some kind of agreement can't be forged. While the architects and vendors are busy in argument, customers and practitioners are frequently left with little by the way of clear advice on how to either construct new systems or integrate existing ones. The outcome is that systems are being built, week in, week out, that cross the Web/Middleware boundary without being informed by both approaches and where they are appropriate. This implies projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art.

Coincidentally, my next "Toward Integration" column is on precisely that same topic: the general failure to date to turn the seemingly aimless WS-* menagerie into a collection of solid and useful industry standards. That column won't be out until mid-November, but for now suffice it to say that Bill and I seem to pretty much be on the same page on this topic.

The whole WS-* mess reminds me of what happened in the OMG starting around a decade ago with respect to object services. Around 1993-1994 the first CORBA ORBs started to appear, which provided basic distributed object activation and communication infrastructure, and so a few folks started looking at the next level up. Now that we had objects, they felt we needed a whole bunch of common services for those objects to use. The result? A whole bunch of specs that nobody ever used. These specs covered things like externalization, relationships, lifecycle, persistence, query, properties, licensing, collections, startup, data interchange, mobile agents, business object facilities, printing, and management. Oh, and don't forget distributed document components ala OpenDoc. Where are these specs now? All dead. Most were dead right from the start. Few people, if any, ever implemented them -- in fact, some were literally impossible to implement -- and nobody ever used them. This failure occurred largely because the specs were written without the benefit of significant experience with implementing and using the specified approaches, and also because the specifications received hardly any vetting except by a few self-anointed "experts."

WS-* authors might say they're avoiding this by keeping the specifications out of standards bodies until they're cooked, thus avoiding design by committee and lengthy standardization cycles, but publishing proprietary standards and then holding little closed workshops to vet them will only result in a similar mess. The result of that mess in turn will be exactly as Bill describes it: "projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art."