|
Advanced
We recommend Middleware as prerequisite reading for this technology description.
Remote Procedure Call (RPC) is a
client/server infrastructure that increases
the
interoperability,
portability, and
flexibility of an application by allowing the
application to be distributed over multiple heterogeneous platforms. It
reduces the
complexity of developing applications that span
multiple operating systems and network protocols by insulating the application
developer from the details of the various operating system and network
interfaces--function calls
are the programmer's interface when using RPC
[Rao 1995].
The concept of RPC has been discussed in literature as far back as 1976, with
full-scale implementations appearing in the late 1970s and early 1980s
[Birrell 84].
In order to access the remote server portion of an application, special
function calls, RPCs, are embedded within the client portion of the
client/server application program. Because they are embedded, RPCs do not
stand alone as a discreet middleware layer. When the client program is
compiled, the compiler creates a local stub for the client portion and another
stub for the server portion of the application. These stubs are invoked when
the application requires a remote function and typically support synchronous
calls between clients and servers. These relationships are shown in Figure 32
[Steinke 95].
By using RPC, the complexity involved in the development of
distributed processing is reduced by keeping the semantics of a remote call the same whether or not the client and server are collocated on the same system. However, RPC increases the involvement of an application developer with the complexity of the master-slave nature of the client/server mechanism.
RPC increases the flexibility of an architecture by allowing a client component of an application to employ a function call to access a server on a remote system. RPC allows the remote component to be accessed without knowledge of the network address or any other lower-level information. Most RPCs use a synchronous, request-reply (sometimes referred to as "call/wait") protocol which involves blocking of the client until the server fulfills its request. Asynchronous ("call/nowait") implementations are available but are currently the exception.
Figure 32: Remote Procedure Calls
RPC is typically implemented in one of two ways:
- within a broader, more encompassing propriety product
- by a programmer using a proprietary tool to create client/server RPC stubs
RPC is appropriate for client/server applications in which the client can
issue a request and wait for the server's response before continuing its own
processing. Because most RPC implementations do not support peer-to-peer, or
asynchronous, client/server interaction, RPC is not well-suited for
applications involving distributed objects or
object-oriented programming (see Object-Oriented Programming Languages).
Asynchronous and
synchronous mechanisms each have strengths and weaknesses
that should be considered when designing any specific application. In contrast
to asynchronous mechanisms employed by Message-Oriented Middleware, the use of a synchronous
request-reply mechanism in RPC requires that the client and server are always
available and functioning (i.e., the client or server is not blocked). In
order to allow a client/server application to recover from a blocked
condition, an implementation of a RPC is required to provide mechanisms such
as error messages, request timers, retransmissions, or redirection to an
alternate server. The complexity of the application using a RPC is dependent
on the sophistication of the specific RPC implementation (i.e., the more
sophisticated the recovery mechanisms supported by RPC, the less complex the
application utilizing the RPC is required to be). RPCs that implement
asynchronous mechanisms are very few and are difficult (complex) to implement
[Rao 1995].
When utilizing RPC over a distributed network, the performance (or load) of
the network should be considered. One of the strengths of RPC is that the
synchronous, blocking mechanism of RPC guards against overloading a network,
unlike the asynchronous mechanism of Message-Oriented Middleware (MOM). However, when recovery mechanisms, such as retransmissions, are employed by an RPC application, the resulting load on a network may increase, making the application inappropriate for a congested network. Also, because RPC uses static routing tables established at compile-time, the ability to perform load balancing across a network is difficult and should be considered when designing an RPC-based application.
Tools are available for a programmer to use in developing RPC applications
over a wide variety of platforms, including Windows (3.1, NT, 95), Macintosh,
26 variants of UNIX, OS/2, NetWare, and VMS
[Steinke 1995]. RPC
infrastructures are implemented within the Distributed Computing Environment (DCE) , and within Open
Network Computing (ONC), developed by Sunsoft, Inc. These two RPC
implementations dominate the current Middleware market
[Rao 1995].
RPC implementations are nominally incompatible with other RPC implementations, although some are compatible. Using a single implementation of a RPC in a system will most likely result in a dependence on the RPC vendor for maintenance support and future enhancements. This could have a highly negative impact on a system's flexibility, maintainability, portability, and interoperability.
Because there is no single standard for implementing an RPC, different features may be offered by individual RPC implementations. Features that may affect the design and cost of a RPC-based application include the following:
- support of synchronous and/or asynchronous processing
- support of different networking protocols
- support for different file systems
- whether the RPC mechanism can be obtained individually, or only bundled with a server operating system
Because of the complexity of the synchronous mechanism of RPC and the proprietary and unique nature of RPC implementations, training is essential even for the experienced programmer.
Other middleware technologies that allow the distribution of processing across multiple processors and platforms are
RPC can be effectively combined with Message-Oriented Middleware (MOM)- MOM can be used for asynchronous processing.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Birrell 84]
|
Birrell, A.D. & Nelson, B.J. "Implementing Remote Procedure Calls."
ACM Transactions on Computer Systems 2, 1 (February 1984):
39-59.
|
|
[Rao 95]
|
Rao, B.R. "Making the Most of Middleware." Data Communications
International 24, 12 (September 1995): 89-96.
|
|
[Steinke 95]
|
Steinke, Steve. "Middleware Meets the Network."
LAN: The Network Solutions Magazine 10, 13 (December 1995): 56.
|
|
[Thekkath 93]
|
Thekkath, C.A. & Levy, H.M. "Limits to Low-Latency Communication on
High-Speed Networks." ACM Transactions on Computer Systems 11, 2 (May
1993): 179-203.
|
Cory Vondrak, TRW, Redondo Beach, CA
25 June 97: modified/updated OLE/COM reference to COM/DCOM
10 Jan 97 (original)
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2008
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/rpc_body.html
Last Modified: 24 July 2008
|
