B2B Integration : A Practical Guide to Collaborative E-commerce

Transport and semantics
Integration Patterns 87
The RPC protocol is completely independent of the transport protocols,
i.e., the client can invoke RPC calls on the server irrespective of the
transport protocol on which the RPC service runs. It deals only with the
specifications and interpretations of messages and does not take into
account the manner and way in which the messages are exchanged
between the client and the server applications. Based on this
independence from transport protocols, RPC protocol does not enforce
any kind of semantics to the invocation or execution of a remote
procedure. The semantics are explicitly declared by the transport protocol.
Thus, client and server applications have to be aware of the transport
protocol underneath RPC, as RPC service can run on a reliable protocol
(such as TCP/IP) or an unreliable (UDP) protocol.
Benefits of RPCs
The biggest advantage of RPCs is their relative simplicity. Though the
procedure is executed on a remote machine, it appears to the developer
that it has been executed locally. Developers are removed from the
complexities, which exist in other middleware solutions, most notably,
distributed object models.
Unlike the wild-west approach to APIs, comprehensive industry
standards have been developed for RPCs. The most notable is the
Distributed Computing Environment (DCE) standard created by the
Open Software Foundation (OSF) in the 1980s. DCE is an industrystandard,
vendor-neutral set of distributed computing technologies. The
DCE standard for RPCs provides a complete distributed computing
environment infrastructure including a security service to protect and
control access to data, name services that make it easy to find distributed
resources and a highly scalable model for organizing widely scattered
users, services and data.
Limitations of RPCs
Though incredibly popular during the 80s and early 90s, RPCs have
lost favor as a middleware solution to other technologies, such as