The Irrelevancy of Objects to the WWW Infrastructure

A position paper for the Joint W3C/OMG Workshop on Distributed Objects and Mobile Code

Object-oriented programming has been the ``next big thing'' in the programming world for over a decade. In fact, I am probably dating myself by using the word programming rather than technology. O-O technology provides an environment in which O-O programming is the most natural way to write code, just as a language without goto makes structured programming the most natural way to write code.

The OMG's definition of an object model, interface language and API, and language bindings seems to be the final push that O-O programming needs for widespread deployment. This is a good thing: as any programmer can tell you, writing code is hard. Object-oriented programming can provide a realistic way of reducing the amount of new code that has to be written:

• Contractual interfaces (expressed through an IDL) ensure that ``using'' code will not change when the implementation ``providing'' code is replaced.
• Encapsulation integrates ``legacy'' facilities (libraries, servers, etc.) into the new paradigm, increasing re-use.
• Inheritance seems to provide a cleaner abstraction than C-like libraries, leveraging commonality to again reduce the amount of new code that must be written.

But looking at it as a technology for Web infrastructure, so what? Object-oriented technology will probably help make it easier to write new web servers in the future. But objects operate at too high a level to be able to address any of the problems the World-Wide Web currently has, or might have in the near future:

• The Web needs security. Objects could help define a security model, such as sparse ACL's on a Web document tree, or policy objects holding collections of Web documents, but that is a server-internal matter unrelated to interoperability. The method of sending authentication data from client to server, and the format of that data, require protocol specifications. The OMG security work has shown that security has vast implications on the object model; it has also been trying for some time to define a base-level interoperable security mechanism without succcess. Contrast this with the Web, where the security protocols currently in use all co-exist with no difference in the HTTP usage model.
• The Web needs protocol work. To quote from the chairman of the IETF HTTP working group: ``Of top priority are those fixes that will help relieve HTTP-caused Internet congestion: host identification, caching, persistent connections.'' Again, objects are too high-level to be useful. The IIOP architecture allows for a variety of transport protocols, without the ORB or clients having any knowledge -- in fact, there is no standard protocol identification mechanism in IIOP. It would be highly surprising if ``TCP tweaks'' to HTTP were not similarly invisible to O-O developers.
• The Web needs naming. A global location-independent naming system is needed. With its concepts of binding and object rereferences, it would seem that O-O is a good candidate to address this issue. This would require world-wide adoption of a single object model which will never happen. Nor will the world ever have a single naming system -- whois++, DNS, X.500 and their ilk will be joined by new systems not merged into one. The most likely way of addressing this issue, then, is to use a federated naming system which can traverse these different protocols.
• The Web is very big. Nobody has ever built an object system anywhere near as big as the Web. Object models that work well in large enterprises might break down when scaled up to the required size. Can a collection realistically handle the wide range in sizes that could be returned by two different Altavista queries? O-O technology hides such issues; by exposing its reliance on TCP, the Web infrastructure makes it obvious that these are problems that need to be addressed.

The cornerstone to the Web's success is its interoperability. The Web infrastructure must ensure this interoperability as it continues to add functionality and address growth problems. O-O technology traditionally abstracts such issues away, freeing the programmer to work on the ``real work.'' For the Web infrastructure, however, the real work is in precisely those areas that objects would have us forget.