RMI and CORBA

Compiled by: Er. Juned Alam

Centralized system

Upto swing app development, we have been studying

and practising our java codes as a centralized system.

That means, all of our code and resources resides

within a particular machine.
Distributed system

In the chapter network programming, we have seen the

distributed system at play, as our java code resides in
two different machines; namely: client and server
machines.

Can we call our servlets and jsps and servlets as

distributed system?
Technologies to achieve
Distributed system using java

For homogeneous system, For heterogeneous

we have RMI (Remote system, we have CORBA
Method Invocation) (Common Object Request
Broker Architecture)
Remote Method Invocation (RMI)

Remote Method Invocation (RMI) model represents a

distributed object application. RMI allows an object
inside a Java Virtual Machine (JVM) (particularly on a
client side) to invoke a method on an object running on
a remote JVM (particularly on a server side).
Lets look at how JVM’s memory
management works for objects.
 JVM’s memory management
within the same machine
Stack memory Heap memory
area area

Object_1 007 Object_1 Object_2

Object_2 008

007 008
 JVM’s memory management in
different machines (RMI’s model)
Stack memory Heap memory
area area

rmiregistry

Object_1 007 Object_1 Object_2

Object_2 008

007 008

Stub Skeleton
RMI’s architecture
Steps to develop a remote
interface using RMI

1. Create the remote interface

2. Implementation of Remote Interface
3. Compile, stub and skeleton (rmic)
4. Start the registry
5. Create and start the server
6. Create and start the client
1. Create the remote interface

import java.rmi.Remote;

public interface AddI extends Remote {

void add(int var1, int var2) throws Exception;

}
2. Implementation of Remote
Interface
import java.rmi.server.UnicastRemoteObject;

public class Adder extends UnicastRemoteObject implements AddI {

public Adder() throws Exception { }

public void add(int var1, int var2) throws Exception {

System.out.println("the result is " + (var1 + var2));

}
Server class

import java.rmi.Naming;
public class Server{
public static void main(String[] args) throws Exception {
Adder adder = new Adder();
Naming.bind("add",adder);
System.out.println("Server started");
}
}
Client class
import java.rmi.Naming;

public class Client{

public static void main(String[] args) throws Exception {

System.out.println("Client started");

AddI addI = (AddI) Naming.lookup("add");

addI.add(10,20);

}
3. Compile, stub and skeleton
(rmic)
>javac *.java
4. Start the RMI registry

>start rmiregistry
5. Create and start the server

>java Server
6. Create and start the client

>java Client
Output
Common Object Request Broker
Architecture (CORBA)
Object Management Group (OMG): a non-profit
industry consortium formed in 1989 with the goal to
develop, adopt, and promote standards for the
development of distributed heterogeneous applications.
CORBA contd.

The CORBA specification details the interfaces and

characteristics of the Object Request Broker; it
practically specifies the middleware functions which
allow application objects to communicate with one
another no matter where they are located, who has
designed them and in which language they are
implemented.
CORBA architecture
CORBA services

1. Naming Service
2. Event Service and notification Service
3. Security service
4. Trading service
5. Transaction service and concurrency control service
6. Persistent state service
7. Life cycle service
 RMI pros and cons

pros cons

Portable across many platforms Tied only to platforms with Java support

Can introduce new code to foreign JVMs Security threats with remote code
execution, and limitations on functionality
enforced by security restrictions

Java developers may already have Learning curve for developers that have no
experience with RMI (available since RMI experience is comparable with
JDK1.02) CORBA

Existing systems may already use RMI - Can only operate with Java systems - no
the cost and time to convert to a new support for legacy systems written in C++,
technology may be prohibitive Ada, Fortran, Cobol, and others (including
future languages).
 CORBA pros and cons
pros cons

Services can be written in many different Describing services require the use of an interface
languages, executed on many different definition language (IDL) which must be learned.
platforms, and accessed by any language with Implementing or using services require an IDL
an interface definition language (IDL) mapping to your required language - writing one for
mapping. a language that isn't supported would take a large
amount of work.

With IDL, the interface is clearly separated IDL to language mapping tools create code stubs
from implementation, and developers can based on the interface - some tools may not
create different implementations based on the integrate new changes with existing code.
same interface.

CORBA supports primitive data types, and a CORBA does not support the transfer of objects, or
wide range of data structures, as parameters code.
 CORBA pros and cons contd

pros cons

CORBA is ideally suited to use with legacy The future is uncertain - if CORBA fails to
systems, and to ensure that applications achieve sufficient adoption by industry, then
written now will be accessible in the future. CORBA implementations become the legacy
systems.

CORBA is an easy way to link objects and Some training is still required, and CORBA
systems together specifications are still in a state of flux.

CORBA systems may offer greater Not all classes of applications need real-time
performance performance, and speed may be traded off
against ease of use for pure Java systems.
Thank you