the RPC Way to Interop With Remote Process

When we say "interop with remote process", people may think "oh, its just remote ipc, which is actually network communication". Yes, it's network communication, but not that easy as it may seem at the first sight.

Besides raw socket mechanism, there are many well defined styles in which a process can communicate with remote processes: Named Pipe, Mailslot are those that are available on Windows platform.

In this article, I will focus on another specific remote IPC mechanism: Remote Procedure Call - communicating with remote process as method call.

1. Why people invent RPC?

When physical network communication comes true in computer world, software designer starts to think how to provide a software interface to these great facility.

Raw socket abstraction is the first step, it is powerful but too low-level - you see connection/listen/accept/byte stream. Networking is for remote IPC, but remote IPC semantic is far more rich than just connection and raw byte stream.

So here comes the invention of RPC. According to the earliest paper, the main motivation behind the design of RPC is - procedure call is a well-known and well-understood mechanism/semantic, making it work among remote computers will make distributed system easier to be built and get right.

2. What problems should RPC solve?

Key problems:

-1]. Binding Remote Methods(A.K.A. identifying/naming/addressing/locating). It concerns with two fundamental problems: how to let caller specify which callee to communicate (Naming)? how to let caller find the physical address(network address/port/process ID etc) of the callee (Locating)?

-2]. Data Unmarshall/Marshall. It concerns how caller encode its data types (in some programming language) into byte stream and how callee decode byte stream into its desired data types (may be in another programming language on another platform). It is typically called Message Encoding. More recently, there is also a related problem - Message Formatting, which define how the message between client/server is layoutted.

-3]. Message Transporting. It concerns how to send/receive data stream, for example, how to manage connection, congestion, failure and time out etc.

Every RPC mechanism has specific solution to these problems.

Basic Components for RPC system:
- Client Code
- Client Stub
- RPC runtime (at both client and server side)
- Server Stub
- Server Code

3. What are the popular RPC system today?

Function Oriented - classic RPC
- Distributed Computing Environment by HP, IBM, DEC and others
- Open Network Computing by SUN
- MSRPC by Microsoft, it's a modification to DCE/RPC and MSRPC is widely used in DCOM, which could be regarded as MSRPC + COM.

Object Oriented - OO RPC
- .Net Remoting by Microsoft
- Java Remote Method Invocation by Sun
- DCOM: Distributed COM by Microsoft
- COBRA: Common Object Request Broker Architecture by Object Management Group
- Jini - Advanced Java RMI by Sun

HTTP/XML Oriented - Web Service
- XML-RPC, xml as data representation and http as transport channel
- JSON-RPC, JSON as data representation, http/socket as transport channel
- SOAP WS, (A.K.A big web service) xml with strong schema as data/message representation, http/smtp/tcp etc as transport layer, security/transaction related protocols (so called WS-*) are added to support enterprise application
- RESTful WS, xml/json/...(flexible) as data encoding, simple & flexible message format, http as transport channel, http method & uri to represent action and stateless in communication

4. Other stuff that matters

The Extensive Adoption of XML

Advantages of using XML
- software that marshall to, unmarshall from xml is easy to get
- text based data representing, easy to read(but why should we read those data?)
- it's flexible and easy to extend

Disadvantages of using XML
- high computing/memory cost
- high cost of communication

The Extensive Adoption of HTTP

- In fact, the HTTP is not a general purpose communication facility by design. The initial motivation to adopt HTTP as transport channel in web service protocols is to communicate through Internet firewalls.

Many criticisms say that HTTP/XML is abused in today's web-scale distributed systems. Yes, these technologies are used in a way other than the initial target, but very few innovations are created as planned, rather, many great inventions are just happy accidents. HTTP/XML may not be the best technologies, but they do be the most successful ones in web world.

Windows Communication Foundation

WCF by no means invents any new communication protocol. It is just a programming framework that implements existing protocols on .Net platform. The main contribution of WCF is that it uniforms various communication protocols(SOAP, WSE, .Net Remoting, Message Queue, JSON-RPC and REST etc.) into one programming model in .Net framework.


Remote Procedure Call
Wiki about RPC - http://en.wikipedia.org/wiki/Remote_procedure_call
RFC about RPC - http://tools.ietf.org/html/rfc707
RPC Tutorial - http://www.cs.cf.ac.uk/Dave/C/node33.html
RPC Implementation - http://pages.cs.wisc.edu/~cs736-1/papers/rpc.pdf
DCE RPC - http://www.opengroup.org/dce/
SUN RPC - http://www.onc-rpc-xdr.com/
MS RPC - http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx

Web Service
The SOAP/XML-RPC/REST Saga, http://www.tbray.org/ongoing/When/200x/2003/05/12/SoapAgain
History of SOAP, http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html
XML-RPC, http://www.xmlrpc.com
SOAP Tutorial, http://www.w3schools.com/soap/default.asp
Build WS the REST way, http://www.xfront.com/REST-Web-Services.html

No comments: