Integrative Programming and

Technologies
Mettu University, Department of Information
Technology
4th Year
Chapter 2 – Inter system Communication
Prepared by: Sridhar.U
 RMI
(Remote Method Invocation)
 Introduction
In the traditional client/server model, the client
translates the request to an intermediary transmission
format and sends the request to the server. The server
parses the request format, computes the response and
formats the response for transmission to the client. The
client then parses the response and displays it to the
user.

If you implement this approach by hand, there is a

significant coding hassle: you have to design a
transmission format, and you have to write code for
conversation between your data and the transmission format.

What we want is a mechanism by which the client

programmer makes a regular method call, without worrying
about sending data across the network or parsing the
response.
 Introduction cont..
The solution is to install a proxy for the server
object on the client. The client calls the proxy making a
regular method call. The client proxy contacts the server.
Similarly the programmer of the server object
doesn’t want to fuss with client communication. The
solution is to install a second proxy object on the server.
The server proxy communicates with the client proxy, and it
makes regular method calls to the sever object.
 Introduction cont..
Client Proxy Proxy Server

Call Proxy Locally

Send request data
Call server method locally

Return method result

Return response data

Return method result
 Implementation Technologies
 RMI, the Java Remote Method Invocation technology,
supports method calls between distributed Java objects.

 CORBA, the Common Object Request Broker

Architecture, supports method Calls between objects of any
programming language. CORBA uses the Internet Inter-ORB
Protocol, or IIOP, to communicate between objects.

 SOAP, the Simple Object Access Protocol, is also

programming- language neutral. However, SOAP uses an XML-
based transmission format
 Remote Method Invocations
The Remote Method Invocation mechanism lets you do
something that sounds simple. If you have access to an
object on a different machine, you can call methods of
the remote object. Of course, the method parameters must
somehow be shipped to the other machine, the server must
be informed to execute the method, and the return value
must be shipped back. RMI handles these details.

In RMI terminology, the object whose method makes the

remote calls is called the client object. The remote
object is called the server object. It is important to
remember that the client/server terminology applies only
to a single method call. The computer running the Java
code that calls the remote method is the client for that
call, and the computer hosting the object that processes
the call is the server for that call. It is entirely
possible that the roles are reversed somewhere down the
road. The server of a previous call can itself become
the client when it invokes a remote method on a object
residing on another computer
 Stubs and Parameter Marshalling
When client code wants to invoke a remote method on
a remote object, it actually calls an ordinary method on a
proxy object called a stub. The stub resides on the client
machine, not on the server. The stub packages the
parameters used in the remote method into a block of bytes.
This packaging uses a device-independent encoding for each
parameter. For example, in the RMI protocol, numbers are
always sent in big-endian byte ordering, and objects are
encoded with the serialization mechanism.
The process of encoding the parameters is called
parameter marshalling. The purpose of parameter marshalling
is to convert the parameters into a format suitable for
transport from one virtual machine to another.
the stub method consists of
 An identifier of the remote object to be used;

 A description of the method to be called; and

 The marshaled parameters.

 The stub then sends this information to the server

 Skeleton and Parameter UnMarshalling
On the server side, a receiver object performs the
following actions for every remote method call:
 It unmarshals the parameters.

 It locates the object to be called.

 It calls the desired method.

 It captures and marshals the return value or exception

of the call.
 It sends a package consisting of the marshaled return
data back to the stub on the client.
The client stub unmarshals the return value or exception
from the server. This value becomes the return value of the
stub call. Or, if the remote method threw an exception, the
stub rethrows it in the process space of the caller.
 RMI System Architecture

Client Virtual Machine Server Virtual Machine

Client Remote
Object

Skeleton
Stub Server

“Fred”

Registry Virtual Machine

 RMI Flow
1. Server Creates Remote Object
2. Server Registers Remote Object
Server Virtual Machine
Client Virtual Machine
Remote
Client Object
1
Skeleton
Stub Server

“Fred”

Registry Virtual Machine

 RMI Flow
3. Client requests object from Registry
4. Registry returns remote reference(and stub gets created)

Client Virtual Machine Server Virtual Machine

Client Remote
Object

Skeleton
Stub Server
3 4

“Fred”

