Recombinant growth - a golden opportunity for web services
By Sean Mc Grath
I don't often read what economists write and they return the compliment by not reading what I write. It's a long standing arrangement.
Recently however, meandering along a blogtrail, I came across an article by Hal Varian entitled "The economics of innovation".
It is a very interesting read that illustrates how bursts of economic growth can be attributed to periods of recombination. Periods in which existing products/services are disassembled into component pieces and then endlessly re-assembled in different combinations.
Varian points to the combination of HTTP and XML as the key component pieces in enabling recombinative growth on the Web. This sounds entirely plausible. I'm guessing that most technologists reading this are probably feeling comfortable - perhaps even warm and fuzzy - with this idea. Equally, any economists reading (unlikely I know) are probably comfortable too. After all, the information technologists know what a "component" is, right?
Now is the time for you technologists out there to fidget in your seat and any economists out there to raise an eyebrow in astonishment. The truth is, the road to 2003 from the dawn of computing, is littered with the charred remains of attempts at componentizing software that went up in smoke. Modules, routines, functions, procedures, objects, interfaces, patterns, aspects, pre/post conditions, data flows, beans, controls, widgets, entities and last but not least Web Services.
Web Services is the latest putative slayer of the component problem in software. This is weird as Web Services do not contain any new thinking on the problem of componentising software that I can discern. It is as if large chunks of the industry are engaged in a collective amnesia about our failure to coalesce around a component model of software. It is as if sprinkling some HTTP and XML on top of the component problem will make the component problem go away. It will not.
I think the fuzzy consensus we have on the concept of a "component" is the key reason why Web Services are the source of so much confusion. Everyone who has internalized the phrase, does so by packaging it up along with their previously internalized notion of "component". Unfortunately, we all have different interpretations of what constitutes a component and that is where the problem lies.
It is fun to watch someone who sees the world in terms of, say, objects talking Web Services with someone who sees the world in terms of, say, messaging. They may be using the same terms - WSDL, SOAP etc. but they more often than not are talking across each other - all because they do not share a common conceptualization of the fundamental concept of a component.
There are object people who think Web Services are great because they hide away platform dependencies. The subtext for object-heads is that so called RPC Web Services (Remote Procedure Call) are great because they can work regardless of the object technology underfoot - COM, CORBA, RMI etc. It appears that the majority of Web Services advocates are currently in that camp.
The problem for these folk of course is that COM, CORBA, RMI etc. are themselves previous attempts at creating components in terms of objects using a layer to hide away platform dependencies! How does adding yet another layer for platform independence help? Why will the new layer, made up of angle brackets and HTTP headers, succeed were their other extra layers failed?
This is a tough question to answer, but it must be answered. Either that or the problem must be revisited afresh. Otherwise, the economists will blame us for spurning the opportunity to create recombinant growth that the basic Internet platform presented to us on a plate.
My opinion is that we need to revisit the problem. We need to stop putting our faith in adding yet more layers to a "solution" to the component problem that has dubious credentials.
I speak of course of object-oriented design. To date, OO has shown itself to be an excellent abstraction for building tightly coupled components - say, as part of a single Windows of Java Swing program -but not a good model for inter-application components. It seems that the larger the scope of the problem, the less useful the object abstraction is. When was the last time you plugged in an off-the-shelf sales ledger component? How about a bank account component? There aren't many of these around, but there are lots of objects to handle GUI windows, filesystems, communications protocols and so on.
It is the larger, enterprise wide, componentization that is needed to drive recombinant growth in web services. Getting there requires moving past OO in my opinion. I think it is about time we seriously revisited a loosely coupled, data-oriented approach to componentization in which data (in XML of course) flows through processing nodes (web services) via reliable message pipes (MOM on HTTP). Not an object in sight!
Now would be a very good time to do that because otherwise XML will be the next in a long list of technologies that promised more than it delivered. If we insist in treating XML as a way of getting objects to talk to each other via RPC, we will have already failed in the quest for a globally applicable, recombinative component architecture. That quest was doomed before we added XML into the equation. Remember CORBA? Remember DCOM?
XML really can be something new for componentized software but only if we resist trying to recast it in terms of paradigms we are more familiar with. The trick, I believe, is to leverage the temporal, spatial and process decoupling tools at our disposal (MOM, HTTP, XML respectively)to create a genuinely new formulation of what it is to be a software component. A formulation that pays homage to systems as collaborating sets of black box data transformations rather than black box objects that fuse data and processing in a process specific deadly embrace.
Now would be a very good time to do it because right now, I fear that the power of the object camp is so overwhelming that fundamental technologies such as XML and HTTP will be bent out of shape to meet the object world view. Strong Datatyping, Binary XML, SOAP/DIME all point in this direction I'm afraid.
This is sad because a golden opportunity to grin back at the economists has presented itself to us.
Let's not spurn this opportunity.