The Irrelevancy of Objects to the WWW Infrastructure
A position paper for the
Workshop on Distributed Objects and Mobile Code
Open Software Foundation
11 Cambridge Center
Cambridge, MA 02142
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
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
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
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
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.