Registry Virtual Machine

 RMI Flow
5. Client invokes stub method
6. Stub talks to skeleton
7. Skeleton invokes remote object method
Client Virtual Machine Server Virtual Machine
Remote
Client
Object
5 7
6
Skeleton
Stub Server

“Fred”

Registry Virtual Machine

 Creating Remote Objects

 Define a Remote Interface

 extends java.rmi.Remote

 Define a class that implements the Remote Interface

 extends java.rmi.RemoteObject

 or java.rmi.UnicastRemoteObject
 Remote Interface Example

import java.rmi.*;
public interface Adder extends Remote
{
public int add(int x, int y)
throws RemoteException;
}
 Remote Class Example
import java.rmi.*;
import java.rmi.server.*;
public class AdderImpl extends UnicastRemoteObject
implements Adder
{
public AdderImpl() throws RemoteException
{
}
public int add(int x, int y)
throws RemoteException
{
return x + y;
}
}
 Compiling Remote Classes (Diagram)

Adder.java javac Adder.class AdderImpl_Skel.class

(interface) (interface classfile) (skeleton classfile)

AdderImpl.java javac AdderImpl.class rmic

(remote class) (classfile)

AdderImpl_Stub.class
(stub classfile)
 Create the server
 Creates a new instance of the remote object

 Registers it in the registry with a unique name

 That’s it
 RMI Server Example

try {
AdderImpl adder = new AdderImpl();
Naming.rebind("adder", adder);
System.out.println("Adder bound");
}
catch (RemoteException re) {
re.printStackTrace();
}
catch (MalformedURLException me) {
me.printStackTrace();
}
 Creating an RMI Client

 Install a Security Manager

 to protect from malicious stubs

 Find a registry
 use java.rmi.Naming

 Lookup the name, returns a reference

 Cast the reference to the appropriate Remote
Interface
 Just use it!
 RMI URLs

rmi://host[:port]/name
 default port is 1099

 Specifies hostname of registry

 can also use relative URLs

 name only

 assumes registry is on local host

 RMI Client Example

System.setSecurityManager(
new RMISecurityManager());

Adder a
=(Adder)Naming.lookup("adder");

int sum = a.add(2,2);

System.out.println("2+2=" + sum);
 Limitations of RMI
 Java-only
 but you can use JNI on the server

 Uses TCP, not UDP

 At least two sockets per connection
 Untested for huge loads
 RMI vs. COM

 Very similar
 remote interfaces ~ type libraries
 COM is Win32-only (for now)
 What Is RMI in Simple?
 Access to Remote Objects
 Java-to-Java only
 Client-Server Protocol
 High-level API
 Transparent
 Lightweight
 Introduction
What is CORBA?
– CORBA, or Common Object Request Broker Architecture,
is a standard architecture for distributed object
systems. It allows a distributed, heterogeneous
collection of objects to interoperate.

The OMG ?
– The Object Management Group (OMG) is responsible for
defining CORBA. The OMG comprises over 800 companies
and organizations, including almost all the major
vendors and developers of distributed object
technology, including platform, database, and
application vendors as well as software tool and
corporate developers.
 Introduction Cont..
– OMG operates as a non-profit organization aiming at
the standardization of “whatever it takes” to
achieve interoperability on all levels of an open
market for “objects”.
– Initially OMG concentrated in solving one
fundamental problem

1. C++ C++
Windows Windows

2. C++ C++
Windows Linux

3. C++ Java
Windows Linux
 Introduction Cont..
– CORBA products can’t interoperate on an efficient
binary levels.

– Interoperability protocol is OMG’s IIOP,

standardized with CORBA 2.0 in July 1995

– In July 1996 update of the CORBA 2.0 standard an

interworking standard was added. Which specifies the
interworking of CORBA based systems with system
based on Microsoft COM.
 CORBA ARCHITECTURE
 It has 3 parts
– Set of Invocation Interface
– ORB
– Set of object adapters

Language / Implementation Object

/ platform barrier Method 1
…
Obj.m(args) Method n

Invocation
ORB Interface ORB Interface Object Adapter
Interface
 CORBA ARCHITECTURE
 Set of Invocation Interface
 It enables various degrees of late biding. They also
