Distributed Program Construction

Fall 1999

Lecture 5: RMI, CORBA

COMP 413

Remote Method Invocation (RMI)

An object-oriented (Java-specific) extension of RPC
Concept: view of the distributed system as a collection of interacting encapsualted (remote) objects providing (remote) interfaces for access to otherwise private state and behavior
Mechanism: clients obtain references to remote objects and invoke methods on them

Design Goals:

Seamless method invocation on objects that reside in different VMs
Integrate RMI naturally with the language

no external IDL
Retain most of Java's object semantics

But, make the difference between dist. and local object model apparent
Assist in building reliable applications
Preserve Java's safety

Extensibility to support

Multiple transport protocols
Various reference semantics (persistent, lazy activation)
Various invocation mechanisms (uni/multi)

Problems (like in RPC)

different memory spaces
parameter passing
binding
failures

Additional Issues:

Distributed garbage collection
Distributed class loading

COMP 413

Distributed Object Model

Definitions:

remote object - an object whose methods can be invoked from another Java Virtual Machine
remote interface - a Java interface that declares the methods of a remote object. A remote object may be described by multiple remote interfaces
remote method invocation (RMI) - the action of invoking a method of a remote interface on a remote object.

RMI has the same syntax as a local method invocation.

Similarity with local objects:

A reference to a remote object can be passed as an argument or returned as a result in any method invocation (local or remote).
A remote object can be cast (with Java casting) to any of the set of remote interfaces supported by its implementation
The instanceof operator can be used to test the remote interfaces supported by a remote object.

Difference from local objects:

Clients of remote objects can interact only with remote interfaces, not with implementation classes
Nonremote arguments to, and results from, a remote method invocation are passed by value rather than by reference
Mandatory remote excpetions must be declared/defined
Some of the Object methods are overriden

COMP 413

Remote Interfaces and Classes

public interface BankAccount extends Remote
{
public void deposit (float amount)
        throws java.rmi.RemoteException;
public void withdraw (float amount)
        throws OverdrawnException, java.rmi.RemoteException;
public float balance()
        throws java.rmi.RemoteException;
}

Each method must declare java.rmi.RemoteException

Thrown by the runtime when the remote invocation failes (e.g., network failure)

A remote object passed as an argument or return value (either directly or embedded within a local object) must be declared as the remote interface, not the implementation class.

Remote class hierarchy

RemoteObject - Remote semantics of class Object
RemoteServer - abstract specification of remote reference: object creation and exporting
Subclasses of RemoteServer - concrete semantics of remote reference. Example: UnicastRemoteObject defines a singleton remote object whose references are valid only while the server process is alive.

COMP 413

Implementing a Remote Interface

Extend java.rmi.server.UnicastRemoteObject (or other remote implementation class)
Implement at least one remote interface
Can define methods that do not appear in the remote interface, but those methods can only be used locally.

package my_package;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class BankAccountImpl extends UnicastRemoteObject implements BankAccount
{
   public void deposit (float amount) throws RemoteException {
                ...
   }
   public void withdraw (float amount) throws OverdrawnException, RemoteException {
                ...
}
public float balance() throws RemoteException {
                ...
        }
}

Invocation of Remote Methods

Clients interact with stub objects with exactly the same set of remote interfaces defined by the remote class
Stubs (generated by rmic compiler) implement the remote interfaces - they have the same type as remote objects! (can use instanceof and casting)
Caller of a remote method must be prepared to handle RemoteException

try {
BankAccount acct = (BankAccount)java.rmi.Naming.lookup(url);
balance = acct.balance();
} catch (Exception e) {
System.out.println("Bank exception: " + e.getMessage());
e.printStackTrace();
}

COMP 413

Parameter Passing

An argument to, or a return value from, a remote object can be any Java type that is serializable.

primitive types, remote objects, and objects that implement the java.io.Serializable interface
if parameter (or referenced objects) is not serializable, an exception is raised.

A nonremote object is passed by value

Content copied to a new object before invocation on the remote object (parameter) or after invocation (return value)
static and transient fields are not copied

For a remote object, its stub object is passed.

A remote object passed as a parameter can only implement remote interfaces.

Based on Java Serialization

COMP 413

Serialization

A general mechanism to store and retrieve objects, by representing their state in a serialized form sufficient to reconstruct the object.
When object is stored, all objects that are reachable from it are stored as well.
Automatic default serialization is provided !

Serliaizable is an empty interface - signaling if an object wants to get serliazied
implementation via writeObject and readObject

// serialize today's date to a file
FileOutputStream f = new FileOutputStream("tmp");
ObjectOutputStream s = new ObjectOutputStream(f);
s.writeObject("Today");
s.writeObject(new Date());
s.flush();

// Deserialize a string and date from a file.
FileInputStream in = new FileInputStream("tmp");
ObjectInputStream s = new ObjectInputStream(in);
String today = (String)s.readObject();
Date date = (Date)s.readObject();

