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

proposition. If one operation is unable to complete for any reason, all other
dependent operations will fail with it.
Remote procedure calls are also a client/server infrastructure intended
to enable and increase interoperability of applications over heterogeneous
platforms. Similar to MOM, it enables communication between software
on different platforms and hides almost all the details of communication.
RPC is based on procedural concepts—developers use remote procedure
or function calls. The first implementations date back to the early 1980s.
The main difference between MOM and RPC is the manner of communica-
tion. While MOM supports asynchronous communication, RPC promotes
synchronous, request-reply communication (sometimes referred to as call/
wait ), which blocks the client until the server fulfills its requests. To achieve
remote communication, applications use procedure calls; RPC middleware
hides all communication details, which makes using remote procedure
calls very similar to local procedure calls.
RPC guards against overloading a network, unlike the asynchronous
mechanism, MOM. There are a few asynchronous implementations avail-
able, but they are more the exception than the rule. RPC increases the flex-
ibility of architecture by allowing a client of an application to employ a
function call to access a server on a remote system. RPC allows the remote
access without knowledge of the network address or any other lower-level
information. The semantics of a remote call is the same whether or not the
client and server are collocated. RPC is appropriate for client/server applica-
tions in which the client can issue a request and wait for the server to return
a response before continuing with its own processing. On the other hand,
RPC requires that the recipient be online to accept the remote call. If the
recipient fails, the remote calls will not succeed, because the calls will not be
temporarily stored and then forwarded to the recipient when it is available
again, as is the case with MOM.
RPC is often connected with the Distributed Computing Environment
(DCE), developed by the Open Systems Foundation (OSF). DCE is a set of
integrating services that expand the functionality of RPC. In addition to
RPC, the DCE provides directory, time, security, and thread services. Over
these fundamental services, it places a layer of data-sharing services, includ-
ing distributed file system and diskless support. Technologies that predomi-
nantly use RPC-style communication include the Common Object Request
Broker Architecture (CORBA), the Java Remote Method Invocation (RMI),
DCOM, Active X, Sun RPC, Java API for XML-RPC (JAX-RPC), and the Simple
Object Access Protocol (SOAP) v1.0 and v1.1. Component-based architectures
such as EJB are also built on top of this model. However, due to their syn-
chronous nature, RPCs are not a good choice to use as the building blocks for
enterprise-wide applications where high performance and high reliability
are needed. The synchronous tightly coupled nature of RPCs is a severe hin-
drance in system-to-system processing where applications need to be inte-
grated together. Under synchronous solutions, applications are integrated by