Distributed Systems Development - Autonomics Development: A Domain-Specific Aspect Language Approach - page 14

can be extended to be used across a communications network [15]. By extend-
ing procedure calls to a distributed environment, interprocess communication is
then given the syntax and semantics of a well-accepted strongly typed language
abstraction [90].
According to Soares [90], the RPC mechanism has the following advantages:

• The communication mechanism has clean, general, and comprehensible se-
mantics.
• A programmer is able to design a distributed application using the same
abstraction as well-engineered software in a non-distributed application.
•Itprovides information hiding as information can be hidden within design
components.
• The distribution of the application is transparent to the application user and
all communication details are hidden.

When a remote procedure call is invoked, the calling environment is sus-
pended, the procedure parameters are passed across the network to the callee, and
the procedure is executed on the remote machine. When the procedure finishes,
the results are passed back to the calling environment, where execution resumes
as if returning from a local procedure call [15].
RPCs can be either asynchronous or synchronous. Asynchronous RPC calls
do not block the caller and the replies can be received as and when they are needed,
thus allowing the caller execution to proceed in parallel with the callee execution
[4]. With synchronous RPCs, on the other hand, the caller is blocked until the
callee has finished execution.
This section provides an overview of the remote procedure call paradigm
and an implementation of a simple application using the ONC RPC system. We
describe the features and facilities of RPC systems along with their shortcomings
and compare it to BSD socket-based distributed systems.

2.3.1 Stubs and Skeletons

Remote procedure calls achieve a high-level of abstraction by using a system based
on proxies [41]. Proxies are used on the caller side to convert local procedure calls
into remote procedure calls and are used on the callee side to convert remote
procedure calls to local procedure calls. The caller proxy is known as a stub
and the callee proxy is known as a skeleton [116]. The interaction 2 between the
components in an RPC system is depicted in the diagram in Figure 2.2.
When a remote procedure call is invoked, the stub (compiled into the caller
code) translates the arguments into a data representation, a process called mar-
shalling, and transmits the data to the callee via the RPCRuntime system. On
receipt of the packets, the RPCRuntime in the callee machine passes them to
the skeleton (compiled into the callee code). The skeleton unpacks them into the

2 This example adapted from Birrell and Nelson [15].