ADVANCED COMPUTER PROGRAMMING
J
A
V
Submitted to:
A
A
S
S
I
G
N
M
E
N
T
Sir Ghulam Jillani Ansari
Assistant Professor
Submitted by:
Syed Ali Asjad
Roll No. 741
M.Sc IT Semester II Morning
Submitted on:
June 02, 2014
CORBA & RMI
DISTRIBUTED OBJECT SYSTEMS
The Common Object Request Broker Architecture (CORBA) and Java Remote Method
Invocation (RMI) mechanism are two most important and widely used distributed object systems.
Each system has its own features and shortcomings. Both are being used in the industry for various
applications ranging from e-commerce to health care. Selecting which of these two distribution
mechanisms to use for a project is a tough task. This article presents an overview of RMI and
CORBA, and more importantly it shows how to develop a useful application for downloading files from
remote hosts. It then:
 Presents a brief overview of distributed object systems
 Provides a brief overview of CORBA & RMI
 Analysis the architecture of CORBA & RMI
 Study the advantages and pros and cons of CORBA & RMI
CORBA
COMMON OBJECT REQUEST BROKER ARCHITECHTURE
CORBA stands for Common Object Request Broker Architecture. The CORBA is a
standard defined by the Object Management Group as a part of Object Management
Architecture to aid in distributed objects programming that enables software components
written in multiple computer languages and running on multiple computers to work together.
CORBA was designed to be platform and language independent Therefore
CORBA objects can run on any platform, be located on any network, be written in any
language that has Interface Definition Language (IDL) mappings.
The purpose of CORBA in Object Management Architecture is to implement
Object Request Broker functions. It has CORBA related objects as CORBAservices
CORBAfacilities and CORBAdomains.
 CORBAservices provide low-level, base-type services such as transactions, security,
life-cycle, and naming.
 CORBAfacilities provide a higher-level set of services such as printing management.
 CORBAdomains represent vertical domain-related standards such as manufacturing,
telecommunication, healthcare, financial and so on.
ARCHITECHTURE OF CORBA
The following figure illustrates the primary components in the CORBA ORB
architecture. Descriptions of these components are available below the figure.
 Object








-- This is a CORBA
programming entity that consists of an
identity, an interface, and an implementation, which is known as a Servant.
Servant -- This is an implementation programming language entity that defines the
operations that support a CORBA IDL interface. Servants 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. Accessing the services of a remote object should be transparent to
the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj>op(args). The remaining components in Figure 2 help to support this level of
transparency.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB simplifies
distributed programming by decoupling the client from the details of the method
invocations. This makes client requests appear to be local procedure calls. 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. This interface provides various helper functions such as converting
object references to strings and vice versa, and creating argument lists for requests
made through the dynamic invocation interface described below.
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. The use of a compiler reduces the
potential for inconsistencies between client stubs and server skeletons and increases
opportunities for automated compiler optimizations.
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 interfacespecific 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 one-way (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.
Objects 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).
The basic steps for CORBA development includes:






Create the IDL to define the application interface
Translate the IDL (Map IDL interface to JAVA)
Compile the interface Files
Compile the implementation
Link the application
Run the client and server
ADVANTAGES OF CORBA
 Object Location Transparency
The client does not need to know where an object is physically located. An object
can either be linked into the client, run in a different process on the same machine, or
run in a server on the other side of the planet. A request invocation looks the same
regardless, and the location of an object can change over time without, breaking
applications.
 Server Transparency
The client is, as far as the programming model is concerned, ignorant of the
existence of servers. The client does not know (and cannot find out) which server hosts
a particular object, and does not care whether the server is running at the time the
client invokes a request.
 Language Transparency
Client and server can be written in different languages. This fact encapsulates the
whole point of CORBA; that is, the strengths of different languages can be utilized to
develop different aspects of a system, which can interoperate through IDL. A server can
be implemented in a different language without clients being aware of this.
 Implementation Transparency
The client is unaware of how objects are implemented. A server can use ordinary
flat files as its persistent store today and use an OO database tomorrow, without clients
ever noticing a difference (other than performance).
 Architecture Transparency
The idiosyncrasies of CPU architectures are hidden from both clients and servers. A
little-endian client can communicate with a big-endian server with different alignment
restrictions.
 Operating System Transparency
