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

2.3.7 Summary

This section has provided an overview of the remote procedure call paradigm and
an implementation of our simple example using the ONC RPC system. Various
aspects of RPC systems have been discussed including the IDL, data representation
and call semantics.
As illustrated in our example, RPC systems are highly intrusive as program-
mers are required to describe their remote procedures in an IDL, to implement
methods generated by the IDL program generator, to use the RPC framework
directly in the implementation code, and to adhere to framework specific con-
ventions. However, compared to BSD socket-based systems, RPC systems are
significantly easier to implement, understand, and subsequently maintain.
Most RPC systems attempt to provide programmer transparency so that
calling a remote procedure is as simple as calling a local procedure. Indeed, this
transparency is often seen as a great benefit of the RPC paradigm as Soares [90]
states:

“The ideal RPC mechanism is the one that provides the application
user with the same syntax and semantics for all procedure calls inde-
pendently of being a local call or a remote one”

This notion of transparency, however, leads to an unfortunate situation when
errors occur, as recovery is left to the RPC system to handle, not the programmer.
Unfortunately, in many situations, the RPC system simply cannot recover, result-
ing in the application hanging while the RPC runtime attempts to reconnect to
the server. Synchronous RPC systems are therefore suitable only for applications
that can be modelled as idempotent, such as the NFS system. Perhaps the biggest
weakness with RPC systems, however, is that their language-neutral nature limits
the data types that can travel between processes to the basic static data types
that can be supported by each language [116].

2.4 CORBA
One of the primary issues with early RPC systems is that they did not have an
object-oriented model and client applications need to know not only how to access
a server but also the location of the server. In addition, client code has to change
whenever the client wants to use new services [27].
The Common Object Request Broker Architecture (CORBA) is designed as
a middleware to enable distributed objects to communicate with one another via
an Object Request Broker (ORB). In the CORBA model, clients communicate to
a server via an ORB as illustrated in Figure 2.5.
Communicating via an ORB removes the necessity for a client to know the
whereabouts of a server as clients send requests to the ORB requesting that certain