A Serializable object:

Must implement the java.io.Serializable interface.
Must mark fields whose values should not persist with the transient keyword.
Can implement a writeObject/readObject methods to control what information is saved/read to/from the stream and perform additional operations

Evolution support - new classes that are compatible with old classes can be used to read stored objects.

COMP 413

Steps in creating an RMI program

Define a remote interface
Write an implementation class
Write a client that uses the remote service (e.g., an Applet)

1. Characteristics of a remote interface

Must be public - otherwise (remote) client would fail, since physically they belong to different classes
extends java.rmi.Remote
Each method must throw a java.rmi.RemoteException (to ensure stubs's exceptions are caught and handled) - enforced by Remote interface
A remote object passed as argument or return value must be declared as the remote interface
Example:

package examples.hello;

public interface Hello extends java.rmi.Remote {

String sayHello() throws java.rmi.RemoteException;

}

COMP 413

Step 2: Implementation Class

Specify the remote interface(s) implemented
Export remote object (listen for incoming requests) by

extending a concrete Remote class
explicitly invoke an export method of the Remote class (useful when remote object already extends some other class) - UnicastRemoteObject.exportObject

define constructor - regularly
provide implementations for remotely invokable methods
create and install a security manager (for class loading)
instanatiate an object - calls export
register the object with the RMI registry

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
public class HelloImpl extends unicastRemoteObject implements Hello {
private String name;
public HelloImpl(String s) throws RemoteException {
super(); // just for clarity, java does it automatically
name = s;
}
public String sayHello() throws RemoteException {
    return "Hello World";
}
public static void main(String args[])
{
   System.setSecurityManager(new RMISecurityManager());
    try {
      HelloImpl obj = new HelloImpl("HelloServer");
      Naming.rebind("//tochna11/HelloServer",Obj);
      System.out.println("HelloServer bounda in registry");
      } catch (Exception e) {
        System.out.println("HelloImpl err: " + e.getMessage());
        e.printStackTrace();
      }
    }
} /* end of class */

COMP 413

Step 3: Call a Remote Service

Get a reference to the remote object by looking up the registry

construct the URL - need hostname and object name
In case of an applet, can use getCodeBase().getHost
if hostname is ommited, client defaults to local host (but for an applet, the security manager will raise an exception !)
returned value is actually a reference to a local stub object that implements the same remote interface
since lookup returns generic Remote objects, returned value is cast to the interface type

Invoke remote methods

     import java.awt.*;
    impot java.rmi.*;
    public class HelloApplet extends java.applet.Applet
    {
     String message = "";
     public void init() {
     try {
          Hello obj = (Hello)Naming.lookup("//" +
                getCodeBase().getHost() + "/HelloServer")
                             message = obj.sayHello();
         } catch (Exception e) {
         System.out.println("HelloApplet Exception: " +
                             e.getMessage());
         e.printStrackTrace();
        }
    }
    public void paint(Graphics G) {
        g.drawString(message, 25, 50);
    }
   }

COMP 413

Step 4: HTML that wraps Applet

For an applet to be downloaded, there needs to be an HTTP server running, and applet should reside in its codebase
need to specify the class name of the applet (fully qualified)

<HTML>
<title>Hello World</title>
<center> <h1> Hello World</h1> </center>

The message from the HelloServer is:
   <p>
<applet codebase="../.."
      code="examples.hello.HelloApplet"
      width=500 height=120>
   </applet>
   </html>

Step 5: COMPILE AND DEPLOY

compile all sources with a Java compiler
generate stub and skeleton by invoking the rmi compiler (rmic) on the classes that contain remote object implementations

rmic generates myclass_Skel.class and myclass_Stub.class
need to create "Make-like" dependency between class file and rmi-generated classes to ensure consistentcy

move html and applet proper "deployable" locations

Step 6: Run

Start the rmiregistry
Start the remote object - specify java.rmi.codebaseproperty
Run the applet

COMP 413

System Architecture

3 independent layers:

Stub-skeleton layer - client stubs and server skeletons
Remote reference layer - Semantics of remote reference
Transport layer - connection set up, management and object tracking

Stub-skeleton Layer

Interface to applications. Stub functions:

Initiating a call to the remote object (via remote reference layer).
Marshaling arguments (using serialization)
Informing the remote reference layer that the call should be invoked.
Unmarshaling the return value or exception from a marshal stream.
Informing the remote reference layer that the call is complete.

Skeleton functions:

Unmarshaling arguments from the marshal stream.
Making the up-call to the actual remote object implementation.
Marshaling the return value of the call or an exception (if one occurred) onto the marshal stream.

Stub and skeleton (bytecode) generated by RMI compiler (rmic)

COMP 413

Remote Reference Layer

An object implementation selects a specific remote reference sub-class. Examples :

Unicast point-to-point invocation
Invocation to replicated object groups (multiple servers)
Support for a user-defined replication/redirection strategy.
Support for a persistent reference to the remote object (enabling activation of the remote object).
Reconnection strategies (if remote object becomes inaccessible).

client-side - information on invocation according to specified remote reference semantics.
server-side - implements the specific remote reference semantics prior to invoking the skeleton (e.g., atomic multicast delivery)
data is transmitted from stub-skeleton to transport layer (and vice-versa) via connecction-oriented stream abstraction
a connectionless transport (UDP) can be implemented underneath

COMP 413

"Transport Layer"

Functions:

Setting up and managing connections
Monitoring connection "liveness."
Listening for incoming calls.
Maintaining a table of remote objects that reside in the address space.
Setting up a connection for an incoming call.
Locating the dispatcher for the target of the remote call and passing the connection to this dispatcher.

Abstractions:

endpoint - denotes an address space or Java virtual machine.
channel - manages connection between local and remote address spaces
connection - transfer data
transport - channel managment

COMP 413

Dynamic Class Loading

RPC typically requires the existence of pre-compiled stubs and skeletons. They may be linked statically or dynamically
RMI uses a special RMIClassLoader that loads at runtime the (possibly remote) classes required for remote invocations:

Stub and skeleton classes
Parameters or return values (passed by copy)

RMIClassLoader looks for, in listed order:

Local CLASSPATH
parameters/return values (both remote and nonremote) - use URL encoded in the marshal stream that contains the serialized object

Stubs and skeletons of remote objects created in the local virtual machine - use URL specified by the local java.rmi.server.codebase property

With useCodebaseOnly property set, no remote loading is allowed

COMP 413

Locating Remote Objects

A remote object registers itself with a URL-based name in a name-server called rmiregistry.

object URL is rmi://hostname:port/server-name

Registry used for client bootstraping to get the initial reference
Subsequent remote references are obtained as return values from other (remote) invocations
Registry is itself implemented as a remote object

java.rmi.Naming provides remote methods for lookup,bind,rebind, unbind and list name-object pairs given host + port

Example:

   BankAccount acct = new BankAcctImpl();
   String url = "rmi://java.Sun.COM/account";
   // bind url to remote object
   java.rmi.Naming.bind(url, acct);
...
   // lookup account
   acct = (BankAccount)java.rmi.Naming.lookup(url);

COMP 413

CORBA

CORBA (Common Object Request Broker Architecture):

An industry standard for distributed object computing, developed by Object Management Group (OMG).
Centered around interoperability (programming language, object model, and framework facilities).
Provides a set of common services (COS) and facilities (e.g., naming, transactions, message queuing, events, security).
To use CORBA, you need a specific implementation (e.g., Orbix by IONA, Visibroker by Inprise; Sun jdk and Netscape browser contain basic support).
In theory, different implementations are interoperable.

How does CORBA differ from RMI:

RMI is Java-only.
RMI is not an industry standard (it is a product of Sun).
RMI does not provide such a rich set of services and facilities.
RMI is simpler to use and integrates smoothly with Java.
RMI and CORBA can be used together. (Soon - RMI over IIOP will make this very simple.)

COMP 413

Deployment of CORBA Applications

COMP 413

CORBA ORB Architecture

Object Implementation -- This defines operations that implement a CORBA IDL interface. Object implementations can be written in a variety of languages including C, C++, Java, Smalltalk, and Ada.

Client -- This is the program entity that invokes an operation on an object implementation.

Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.

ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB.

CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler.

Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.

Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

COMP 413

Development Process

COMP 413

CORBA IDL

Intro:

A language for specifying distributed object interfaces.
Does not assume any specific implementation language.
A non-operational language, unlike programming languages.

A nested namespace:

module services {
interface inter1{
long action();
};
interface inter2 {
inter1 get_inter1();
};
};

get_inter1 is actually services::inter2::get_inter1().
modules can be nested.

Parameter passing:

CORBA objects are passed by (remote) reference.
Other types: in, out, inout.

Basic data types:

short / ushort, long / ulong, longlong / ulonglong, float, double, char, boolean.
string - variable length string. Can be bounded: string<10>.

Constants:

const long my_const = 10;
const string message = "Hello!";

COMP 413

CORBA IDL (Cont.)

Type declarations:

typedef T1 T2
enum test_grade {pass, fail};
struct and union - as in C.

struct car {
string manufacturer;
long velocity;
};

Arrays:

Declared using typedef. (Can appear without typedef inside a struct or a union).

typedef long[10] my_array;

Exceptions:

Declaration similar to that of struct

exception FileNotFound {

string filename;

string reason;

};

(Possibly multiple) inheritance of interfaces:

interface A : B, C {

};

The special type Any:

Represents an object of any type.

COMP 413