Client and server are unaffected by each other's operating system. In addition,
source code does not change if you need to port the source from one operating system
to another.
 Protocol Transparency
Clients and servers do not care about the data link and transport layer. They can
communicate via token ring, Ethernet, wireless links, ATM (Asynchronous Transfer
Mode), or any number of other networking technologies.
Moreover, CORBA also has following advantages:
 Open Standard
 Efficiency
 Scalability
 Strong Data typing
PROS & CONS OF CORBA
Pros
Cons
 Services can be written in many
 Describing services require the use of
different languages, executed on many
different platforms, and accessed by any
language with an interface definition
language (IDL) mapping.
an interface definition language (IDL)
which must be learned. Implementing or
using services require an IDL mapping
to your required language - writing one
for a language that isn't supported
would take a large amount of work.
 With IDL, the interface is clearly
 IDL to language mapping tools create
separated from implementation, and
developers
can
create
different
implementations based on the same
interface.
code stubs based on the interface some tools may not integrate new
changes with existing code.
 CORBA supports primitive data types,
 CORBA does not support the transfer of
and a wide range of data structures, as
parameters
objects, or code.
 CORBA is ideally suited to use with
 The future is uncertain - if CORBA fails
legacy systems, and to ensure that
applications written now will be
accessible in the future.
to achieve sufficient adoption by
industry, then CORBA implementations
become the legacy systems.
 CORBA is an easy way to link objects
 Some training is still required, and
and systems together
 CORBA systems may offer greater
performance
CORBA specifications are still in a state
of flux
 Not all classes of applications need realtime performance, and speed may be
traded off against ease of use for pure
Java systems.
RMI
REMOTE METHOD INVOCATION
The Java Remote Method Invocation Application Programming Interface (API), or
Java RMI developed by Sun Microsystems, is a Java application programming interface
that performs the object-oriented equivalent of Remote Procedure Calls (RPC).
RMI is a distributed object system that enables you to develop easily distributed
JAVA applications, in which the methods of remote JAVA objects can be invoked from
another JAVA Virtual Machine (JVM) possible on different host. Under RMI, entire objects
can be passed and returned as parameter, unlike many remote procedure calls based
mechanisms which require parameters to be either primitive data types, or structures
composed of primitive data types. It means that any JAVA object can be passed as a
parameter – even new objects whose class has never been encountered before by the
Remote Virtual Machine.
ARCHITECHTURE OF RMI
The following figure illustrates the primary components in the RMI architecture.
Descriptions of these components are available below the figure.
D
S
The RMI Architecture has four layers:
(1) Application Layer
(2) Proxy Layer
(3) Remote Reference Layer
(4) Transport Layer
 Application Layer:
It’s a responsible for the actual logic (implementation) of the client and server
applications. Generally at the server side class contain implementation logic and also apply
the reference to the appropriate object as per the requirement of the logic in application.
 Proxy Layer:
It’s also called the “Stub/Skeleton layer”.
A Stub class is a client side proxy handles the remote objects which are getting from
the reference. A Skeleton class is a server side proxy that set the reference to the objects
which are communicates with the Stub.
 Remote Reference Layer:
It’s a responsible for manage the references made by the client to the remote object
on the server so it is available on both JVM (Client and Server).
The Client side RRL receives the request for methods from the Stub that is
transferred into byte stream process called serialization (Marshalling) and then these data
are send to the Server side RRL.
The Server side RRL doing reverse process and convert the binary data into object.
This process called de-serialization or un-marshalling and then sent to the Skeleton class.
 Transport Layer:
It’s also called the “Connection layer”.
It’s a responsible for the managing the existing connection and also setting up new
connections. So it is a work like a link between the RRL on the Client side and the RRL on
the Server side.
The RMI application contains the three components:
(1) RMI Server
(2) RMI Client
(3) RMI Registry
 RMI Server:
RMI Server contains objects whose methods are to be called remotely. It creates
remote objects and applies the reference to these objects in the Registry, after that the
Registry registers these objects who called by client remotely.
 (2) RMI Client:
The RMI Client gets the reference of one or more remote objects from Registry with
the help of object name. Now, it can be invokes the methods on the remote object to access
the services of the objects as per the requirement of logic in RMI application. Once the client
gets the reference of remote object, the methods in the remote object are invoked just like as
the methods of a local object.
 RMI Registry:
