Integration Technologies - Guide to Cloud Computing for Business and Technology Managers - page 115

to a local stub. Stubs are code within the local system that handles commu-
nication and passing data to and from the remote system. When a local stub
receives the arguments, it establishes communication with the server and
passes the arguments for the procedure call to the stub on the server. The cli-
ent application blocks processing while it waits for the response to its remote
procedure calls. When the server stub receives the arguments, it calls the
procedure. After the server executes the procedure call, it passes the results
to the server stub, which sends the results to the client stub. The client stub
passes the results to the calling application. The connection between the two
systems is closed only after the server returns the results of the request or the
connection reaches a preset time limit. The client proceeds with its process-
ing after it has received the response. Figure 5.1 describes the basic operation
of RPC. In this example, the calling application in system A calls the RPC cli-
ent stub. The stub then communicates with the RPC server stub in system B.
After the target application in system B finishes processing, the result is sent
back to the calling application via the client and server stubs.
RPC utilizes synchronous communication, which is different from the
asynchronous nature of messaging. Using RPC, an application can invoke
functions on another system as if they are on the same system. This is a tre-
mendous help for application development. In a client-server development
environment, developers can build distributed applications that span mul-
tiple computers using RPC without having to worry about network interface
details. Unlike message-oriented middleware (MOM), RPC is not a discrete
middleware layer. It requires stub codes on the client and the server. As long
as the RPC stubs are available on the client and the server, the communica-
tion can be established directly without a discrete middleware intermediary.
RPC technology comes with its set of specifications; when applications on dif-
ferent platforms follow the same set of specifications, these applications can
interact with one another. Thus, RPC standards are platform independent.
RPCs work well for smaller, simple applications where communication
is primarily point to point (rather than one system to many). RPCs do not
scale well to large, mission-critical applications, as they leave many crucial
details to the programmer, including handling network and system failures,
handling multiple connections, and synchronization between processes.
RPC-style programming leads to tight coupling of interfaces and applica-
tions. In an RPC environment, each application needs to know the intimate
details of the interface of every other application—the number of methods
it exposes and the details of each method signature it exposes. This figure
clearly shows that the synchronized nature of RPC tightly couples the cli-
ent to the server. The client cannot proceed—it is blocked—until the server
responds, and the client fails if the server fails or is unable to complete. This
can be understood by the fact that when performing a synchronous opera-
tion across multiple processes, the success of one RPC call depends on the
success of all downstream RPC-style calls that are part of the same synchro-
nous request/response cycle. This makes the invocation a whole-or-nothing