From: Jonathan Aldrich (jonal@cs.washington.edu)
Date: Mon Dec 16 2002 - 23:29:38 PST
"A Note on Distributed Computing"
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall
http://research.sun.com/techrep/1994/abstract-29.html
This paper is pretty famous in the distributed object world, and it plays
a key role in my thinking about distributed systems (see below). It's
definitely a valuable read for anyone thinking of developing distributed
systems or related tools. The central argument is that it's a bad idea to
use treat remote and local objects identically in a language or run-time
system. The biggest problem they identify is partial failure, a really
hairy issue with distributed applications that simply doesn't occur in
local applications. They make several other salient points as well, such
as the difference in latency between local and remote accesses, which is
*far* larger than the penalty of using a high-level language (for
example).
I basically agree with them at a fundamental level--application designers
need to be aware of distribution to code robust applications. However,
many solutions make the mistake of exposing distribution throughout the
application, resulting in "tangled" and unreusable code. Jim Waldo, one
of the authors of this paper, did this when he designed RMI (to be fair to
Jim, he probably wasn't able to consider changing the language). RMI
exposes the distributed nature of a remote reference by requiring all
methods in the reference's interface to throw a RemoteException in case a
network failure occurs. As a result, all application code must know if it
is dealing with a remote reference, and handle the appropriate exception
accordingly. Distribution is not a modularized concern, but is tangled
throughout the code, making the code less reuseable and harder to
understand.
Getting this issue right was a central motivation of the ArchJava
connector design. In ArchJava, a component does not have to be aware of
the protocol it uses to communicate with external components--thus it is
reuseable in a wide variety of systems, and can communicate with both
local and remote peers using the same code. The communication protocol
(local or remote) to be used is defined using an architectural connector
in the surrounding architecture. These connectors can also include the
logic that handles failures, at least partially insulating the components
themselves from many of the hard problems in distributed systems. Thus,
the application designer is aware of distribution, but handles it in a
modular way using the architectural constructs.
Of course, there are other solutions to this as well. For example, there
was a paper in this year's OOPSLA applying AspectJ to distributed systems.
Jonathan
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://mailman.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2.1.5 : Mon Dec 16 2002 - 23:29:43 PST