BT Position Paper
Joint W3C/OMG Workshop on Distributed Objects and Mobile Code, June 24-25, 1996
The marriage between distributed object technology (the real men) and Web technology (the earth mothers) has been announced. From the groom's point of view, preparations for the marriage will be complete once he's taught the bride how to speak IIOP, learnt a bit of HTTP to make her comfortable and finished work on some important object services in the shed at the bottom of the OMG. However, by some mysterious organic process, she has amassed knowledge of all things. Whatever question he has, he must discover the spell that will draw out the answer. He needs to get in touch with her inner feelings. Consummation will be delayed until this chauvinistic gap is breached.
It is fashionable to criticise how well the Web achieves this or that goal then invent a "proper" service to do it better. It is tempting to suppose that technology for structured applications from the traditions of the distributed object world should be inserted into the Web on the day of their marriage. This paper aims to show that, in the field of service discovery, the Web deserves a long hard look before we click on the button marked "Fixed in the Next Release". As such, no new technology is proposed, merely some optimistic thoughts leading to the insight that the Web is a "proper" system for resource discovery (well, nearly).
The ideas in this paper stemmed from a short exercise describing the steps required for service discovery in terms familiar to the distributed object community, then comparing this with how these are implemented in the Web. The big assumption (cheat) was made that data designed as human readable is equivalent to machine-readable data.
At this point the reader is probably thinking, "Well isn't that obvious?" and probably also thinking, "But the assumption that human readable equals machine readable is just plain wrong". The very fact that these insights are possible by merely adopting one assumption, should itself provide further insight by examining that assumption.
Trying to design a "proper" name server, trader, locator or type repository for a massive scale federated system won't work if all the data that will populate it is "left as an exercise for the user". At present, the distributed object community has all the proper (but hollow) objects, while the Web has all the data to populate them (somewhere). Therefore the problem is not just to add metadata structure to content, but primarily to learn how to extract structure from the unstructured data that will both continue to exist, and continue to be created.