RPC

RPC

RPCRemote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

RPC

Goal

That is, the programmer would write essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question is written using object-oriented principles, RPC may be referred to as remote invocation or remote method invocation.

RPC

The idea of RPC goes back at least as far as 1976, when it was described in RFC 707. One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Sun's NFS. ONC RPC is still widely used today on several platforms.

Another early Unix implementation was Apollo Computer's Network Computing System (NCS). NCS later was used as the foundation of DCE/RPC in the OSF's Distributed Computing Environment (DCE). A decade later Microsoft adopted DCE/RPC as the basis of their Microsoft RPC (MSRPC) mechanism, and implemented DCOM atop it. Around the same time (mid-90's), Xerox PARC's ILU, and the Object Management Group's CORBA, offered another RPC paradigm based on distributed objects with an inheritance mechanism.

History and origins

RPC

.

Another early Unix implementation was Apollo Computer's Network Computing System (NCS). NCS later was used as the foundation of DCE/RPC in the OSF's Distributed Computing Environment (DCE). A decade later Microsoft adopted DCE/RPC as the basis of their Microsoft RPC (MSRPC) mechanism, and implemented DCOM atop it. Around the same time (mid-90's), Xerox PARC's ILU, and the Object Management Group's CORBA, offered another RPC paradigm based on distributed objects with an inheritance mechanism.

History and origins (concluded)

RPC

RPC is an obvious and popular paradigm for implementing the client-server model of distributed computing. An RPC is initiated by the client sending a request message to a known remote server in order to execute a specified procedure using supplied parameters. A response is returned to the client where the application continues along with its process. There are many variations and subtleties in various implementation, resulting in a variety of different (incompatible) RPC protocols. While the server is processing the call, the client is blocked.

Message passing

RPC

An important difference between remote procedure calls and local calls is that remote calls can fail because of unpredictable network problems. Also, callers generally must deal with such failures without knowing whether the remote procedure was actually invoked. Idempotent procedures (those which have no additional effects if called more than once) are easily handled, but enough difficulties remain that code which calls remote procedures is often confined to carefully written low-level subsystems.

Locals vs. Remotes

RPC

In order to allow servers to be accessed by differing clients, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to allow various platforms to call the RPC.

The IDL files can then be used to generate code to interface between the client and server. The most common tool used for this is RPCGEN.

Standard contract mechanisms

RPC

The Java Remote Method Invocation API, or Java RMI, is a Java application programming interface for performing the object equivalent of remote procedure calls.There are two common implementations of the API. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP).

Java Remote Method Invocation API

RPC

The original RMI API was generalized somewhat to support different implementations, such as an HTTP transport. Additionally, work was done to CORBA, adding a pass by value capability, to support the RMI interface. Still, the RMI-IIOP and JRMP implementations are not fully identical in their interfaces.

CORBA vs. RMI

RPC

java.rmi

The package name is java.rmi while most of Sun's implementation is located in the sun.rmi package. Note that with Java versions before Java 5.0 it was necessary to compile RMI stubs in a separate compilation step using rmic. Version 5.0 of Java and beyond no longer require this step

RPC

jini

A more advanced version of RMI in Java is Jini - it is similar but provides more advanced searching capabilities and mechanisms for distributed object applications, Objects received are “live” and the protocol is more “free form”.

RPC

Serialization

In computer science, in the context of data storage and transmission, serialization is the process of saving an object onto a storage medium (such as a file, or a memory buffer) or to transmit it across a network connection link in binary form. When the resulting series of bytes is reread according to the serialization format, it can be used to create an accurate clone of the original object.

RPC

Marshalling and Unmarshalling

This process of serializing an object is also called deflating or marshalling an object. The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also called inflating or unmarshalling).

RPC

Serialization Advantages

Serialization has a number of advantages. It provides:

a method of persisting objects which is more convenient than writing their properties to a text file on disk, and re-assembling them by reading this back in. a method of issuing remote procedure calls, e.g., as in SOAP a method for distributing objects, especially in software componentry such as COM, CORBA, etc. a method for detecting changes in time-varying data.

RPC

Serailizazation DisadvantagesSerialization, however, breaks the opacity of an abstract data type by potentially exposing private implementation details. To discourage competitors from making compatible products, publishers of proprietary software often keep the details of their programs' serialization formats a trade secret. Some deliberately obfuscate or even encrypt the serialized data. This process is often termed "instantated oatmealization" by the open source community, a pun on the homophony of serialization and cereal. cite_ref-oatmeal_0-0cite_ref-oatmeal_0-0[1]

