<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Distributed Objects - Remote Message
Passing</title></head><body>
<div>At 11:25 -0500 00.11.20, Lex Spoon wrote:</div>
<div><br></div>
<blockquote type="cite" cite>The best summary of the problems with
the abstraction I've seen is at:<br>
</blockquote>
<blockquote type="cite"
cite><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>http://www.sun.com/research/technical-rep<span
></span>orts/1994/abstract-29.html<br>
</blockquote>
<blockquote type="cite" cite>What do you think?</blockquote>
<div><br></div>
<div>I think that the Waldo paper referenced here, and Lex's browser
example,&nbsp; raise several very valid points.&nbsp; I've raised
some of these myself, along with others, in a paper of my own
critiquing RPC parameter passing.&nbsp;&nbsp; Butler Lampson also
listed some of them in the discussion of RPC that was part of his
talk at the 1999 SOSP.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>There are two issues to be solved in writing a distributed
application.&nbsp; The conceptually easy one is communicating with a
remote address space.&nbsp;&nbsp; It's conceptually easy, but very
messy, as anyone who has had to write code that marshals&nbsp; data
into a network format and rebuilds the data structure son the other
side will testify.</div>
<div><br></div>
<div>The conceptually hard issue is dealing with failure.&nbsp; I
agree that in some sense this is the core problem that characterizes
the field of distributed systems.&nbsp; Even<i> detecting</i> a
failure is impossible: a failed process cannot be distinguished from
one that is simply very slow. </div>
<div><br></div>
<div>RPC and RMI mechanisms help with the first problem.&nbsp; 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.</div>
<div><br></div>
<div>In this context, I think that the Waldo paper does not fairly
describe the distributed system-building methodology espoused by
languages such as Emerald.&nbsp; In Emerald, we made local and remote
method invocation semantically identical.&nbsp; 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.&nbsp; I still believe that
this is appropriate. </div>
<div><br></div>
<div>What Emerald did not try to do was to hide the location of
objects.&nbsp; On the contrary, there were special system primitives
that exposed the location of objects to the program.&nbsp; And it was
a design feature that there operations were language primitives, and
not simply message sends.&nbsp; Indeed, the mantra of those early
days was &quot;Invocation should be location independent, but Objects
need not be&quot;.</div>
<div><br></div>
<div>Neither did Emerald try to hide failures -- just the
opposite.&nbsp; 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.&nbsp; Once again,
this was quite different from exception handling, which is applied
when&nbsp; the message send and answer mechanism has succeeded, but
the reply may not be what the sender had hoped for.</div>
<div><br></div>
<div>So, to recap: the hard problems of distributed computing are
designing the distributed object architecture, locating the objects
for efficiency, detecting failures,&nbsp; making progress in the
presence of uncertainty about the global system state, and so
on.&nbsp; Anyone who sells you an RPC or RMI mechanism claiming that
it solves these problems is a charlatan.</div>
<div><br></div>
<div>But that does mean that an RPC or RMI mechanism is not
useful.&nbsp; If it is well designed and implemented, it removes a
lot of error-prone detail from the eyes of the programmer and the
maintainer.&nbsp; It lets them focus on the hard problems listed
above.&nbsp; I don't see that this is bad.</div>
<div><br></div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Andrew</div>
<div>_________________________________________<span
></span>_______________________________________</div>
<div><br></div>
<div>Reference:</div>
<div><br></div>
<div>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.</div>
</body>
</html>