The Web is more than (conventional) distributed objects

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...''
---------------------------------------------------------------------

Received on Thursday, 29 June 1995 20:39:43 UTC