Why do we distribute objects anyway?

[Bill Frantz]

The question has been raised, why do we use distributed objects in place of
defining an asynchronous message protocol and being done with it.  Since E
distributed objects are built on top of a asynchronous messaging protocol
(IP), it is obvious that anything you can do in E you can do with
asynchronous messages.  I expect the answer to this question also applies
to arguments about E's security, so I will try to think thru my fingers here.

Let's take a simple application.  Alice has a dynamic variable on her
machine.  She wants to give Bob and Carol the privilege of reading the
current value of that variable.

In E she gives each of them a sturdy reference to an different object on
her machine which will return the current value of the variable when it is
invoked, and she is done.  (Each gets a separate object so they can be
individually revoked.)  Simplicity has the win for E here.

With async messages, she needs to define a protocol to read the value.  She
also needs to set up authentication so she doesn't let just anybody read
the value.  Assume she takes the approach of the E run time.  She sets up
an authenticated connection between herself and her callers (Bob and
Carol).  She makes a different big random number for each of them and gives
one to Bob and another to Carol and tells them to authenticate their
requests with that number.

Now Bob and Carol know that when they want to read Alice's variable, they
first check that they are talking to Alice and the send a message that
looks like:

   <random-number> <read>

Alice will ensure that the random number is correct and return a message
which looks like:

   <current-value>


If Alice decides she no longer wants to make the current value available to
Bob, but wants to continue to make it available to Carol, she has to revoke
access.

In E, she had to plan ahead, and build a revoke operation into the object
she gave Bob.  If she didn't plan ahead, she has to hack her E runtime to
do the same thing that she does in the async message case below.

In the async message case, Alice makes it so that the big number she gave
to Bob is no longer recognized as authenticating a request for the current
value.  If she is feeling nice, she will return a "request rejected"
response to Bob's request.  If she is feeling more like the IETF, she will
just ignore his request.  The request rejected response is similar to the
effect of a space bank delete object operation in KeyKOS.


It seems like E has saved Alice a bunch of detail work at the cost of
having to build a specific "revoke" operation into her objects.  She also
gets the benefit of having others check the security of the protocol.

Have I missed anything?