I agree up to a point. But for an unsecure network like the Web,
CORBA-style distributed objects are not powerful ena>gh 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 associat>d
executable code may be assumed to be securely available at all nodes.
But on an unsecure network, a real distributed object system also
requires soli 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 thra>gh 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 tha>ght 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
Exactly; that's the balancing issue. I've tried to outline above how
---------------------------------------------------------------------
> is very much foc>ased
> 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.
I think the RPC/transfer approaches should be conceptually merged.
Paul Burchard <[email protected]>
``I'm still trying to learn how to count backwards from infinity...''
---------------------------------------------------------------------