RPC

Human-readable serializationIn the late 1990s, a push to provide an alternative to the standard serialization protocols started: the XML markup language was used to produce a human readable text-based encoding. Such an encoding can be useful for persistent objects that may be read and understood by humans, or communicated to other systems regardless of programming language. It has the disadvantage of losing the more compact, byte stream based encoding, which is generally more practical. XML is today often used for asynchronous transfer of structured data between client and server in Ajax web applications.

RPC

Programming language supportSeveral object-oriented programming languages directly support object serialization (or object archival), either by syntactic sugar elements or providing a standard interface for doing so.

Some of these programming languages are Ruby, Smalltalk, Python, PHP, Objective-C, Java, and the .NET family of languages.

There are also libraries available that add serialization support to languages that lack native support for it.

RPC

JavaJava provides automatic serialization which requires that the object be marked by implementing the java.io.Serializable interface. Implementing the interface marks the class as "okay to serialize," and Java then handles serialization internally. There are no serialization methods defined on the Serializable interface, but a serializable class can optionally define methods with certain special names and signatures that if defined, will be called as part of the serialization/deserialization process. The language also allows the developer to override the serialization process more thoroughly by implementing another interface, the Externalizable interface, which includes two special methods that are used to save and restore the object's state.

RPCTransient

There are three primary reasons why objects are not serializable by default and must implement the Serializable interface to access Java's serialization mechanism.

Not all objects capture useful semantics in a serialized state. For example, a Thread object is tied to the state of the current JVM. There is no context in which a deserialized Thread object would maintain useful semantics. The serialized state of an object forms part of its class's compatibility contract. Maintaining compatibility between versions of serializable classes requires additional effort and consideration. Therefore, making a class serializable needs to be deliberate design decision and not a default condition.

RPCExample

