Download Lecture 5d, RPC

RPC
RPC
RPC
Remote 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
History and origins
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.
RPC
History and origins (concluded)
.
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.
RPC
Message passing
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.
RPC
Locals vs. Remotes
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.
RPC
Standard contract mechanisms
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.
RPC
Java Remote Method Invocation API
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).
RPC
CORBA vs. RMI
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.
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 Disadvantages
Serialization, 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 serialization
In 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 support
Several 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
Java
Java 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.
RPC
Transient
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.
Example
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);
RPC
Example (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");
RPC
RPC
Advantages 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.
RPC
Remote 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.
RPC
Remote 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.
RPC
Designing 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.
RPC
Remote 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.
RPC
Implementing 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
RPC
Providing 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();
}
RPC
Passing 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.
RPC
Making 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.
RPC
XML-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.
RPC
History - 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]
RPC
XML-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
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).
RPC
REST
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-server
Stateless
Cacheable
Layered
RPC
REST- Simplicity
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.
RPC
REST's central principle: resources
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).
RPC
HTTP and REST
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.
RPC
REST versus 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
RPC
Summary
We use Serialization to make remote calls.
XML May be used for Serialization.
Serialization is expensive.