marshals an invocation arguments.
 ORB
 Can locate the receiver object and the invoked
method and transport the arguments.

 Object Adapter
 Unmarshalls the arguments and invokes the requested
method on the receiver object.
 CORBA ARCHITECTURE
 OMG IDL
 For invocation interface and object adapters for
work, two essential requirements need to be met
1. All object interface need to be described in a
common language.
 It enables construction of marshals and
un marshals

2. All language used must have binding to the

common language.
 It allows call from or to a particular
language
 CORBA ARCHITECTURE
 Example for OMG IDL
Module Example{
Struct Date{
Unsigned short day;
Unsigned short month;
Unsigned short year;
}
interface UFO{
readonly attribute unsigned long ID;
readonly attribute string Name;
readonly attribute Date First Contact;
unsigned long contact();
void RegisterContact(Date dateof contact);
}
}
*Note: Once interfaces are expressed in OMG IDL, they can be
compiled using an OMG IDL compiler and deposited in an
interface repository
 CORBA ARCHITECTURE
Interface Repository:
– Every ORB must have an interface repository.
– Compiled interface can be retrieved from the
interface repository.
Object Servants:
– when compiling program fragments that can provide
implementation of such interface, these program
fragments called object servants
– it has been registered with the ORB’s
implementation repository.
– An ORB is capable of loading and starting an object
servant when receiving invocation request for an
object of that servant.
 CORBA ARCHITECTURE
Object Adapter:
 It is responsible for telling an ORB which new
object is severed by which servant.

 Multiple servants can execute in a shared server

environment.

 An object adapter serves as mediator between the

ORB and the servant, providing the ORB with a
consistent interface for interacting with user
code, and being flexible in cooperating with the
servant
 The Basic Object Adapter was introduced with the
first version of CORBA in 1991 and has been
largely unchanged since then.
 In 1998 the BOA specification was deprecated and
replaced by the specification of the Portable
Object Adapter( POA)
 CORBA ARCHITECTURE
Marshaling and Unmarshaling:
– To enable efficient marshaling and unmarshaling of
arguments, an ORB specific OMG IDL compiler must be
used to generate stubs and skeletons.
Stubs (Client - side Proxy):
– A Stub can be instantiated and looks like a local
object, but forwards all invocations trough the ORB
to the real target object
Skeletons (Server - side Stubs):
– A skeletons receives invocations un marshals
arguments, and directly invokes the target method.
– A skeleton also accepts return values, marshals
these, and sends them back to the stubs
 CORBA ARCHITECTURE
DII and DSI:
 Sometimes this binding is too static and the
operation to be invoked needs to be selected at
runtime.

 CORBA provides a dynamic invocation interface

(DII) for this purpose, while CORBA 2.0 added a
dynamic skeleton interface (DSI).

 These interfaces allow for the dynamic selection

of methods either at the client’s end (DII) or at
the server’s end (DSI)
 CORBA ARCHITECTURE
CORBA and OMG IDL

IDL Source

Application Server
IDL Compiler
Programs Programs

Dynamic Dynamic
ORB IDL Skeletons Skeleton Object
Invocation IDL Stubs interface Adapter
Interface Interface
Object Request Broker (ORB)
CREATING CORBA IDL FILES
 Contents
 The CORBA Interface Definition Language (IDL)
 Declaring data members, methods, and parameters
 The interface compiler
 Separating client and server on different machines
 CORBA IDL

 IDL is used to describe the interfaces that client

objects call and that object implementations provide.

 It is a specification that enables interoperability by

separating interface from implementation.

 It is not a programming language – has no constructs

 It maps to many programming languages like C, C++,

Java, and COBOL via OMG standards
 The Interface Definition
 The interface is the syntax part of the contract that
the server object offers to the clients that invoke it.

 Clients access objects only through their advertised

interface, invoking only those operations that the
object exposes through its IDL interface, with only
those parameters (input and output) that are included in
the invocation.
 The IDL interface definition is independent of
programming language.
 It is mapped to programming languages using the
interface compiler
 Example - Calc.idl

module Calc{
interface Calculator {
float calculate(in float val1, in
float val2, in char operator);
}
}
This is an interface for a Calculator with one method – calculate.
A module can have many interfaces.
Mapping IDL to Java, C++
IDL Java C++

