[8538] in www-talk@info.cern.ch
The Web is more than (conventional) distributed objects
daemon@ATHENA.MIT.EDU (Paul Burchard)
Thu Jun 29 20:49:39 1995
Date: Thu, 29 Jun 95 18:39:00 -0600
From: Paul Burchard <burchard@horizon.math.utah.edu>
To: Gavin Nicol <gtn@ebt.com>
Cc: www-vrml@wired.com, www-talk@www10.w3.org
Reply-To: burchard@geom.umn.edu
Resent-From: www-talk@www10.w3.org
Gavin Nicol <gtn@ebt.com> writes:
> [monolithic browsers...HTTP's focus on data transfer...]
>
> I think the solution to both of these problems lies in
> distributed object technologies, and in particular, CORBA.
I agree up to a point. But for an unsecure network like the Web,
CORBA-style distributed objects are not powerful enough to create a
true distributed computing platform. Distributed computing requires
the ability to relocate both data and computation on the network in
order to optimize communication costs.
It's true that on a controlled network, RPC and object-data copying
are sufficient to accomplish these goals, because the associated
executable code may be assumed to be securely available at all nodes.
But on an unsecure network, a real distributed object system also
requires some mechanism for safely transmitting object implementation
code. In contrast, CORBA/ILU-style distributed object systems were
designed specifically to factor out object implementation issues.
Nevertheless, far from criticizing this factorization, I believe it
to form the correct basis for extension of distributed objects to the
unsecure setting. When a class implementation is not locally
available, the distributed object runtime needs to be able to
retrieve it over the network -- in terms of _any_ secure,
CORBA/ILU-capable language for which it has a local interpreter. The
resulting objects can then communicate locally through the usual
CORBA/ILU mechanisms (which may be very efficient if all
implementations happen to be available in the same language).
Thus, the Web needs the following ingredients beyond CORBA:
1. A system for remote location and retrieval of implementation code
(could be as simple as URIs and HTTP with format negotiation)
2. Secure, CORBA-aware, transportable languages
(e.g., Java, Phantom...once they are made CORBA-compatible!)
3. A "class-faulting" distributed object runtime
(hooks could be added to the CORBA glue for each language)
> The last point is important: one can look at HTTP as nothing
> more than an extraordinarily simple (and limited) form of
> remote method invocation.
Given the semantics of PUT, and the support in MIME for executable
data types, HTTP in its own right can already be thought of as a
crude version of the full distributed object model described above,
which allows migration of both data and implementation. (Of course,
HTTP's simplicity allows a variety of formal interpretations.)
> In addition, one of the very major problems with the WWW is that it
> is very much focuased on data/code transfer (ie. Java download code
> rather than using RPC, and HTTP etc al. are basically data transfer
> protocols). For many needs, this is in fact the optimal way of
> accessing data, but for a number of other important cases, it
> is not.
Exactly; that's the balancing issue. I've tried to outline above how
I think the RPC/transfer approaches should be conceptually merged.
---------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still trying to learn how to count backwards from infinity...''
---------------------------------------------------------------------
