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?