module package namespace

interface interface abstract class

operation method member function

attribute pair of methods pair of functions

exception exception exception

 Declaring Data Members

Data members are declared using the attribute keyword. The

declaration must include a name and a type. Attributes are
readable and writable by default. To make a readonly
attribute, use the read-only keyword. IDL compiler
generates public read and write methods for the data
member as required.
For example,
attribute long assignable ;
generates,
int assignable();
void assignable (int i);
 Declaring Data Members

CORBA const values declared in an IDL map to public

static final fields in the corresponding Java interface.
Constants not declared inside the interface are mapped to
public interface with the same name containing a field
value.
const float sample = 2.3;
It is also possible to define your own types using the
typedef keyword.
typedef string name;
 Declaring Methods

 Methods are declared by specifying name, return type,

and parameters.
float calculate(in float val1, in float val2, in char operator);

 Methods can optionally throw exceptions. User-defined

exceptions must be declared in the IDL.
 Methods Types

 Methods are synchronous by default. The client program

will wait for the remote method to execute and return.

 Asynchronous methods are defined using the oneway

keyword. oneway methods have no return value, can have
input parameters only and cannot throw exceptions. The
client makes the call to the oneway method and
continues processing while the remote object executes
it – the client is not blocked.
 Declaring Methods (contd.)

module Calc{
interface Calculator{
//User-defined exception
exception MyException{};
//synchronous method
float calculate(in float val1, in float val2, in char
operator) raises (MyException);
//asynchronous method
oneway void set_value(in long val);
};
};
 More on Exceptions

There are two types of CORBA exceptions:

 System Exceptions are thrown when something goes wrong

with the system.
 User Exceptions are generated if something goes wrong
inside the execution of the remote method. They are
declared inside the IDL definition for the object, and
are automatically generated by the IDL compiler.
Implementation of these exceptions depends on the
language mapping.
 Declaring Parameters

 Parameters can be of following types: Basic (char, long,

short, float, bool, etc.), Constructed (struct, union,
array, sequence), Typed objects, or any.

 Parameters can be declared as in, out, or inout.

 in parameters are copied from client to server
 out parameters are copied from server to client
 inout parameters are used both for incoming and
outgoing information and are copied both ways.
 Interface Compilers
 IDL Compilers implement language mappings in software.

 They compile the interface definition (defined using

IDL) to produce output that can be compiled and linked
with an object implementation and its clients.

 Every ORB comes with one or more IDL compilers, one for
each language that it supports.
 Many vendors supply their IDL compilers. Because the
compilers implement mapping standards, every vendor's
IDL compiler produces language code with the same
mappings, making the code vendor independent.
 Sun’s JDK provides the idlj compiler.
 VisiBroker provides idl2cpp and idl2java compilers.
 Need for Interface Compiler
 The interface compiler converts the language independent
IDL to language specific code that C++, Java or other
language clients and servers can understand.
 For example, the idlj compiler compiles the IDL to Java
code.
 IDL allows an object implementer to choose the
appropriate programming language for the object. Client
and server can be developed in parallel.
 Clients depend only on the interface and not the
implementation of the server code.
 The idlj compiler
 To compile the IDL to java using idlj,
idlj -fall <idl_file_name>
 The –fall option creates both server and client files.
 -fclient generates client files only (default).
 –fserver generates server files only.
 Files created by idlj
The following classes are created when Calc.idl is compiled using
idlj
 Calc.Calculator - The IDL interface represented as a Java
interface
 Calc.CalculatorHelper - Implements the type operations for the
interface
 Calc.CalculatorHolder - Used for out and inout parameters
 Calc.CalculatorOperations – The interface that defines the
exposed remote methods.
 Calc._CalculatorStub - The client stub. Implements a local
object representing the remote CORBA object. This object
forwards all requests to the remote object. The client does not
use this class directly.
 Calc._CalculatorImplBase - An abstract class that implements
the Calculator interface. It is the server skeleton.
Separating client and server

Client Server

 _CalculatorStub  _CalculatorImplBase
 Calculator  Calculator
 CalculatorHelper  CalculatorOperations
 CalculatorHolder
 CalculatorOperations
THANK YOU