Craig Hubley <craig@passport.ca> writes:
> Paul Burchard <burchard@math.utah.edu> writes:
> > 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.
>
> Yes. Best reference I know of is David Gelertner's paper
> on "Linda in Context" in (I believe) August '88
> Communications of the ACM. He is very clear that
> 'distributed objects' are NOT a modelling technology
> and NOT a distributed computing mechanism but merely an
> integration/binding mechanism. A lot of us old
> OOP-heads did a hard sell on objects in the 80s on the basis
> that they would improve distribution capability and
> simplify modelling, but this is a far cry from saying that
> they actually solve these problems.
>
> Also, speaking as someone who worked with all of CORBA's
> predecessor and inspiring technologies (Sun ToolTalk
> and DOE, DEC ACAS - later LinkWorks, various object DBs,
> HP NewWave later OpenWave, DCE and related
> technologies) directly for the vendors, I can honestly
> say that no one thought hard enough about WAN problems, in
> particular response latencies. CORBA will not help you
> with the problem of measuring and anticipating real time
> response which is one of the worst problems in a
> stochastically distributed net of objects. For
> reference, see Mario Tokoro's work, published mostly in
> SIGPLAN's OOPSLA proceedings.
>
> > 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.
>
> Yes. Also other guarantees, such as physical privacy of
> the network or cost accounting reliability, can be
> assumed to be provided by the network. None of this is true
> on the internet: services may be operated by different
> organizations that want payment from other services
> before responding to them, which gets into
> payment/authentication, privacy of the transmission,
> etc.
>
> > 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.
>
> Yes. Thus the popularity of
> implemention-code-distributing mechanisms such as
> Java's HTML-extension-based transfer of code to the
> client browser.
>
> > 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
>
> Yes, it's a good basis for representing the names of the
> various objects and their functions, but all that does is
> standardize binding and some of the namespace. You still
> have to build some software to solve the real problem.
> With so many different possible configurations and
> constraints, it seems unlikely to me that this could ever
> be a single standard protocol.
>
> More likely a set of objects could be standardized to
> represent the various objects involved: users,
> terminals, services, brokers, payment clearers, etc.
> Actual processing required of these objects would be
> very application-specific or network-specific, but at
> least they'd all have the same names. Better than what
> we've got now.
>
> > 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
>
> A simpler alternative is RPC-based stubs that sit behind
> proxy objects instantiated by a local library. Use
> CORBA/ILU when dealing with another object oriented
> application, but the overhead isn't required when you
> know your server. Running through insecure brokers
> might be quite undesirable. I can implement a secure RPC
> stub easily but it's a horror to write my own secure CORBA
> implementation. And I'll be damned if my financial apps
> are going to route their requests through a commercial
> broker running on someone else's network, in the
> clear...!
>
> > 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).
>
> CORBA/ILU is reasonable for local applications where I
> control the net. Not reasonable on WANs until it is secure
> - see my requirements below.
>
> > 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)
>
> Yes, Java is kind of doing this now.
>
> > 2. Secure, CORBA-aware, transportable languages
> > (e.g., Java, Phantom...once they are made CORBA-compatible!)
>
> You mean, incorporate the CORBA Common Services and Object Model ?
> Don't forget that real security implies authenticated encrypted and
> traffic-mixed requests and responses, which CORBA doesn't have now.
> Think of it as a parallel to SSL - a 'secure object/method layer'.
>
> > 3. A "class-faulting" distributed object runtime
> > (hooks could be added to the CORBA glue for each language)
>
> Yes, although this already exists for DCE-based solutions.
>
> > 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,
>
> Another reason to offer some DCE-based integration is
> that it could be rolled out far more quickly than an
> improved CORBA. DCE-RPC-based tools could easily issue
> SSL calls instead of insecure socket calls. However
> producing an object oriented secure layer seems like a
> major task and a prerequisite to serious commercial
> applications.
>
> On the other hand you can put up a CORBA server on a port
> right now and invite people to route object requests
> through it, and developers of new systems and tools to
> support CORBA as well as HTTP etc. Tall order but if they
> already support CORBA on a LAN they could probably adapt
> to WAN access as well. This would not solve the security
> problems but would provide prototypes that would
> illustrate the traffic and response time problems.
>
> --
> Craig Hubley Business that runs on knowledge
> Craig Hubley & Associates needs software that runs on the net
> mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX
> Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5
--------------------------------------------------------------------
Paul Burchard <burchard@cs.princeton.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------