At 11:25 -0500 00.11.20, Lex Spoon wrote:

>The best summary of the problems with the abstraction I've seen is at:
>
>	http://www.sun.com/research/technical-reports/1994/abstract-29.html
>
>What do you think?

I think that the Waldo paper referenced here, and Lex's browser 
example,  raise several very valid points.  I've raised some of these 
myself, along with others, in a paper of my own critiquing RPC 
parameter passing.   Butler Lampson also listed some of them in the 
discussion of RPC that was part of his talk at the 1999 SOSP.

Java RMI is considered by some to be unusable because on the one 
hand, the semantics of a message send depend on whether the sender 
and the target are co-located, while on the other hand you are not 
supposed to _know_ if they are co-located.

There are two issues to be solved in writing a distributed 
application.  The conceptually easy one is communicating with a 
remote address space.   It's conceptually easy, but very messy, as 
anyone who has had to write code that marshals  data into a network 
format and rebuilds the data structure son the other side will 
testify.

The conceptually hard issue is dealing with failure.  I agree that in 
some sense this is the core problem that characterizes the field of 
distributed systems.  Even detecting a failure is impossible: a 
failed process cannot be distinguished from one that is simply very 
slow.

RPC and RMI mechanisms help with the first problem.  They do not help 
with the second, other than by freeing up your time to focus on 
issues of failure because you don't have to worry about getting the 
bits across the network.

In this context, I think that the Waldo paper does not fairly 
describe the distributed system-building methodology espoused by 
languages such as Emerald.  In Emerald, we made local and remote 
method invocation semantically identical.  This meant that when you 
wrote a message send, the syntax and semantics did not depend on the 
location of the sender and the target.  I still believe that this is 
appropriate.

What Emerald did not try to do was to hide the location of objects. 
On the contrary, there were special system primitives that exposed 
the location of objects to the program.  And it was a design feature 
that there operations were language primitives, and not simply 
message sends.  Indeed, the mantra of those early days was 
"Invocation should be location independent, but Objects need not be".

Neither did Emerald try to hide failures -- just the opposite.  Any 
message send could be provided with a failure handler that allowed 
the sender to explicitly write code that dealt with the situation 
where the target object failed.  Once again, this was quite different 
from exception handling, which is applied when  the message send and 
answer mechanism has succeeded, but the reply may not be what the 
sender had hoped for.

So, to recap: the hard problems of distributed computing are 
designing the distributed object architecture, locating the objects 
for efficiency, detecting failures,  making progress in the presence 
of uncertainty about the global system state, and so on.  Anyone who 
sells you an RPC or RMI mechanism claiming that it solves these 
problems is a charlatan.

But that does mean that an RPC or RMI mechanism is not useful.  If it 
is well designed and implemented, it removes a lot of error-prone 
detail from the eyes of the programmer and the maintainer.  It lets 
them focus on the hard problems listed above.  I don't see that this 
is bad.

	Andrew
________________________________________________________________________________

Reference:

M. M. da Silva, M. P. Atkinson, A. P. Black (1996). Semantics for 
Parameter Passing in a Type-complete Persistent RPC. 16th 
International Conference on Distributed Computing Systems, Hong Kong, 
IEEE Computer Society Press.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20001121/3b6df309/attachment.htm