In the Server side the reference of the object (which is invoked remotely) is applied
and after that this reference is set in the RMI registry. When the Client call the method on
this object, it’s not directly call but it call by the reference which is already set in the Registry
so first get the object from this reference which is available at RMI Registry then after calls
the methods as per the requirement of logic in RMI application.
ADVANTAGES OF RMI
 Object Oriented: RMI can pass full objects as arguments and return values, not just
predefined data types. This means that you can pass complex types, such as a standard
Java hash table object, as a single argument. In existing RPC systems you would have
to have the client decompose such an object into primitive data types, ship those data
types, and the recreate a hash table on the server. RMI lets you ship objects directly
across the wire with no extra client code.
 Mobile Behaviour: RMI can move behaviour (class implementations) from client to
server and server to client. For example, you can define an interface for examining
employee expense reports to see whether they conform to current company policy.
When an expense report is created, an object that implements that interface can be
fetched by the client from the server. When the policies change, the server will start
returning a different implementation of that interface that uses the new policies. The
constraints will therefore be checked on the client side-providing faster feedback to the
user and less load on the server-without installing any new software on user's system.
This gives you maximal flexibility, since changing policies requires you to write only one
new Java class and install it once on the server host.
 Design Patterns: Passing objects lets you use the full power of object oriented
technology in distributed computing, such as two- and three-tier systems. When you can
pass behaviour, you can use object oriented design patterns in your solutions. All object
oriented design patterns rely upon different behaviours for their power; without passing







complete objects-both implementations and type-the benefits provided by the design
patterns movement are lost.
Safe and Secure: RMI uses built-in Java security mechanisms that allow your system to
be safe when users downloading implementations. RMI uses the security manager
defined to protect systems from hostile applets to protect your systems and network from
potentially hostile downloaded code. In severe cases, a server can refuse to download
any implementations at all.
Easy to Write/Easy to Use: RMI makes it simple to write remote Java servers and Java
clients that access those servers. A remote interface is an actual Java interface. A server
has roughly three lines of code to declare itself a server, and otherwise is like any other
Java object. This simplicity makes it easy to write servers for full-scale distributed object
systems quickly, and to rapidly bring up prototypes and early versions of software for
testing and evaluation. And because RMI programs are easy to write they are also easy
to maintain.
Connects to Existing/Legacy Systems: RMI interacts with existing systems through
Java's native method interface JNI. Using RMI and JNI you can write your client in Java
and use your existing server implementation. When you use RMI/JNI to connect to
existing servers you can rewrite any parts of you server in Java when you choose to, and
get the full benefits of Java in the new code. Similarly, RMI interacts with existing
relational databases using JDBC without modifying existing non-Java source that uses
the databases.
Write Once, Run Anywhere: RMI is part of Java's "Write Once, Run Anywhere"
approach. Any RMI based system is 100% portable to any Java Virtual Machine *, as is
an RMI/JDBC system. If you use RMI/JNI to interact with an existing system, the code
written using JNI will compile and run with any Java virtual machine.
Distributed Garbage Collection: RMI uses its distributed garbage collection feature to
collect remote server objects that are no longer referenced by any clients in the network.
Analogous to garbage collection inside a Java Virtual Machine, distributed garbage
collection lets you define server objects as needed, knowing that they will be removed
when they no longer need to be accessible by clients.
Parallel Computing: RMI is multi-threaded, allowing your servers to exploit Java
threads for better concurrent processing of client requests.
The Java Distributed Computing Solution: RMI is part of the core Java platform
starting with JDK 1.1, so it exists on every 1.1 Java Virtual Machines. All RMI systems
talk the same public protocol, so all Java systems can talk to each other directly, without
any protocol translation overhead.
PROS & CONS OF RMI
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
have
since
 Learning curve for developers that have no
 Existing systems may already use RMI - the
 Can only operate with Java systems - no
cost and time to convert to a new
technology may be prohibitive
support for legacy systems written in C++,
Ada, Fortran, Cobol, and others (including
future languages).
developers may already
experience with RMI (available
JDK1.02)
RMI experience is comparable with CORBA