import java.io.*; /** * The object to serialize. */class ObjectToSerialize implements Serializable { static private final long serialVersionUID = 42L; public ObjectToSerialize(String firstAttribute, int secondAttribute) { this.firstAttribute = firstAttribute; this.secondAttribute = secondAttribute; } @Override public String toString() { return firstAttribute + ", " + secondAttribute; } private String firstAttribute; private int secondAttribute;} public class Main { /** * Save an object. */ private static void save_object(Serializable object, String filename) throws IOException { ObjectOutputStream objstream = new ObjectOutputStream(new FileOutputStream(filename)); objstream.writeObject(object); objstream.close(); }

RPCExample (Concluded)

/** * Load an object. */ private static Object load_object(String filename) throws Exception { ObjectInputStream objstream = new ObjectInputStream(new FileInputStream(filename)); Object object = objstream.readObject(); objstream.close(); return object; } public static void main(String[] args) { ObjectToSerialize o = new ObjectToSerialize("Object", 42); System.out.println(o); try { save_object(o, "object.ser"); ObjectToSerialize object_loaded = (ObjectToSerialize) load_object("object.ser"); System.out.println(object_loaded); } catch (Exception e)

RPCAdvantages of Dynamic Code Loading

One of the central and unique features of RMI is its ability to download the definition of an object's class if the class is not defined in the receiver's Java virtual machine. All of the types and behavior of an object, previously available only in a single Java virtual machine, can be transmitted to another, possibly remote, Java virtual machine. RMI passes objects by their actual classes, so the behavior of the objects is not changed when they are sent to another Java virtual machine. This capability enables new types and behaviors to be introduced into a remote Java virtual machine, thus dynamically extending the behavior of an application.

RPCRemote Interfaces, Objects, and Methods

Like any other Java application, a distributed application built by using Java RMI is made up of interfaces and classes. The interfaces declare methods. The classes implement the methods declared in the interfaces and, perhaps, declare additional methods as well. In a distributed application, some implementations might reside in some Java virtual machines but not others. Objects with methods that can be invoked across Java virtual machines are called remote objects.

RPCRemote Interface

An object becomes remote by implementing a remote interface, which has the following characteristics:

A remote interface extends the interface java.rmi.Remote. Each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.

RPCDesigning a Remote Interface

At the core of the compute engine is a protocol that enables tasks to be submitted to the compute engine, the compute engine to run those tasks, and the results of those tasks to be returned to the client. This protocol is expressed in the interfaces that are supported by the compute engine.

RPCRemote Example

package compute;

import java.rmi.Remote;import java.rmi.RemoteException;

public interface Compute extends Remote { <T> T executeTask(Task<T> t) throws RemoteException;

}

By extending the interface java.rmi.Remote, the Compute interface identifies itself as an interface whose methods can be invoked from another Java virtual machine. Any object that implements this interface can be a remote object.

RPCImplementing a Remote Interface

This section discusses the task of implementing a class for the compute engine. In general, a class that implements a remote interface should at least do the following:

Declare the remote interfaces being implemented Define the constructor for each remote object Provide an implementation for each remote method in the remote interfaces

RPCProviding Implementations For Remote

The class for a remote object provides implementations for each remote method specified in the remote interfaces. The Compute interface contains a single remote method, executeTask, which is implemented as follows:

public <T> T executeTask(Task<T> t) { return t.execute();}

RPCPassing Objects in RMI

The rules governing how arguments and return values are passed are as follows:

Remote objects are essentially passed by reference. A remote object reference is a stub, which is a client-side proxy that implements the complete set of remote interfaces that the remote object implements. Local objects are passed by copy, using object serialization. By default, all fields are copied except fields that are marked static or transient. Default serialization behavior can be overridden on a class-by-class basis.

RPCMaking the Remote Object Available

Compute stub =

(Compute) UnicastRemoteObject.exportObject(engine, 0);

The static UnicastRemoteObject.exportObject method exports the supplied remote object so that it can receive invocations of its remote methods from remote clients. The second argument, an int, specifies which TCP port to use to listen for incoming remote invocation requests for the object. It is common to use the value zero, which specifies the use of an anonymous port. The actual port will then be chosen at runtime by RMI or the underlying operating system. Once the exportObject invocation has returned successfully, the ComputeEngine remote object is ready to process incoming remote invocations.

RPCXML-RPC

XML-RPC is a remote procedure call protocol which uses XML to encode its calls and HTTP as a transport mechanism.

XML-RPC is a very simple protocol, defining only a handful of data types and commands, and the entire description can be printed on two pages of paper. This is in stark contrast to most RPC systems, where the standards documents often run into the hundreds of pages and require considerable software support in order to be used.

RPCHistory - XML-RPC

XML-RPC was first created by Dave Winer of UserLand Software in 1998 with Microsoft.[citation needed] As new functionality was introduced, the standard evolved into what is now SOAP.

XML-RPC was patented by Phillip Merrick, Stewart Allen, and Joseph Lapp in April 2006, claiming benefit to a provisional application filed in March 1998. The patent is assigned to webMethods, located in Fairfax, VA. [3]

RPCXML-RPC

<?xml version="1.0"?><methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>40</i4></value> </param> </params></methodCall>

An example of a typical XML-RPC response would be:

<?xml version="1.0"?><methodResponse> <params> <param> <value><string>South Dakota</string></value> </param> </params></methodResponse>

RPC

SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.As a layman's example of how SOAP procedures can be used, a correctly formatted call could be sent to a Web Service enabled web site - for example, a house price database - with the data ranges needed for a search. The site could then return a formatted XML document with all the required results and associated data (prices, location, features, etc).

SOAP

RPC

Application state and functionality are abstracted into resources Every resource is uniquely addressable using a universal syntax for use in hypermedia links All resources share a uniform interface for the transfer of state between client and resource, consisting of A constrained set of well-defined operations A constrained set of content types, optionally supporting code on demand A protocol which is: Client-serverStatelessCacheable Layered

REST

RPC

REST’s client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive.

REST- Simplicity

RPC

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (clients and servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information).

REST's central principle: resources

RPC

We may link HTTP verbs with similar database operations, however the meaning of the HTTP verbs do not correspond directly with a single database operation. For example, an HTTP PUT is used to set the value of a resource and may result in either a creation or replacement as needed.

HTTP and REST

RPC

The statements below refer to REST in the context of Web Services, specifically as opposed to SOAP.

REST Resources—Commands are defined in simple terms: resources to be retrieved, stored / get, set—difficult to do many joins RPC Commands—Commands are defined in methods with varying complexity: depending on “standard”—easier (?) to hide complex things behind a method REST Nouns—Exchanging resources and concepts RPC Verbs—Exchanging methods

REST versus RPC

RPC

We use Serialization to make remote calls.

XML May be used for Serialization.

Serialization is expensive.

Summary