Unit III

APPLICATIONS IN DISTRIBUTED ENVIRONMENT

3.1 RMI (Remote Method Invocation)

The RMI (Remote Method Invocation) is an API that provides a mechanism to create
distributed application in java. The RMI allows an object to invoke methods on an object
running in another JVM.

The RMI provides remote communication between the applications using two
objects stub and skeleton.

Understanding stub and skeleton

stub

The stub is an object, acts as a gateway for the client side. All the outgoing requests are routed
through it. It resides at the client side and represents the remote object. When the caller
invokes method on the stub object, it does the following tasks:

1. It initiates a connection with remote Virtual Machine (JVM),

2. It writes and transmits (marshals) the parameters to the remote Virtual Machine (JVM),
3. It waits for the result
4. It reads (unmarshals) the return value or exception, and
5. It finally, returns the value to the caller.

skeleton

The skeleton is an object, acts as a gateway for the server side object. All the incoming requests
are routed through it. When the skeleton receives the incoming request, it does the following
tasks:

1. It reads the parameter for the remote method

2. It invokes the method on the actual remote object, and
3. It writes and transmits (marshals) the result to the caller.
Java RMI Example

The is given the 6 steps to write the RMI program.

1. Create the remote interface

2. Provide the implementation of the remote interface
3. Compile the implementation class and create the stub and skeleton objects using the
RMIC tool
4. Start the registry service by rmiregistry tool
5. Create and start the remote application
6. Create and start the client application

Syntax

import java.rmi.*;
import java.rmi.registry.*;
public class SearchServer
{
public static void main(String args[])
{
………….
} }

import java.rmi.*;
public class SearchClient
{
public static void main(String args[])
{
……………………..
}}
3.2 RMI activation
In the RMI activation system, activatable objects belong to activation groups, and each
activation group runs within its own Java VM. If you don't group your activatable objects, simply
assigning a new activation group to each activatable object you create, then each object runs
inside a separate Java VM.

3.3 RMI custom sockets

A Java Remote Method Invocation (RMI) application can make remote invocations over secure
SSL connections using custom socket factories. An application can export a remote object to use
an RMI socket factory that creates SSL sockets.

This tutorial shows you the steps to follow to implement and use a custom RMI socket factory.
A custom RMI socket factory is useful if
(1) your RMI client and server need to use sockets that encrypt or compress data, and/or
(2) your application requires different socket types for different remote objects.

3.4 RMI-IIOP
The Java RMI-IIOP specification was created to simplify the development of CORBA
applications, while preserving all major benefits. It was developed by Sun Microsystems and
IBM, combining features of Java RMI technology with features of CORBA technology.

CORBA, IIOP, and ORB

IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs
written in different programming languages to communicate over the Internet. IIOP is a critical
part of an industry standard, the Common Object Request Broker Architecture (CORBA). CORBA
is an architecture and specification for creating, distributing, and managing distributed program
objects in a network. CORBA allows programs at different locations and developed by different
vendors to communicate in a network through a broker that mediates remote requests.
An essential concept in CORBA is the Object Request Broker (ORB). An Object Request Broker
(ORB) acts as a “broker” between a client request for a service from a distributed object or
component and the completion of that request. ORB support in a network of clients and servers
on different computers means that a client program (which may itself be an object) can request
services from a server program or object without having to understand where the server is in a
distributed network or what the interface to the server program looks like.

The stub forwards the request to the remote object, where the operation runs and the results
are returned to the client. The client-side ORB is responsible for creating an IIOP request that
contains the operation and required parameters, and for sending the request on the network.

RMI may be implemented as three layers:


o A stub (proxy) program in the client side of the client/server relationship, and a
corresponding skeleton at the server end. The stub appears to the calling
program to be the program being called for a service.
o A Remote Reference Layer that can behave differently depending on the
parameters passed by the calling program. For example, this layer can determine
whether the request is to call a single remote service or multiple remote
programs as in a multicast.
o A Transport Connection Layer, which sets up and manages the request.

A single request travels down through the layers on one computer and up through the layers at
the other end
3.5 IDL technology

Java IDL enables objects to interact regardless of whether they're written in the Java
programming language or another language such as C, C++, COBOL, or others.
IDL is independent of any particular programming language. Mappings, or bindings, from IDL to
specific programming languages are defined and standardized as part of the CORBA
specification. At the time of this writing, standard bindings for C, C++, Smalltalk, Ada, COBOL,
and Java have been approved by the OMG.

The core of the CORBA architecture is the Object Request Broker, as shown in following Figure .
Each machine involved in a CORBA application must have an ORB running in order for processes
on that machine to interact with CORBA objects running in remote processes. Object clients
and servers make requests through their ORBs; the ORB is responsible for making the requests
happen or indicating why they cannot. The client ORB provides a stub for a remote object.
Requests made on the stub are transferred from the client's ORB to the ORB servicing the
implementation of the target object. The request is passed onto the implementation through its
skeleton interface.

3.6 Naming Service

The Naming Service The CORBA Naming Service provides a directory naming structure
for remote objects. The tree always starts with a root node, and subnodes of the object tree
can be defined. Actual objects are stored by name at the leaves of the tree. Figure 4-2 depicts
an example set of objects[2] registered within a Naming Service directory. The fully qualified
name of an object in the directory is the ordered list of all of its parent nodes, starting from the
root node and including the leaf name of the object itself. So, the full name of the object
labeled "Fred" is "living thing," "animal," "man," "Fred," in that order.
3.7 JAR files in Java

A JAR (Java Archive) is a package file format typically used to aggregate many Java class files
and associated metadata and resources (text, images, etc.) into one file to distribute
application software or libraries on the Java platform.
In simple words, a JAR file is a file that contains a compressed version of .class files, audio
files, image files, or directories. We can imagine a .jar file as a zipped file(.zip) that is created
by using WinZip software. Even, WinZip software can be used to extract the contents of
a .jar . So you can use them for tasks such as lossless data compression, archiving,
decompression, and archive unpacking.

1 ) In order to create a .jar file, we can use jar cf command in the following ways as discussed
below:

Syntax:

jar cf jarfilename inputfiles

Here, cf represents to create the file. For example , assuming our package pack is available in
C:\directory , to convert it into a jar file into the pack.jar , we can give the command as:

C:\> jar cf pack.jar pack

2 ) Extracting a JAR file

In order to extract the files from a .jar file, we can use the commands below listed:

jar xf jarfilename

Here, xf represents extract files from the jar files. For example, to extract the contents of our
pack.jar file, we can write:

C:\> jar xf pack.jar

3 ) Running a JAR file
In order to run an application packaged as a JAR file (requires the Main-class manifest
header), the following command can be used as listed:
Syntax:
C:\>java -jar pack.jar