CLASS: I M.

Sc (CS) SUBJECT: ADVANCED JAVA PROGRAMMING UNIT: II

REMOTE METHOD INVOCATION

1. EXPLAIN REMOTE METHOD INVOCATION. (PART-C)
2. DISCUSS ABOUT STUB AND SKELETON. (PART-B)
 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:
 RMI uses stub and skeleton object for communication with the remote object.
 A remote object is an object whose method can be invoked from another JVM. Let’s 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
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
3. It writes and transmits (marshals) the result to the caller
 In the Java 2 SDK, an stub protocol was introduced that eliminates the need for skeletons.

Understanding requirements for the distributed applications:

 If any application performs these tasks, it can be distributed application.
o The application need to locate the remote method
o It need to provide the communication with the remote objects
o The application need to load the class definitions for the objects. The RMI application has all
these features, so it is called the distributed application.
 The RMI application has all these features, so it is called the distributed application.
Working of RMI:
 The communication between client and server is handled by using two intermediate objects:
Stub object (on client side) and Skeleton object (on server-side) as also can be depicted from below
media as follows.
 These are the steps to be followed sequentially to implement Interface as defined below as follows:
1. Create the remote interface
2. Provide the implementation of the remote interface

1
 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

 The client application needs only two files, remote interface and client application. In the rmi
application, both client and server interacts with the remote interface. The client application
invokes methods on the proxy object; RMI sends the request to the remote JVM. The return value is
sent back to the proxy object and then to the client application.

1) Create the remote interface

 For creating the remote interface, extend the Remote interface and declare the Remote Exception
with all the methods of the remote interface. Here, we are creating a remote interface that extends the
Remote interface. There is only one method named add() and it declares Remote Exception.
1. import java.rmi.*;
2. public interface Adder extends Remote{
3. public int add(int x,int y)throws Remote Exception;
4.}
2) Provide the implementation of the remote interface
 Now provide the implementation of the remote interface. For providing the implementation of the
Remote interface, we need to
 Either extend the UnicastRemoteObject class,
 Or use the exportObject() method of the UnicastRemoteObject class
 In case, you extend the UnicastRemoteObject class, you must define a constructor that declares
Remote Exception.
 In case, you extend the UnicastRemoteObject class, you must define a constructor that declares
Remote Exception.
1. import java.rmi.*;
2. import java.rmi.server.*;
3. public class AdderRemote extends UnicastRemoteObject implements Adder{
4. AdderRemote()throws RemoteException{
5. super();
2
 6.}
7. public int add(int x,int y){return x+y;}
8.}
3) Create the stub and skeleton objects using the rmic tool
 Next step is to create stub and skeleton objects using the rmi compiler. The rmic tool invokes
the RMI compiler and creates stub and skeleton objects.
rmic Adder Remote
4) Start the registry service by the rmiregistry tool
 Now start the registry service by using the rmiregistry tool. If you don't specify the port number,
it uses a default port number. In this example, we are using the port number 5000.
rmiregistry 5000
5) Create and run the server application
 Now rmi services need to be hosted in a server process. The Naming class provides methods
to get and store the remote object. In this example, we are binding the remote object by the name
soon.
1. import java.rmi.*;
2. import java.rmi.registry.*;
3. public class MyServer{
4. public static void main(String args[]){
5. try{
6. Adder stub=new AdderRemote();
7. Naming.rebind("rmi://localhost:5000/sonoo",stub);
8. }catch(Exception e){System.out.println(e);}
9.}
10.}
6) Create and run the client application
 At the client we are getting the stub object by the lookup() method of the Naming class and invoking
the method on this object.
 In this example, we are running the server and client applications, in the same machine so we are
using localhost. If you want to access the remote object from another machine, change the localhost
to the host name (or IP address) where the remote object is located.
1. import java.rmi.*;
2. public class MyClient{
3. public static void main(String args[]){
4. try{
5. Adder stub=(Adder)Naming.lookup("rmi://localhost:5000/sonoo");
6. System.out.println(stub.add(34,4));
7.} catch(Exception e){}
8.}
9.}
DISTRIBUTED APPLICATION ARCHITECTURE
3. WRITE A SHORT NOTE ON DISTRIBUTED APPLICATION ARCHITECTURE. (PART-B)
 Distributed application architecture is a design approach for developing software applications that
are comprised of multiple components or services that are deployed and run on multiple computers
or servers. This architecture allows for scalability, fault-tolerance, and easy integration of different
components
 There are several key aspects of distributed application architecture:
o Client-server model: The application is divided into a client component that interacts with
the user and a server component that provides services and resources. Clients communicate
with servers over a network, typically using protocols like HTTP or TCP/IP.
o Middleware: Middleware is a software layer that sits between the client and server
components, providing services such as message passing, data persistence, and load
balancing. It coordinates communication between different components and facilitates
interoperability.

3
 o Service-oriented architecture (SOA): This architectural style focuses on organizing
software applications into services, which are self-contained modules that provide specific
functions or processes. Services can be developed and deployed independently, and can
communicate with each other to form a complete application.
o Micro services architecture: This approach breaks down the application into smaller,
loosely coupled services that can be developed, deployed, and scaled independently.
Each microservice is responsible for a specific functionality and can communicate with each
other through lightweight APIs.
o Message-based communication: In a distributed application, components typically
communicate with each other through messages. This can be achieved using messaging
protocols like AMQP or event-driven architectures, where components publish and subscribe
to events.
o Load balancing and fault tolerance: Distributed applications often involve multiple
instances of a component running on different servers. Load balancing ensures that requests
are distributed evenly across these instances, improving performance and scalability.
Fault tolerance mechanisms like redundancy and failover ensure that the application can
continue functioning even if one or more components fail.
 Overall, distributed application architecture aims to provide scalable, reliable, and flexible software
solutions by distributing components across multiple servers and leveraging communication
protocols and middleware to enable seamless integration and coordination.
 In distributed architecture, components are presented on different platforms and several components
can cooperate with one another over a communication network in order to achieve a specific
objective or goal.
 In this architecture, information processing is not confined to a single machine rather it is
distributed over several independent computers.
 A distributed system can be demonstrated by the client-server architecture which forms
the base for multi-tier architectures; alternatives are the broker architecture such as
CORBA, and the Service-Oriented Architecture (SOA).
 There are several technology frameworks to support distributed architectures, including
.NET, J2EE, CORBA, .NET Web services, AXIS Java Web services, and Globus Grid
services.
 Middleware is an infrastructure that appropriately supports the development and
execution of distributed applications. It provides a buffer between the applications and the
network.
 It sits in the middle of system and manages or supports the different components of a
distributed system. Examples are transaction processing monitors, data convertors and
communication controllers etc.
Middleware as an infrastructure for distributed system

 The basis of a distributed architecture is its transparency, reliability, and availability. The following
table lists the different forms of transparency in a distributed system.
4
Transparency & Description:
1. Access: Hides the way in which resources are accessed and the differences in data platform.
2. Location: Hides where resources are located.
3. Technology: Hides different technologies such as programming language and OS from user.
4. Migration / Relocation: Hide resources that may be moved to another location which are in use.
5. Replication: Hide resources that may be copied at several locations.
6. Concurrency: Hide resources that may be shared with other users.
7. Failure: Hides failure and recovery of resources from user.
8. Persistence: Hides whether a resource (software) is in memory or disk.
CREATING STUBS AND SKELETONS
4. WRITE THE STEPS TO CREATE STUBS AND SKELETONS. EXPLAIN. (PART-B)
Steps to Create Stub and Skeleton in RMI:
 To create a remote object and enable RMI communication, the following steps are involved in
creating the stub and skeleton.
1. Define the Remote Interface:
o Create an interface that extends the "java.rmi.Remote" interface.
o Declare the remote methods that can be invoked by the client.
o Each remote method must throw "java.rmi.RemoteException".
2. Implement the Remote Interface:
o Create a class that implements the remote interface.
o Provide the implementation for each remote method declared in the interface.
o This class will serve as the server-side implementation of the remote object.
3. Compile the Remote Interface and Implementation:
o Compile both the remote interface and its implementation class.
4. Generate the Stub and Skeleton:
o Use the "rmic" tool (RMI Compiler) provided by Java to generate the stub and
skeleton classes.
o Run the "rmic" command followed by the fully qualified name of the remote
implementation class.
o This step generates the stub and skeleton classes for the remote object.
5. Start the RMI Registry:
o Start the RMI Registry on the server-side to enable clients to locate the remote
object.
o This can be done by running the "rmiregistry" command from the command line.
6. Deploy and Run the Server and Client:
o Start the server program by instantiating the remote object and binding it to a
unique name using "Naming.rebind()".
o Run the client program by looking up the remote object from the RMI Registry
using "Naming.lookup()".
o The client can then invoke remote methods on the object obtained from the
lookup.
 By following these steps, the stub (client-side) and skeleton (server-side) classes are generated,
enabling remote method invocation between client and server objects using RMI in Java.
DEFINING REMOTE OBJECTS
5. HOW TO DEFINE REMOTE OBJECTS? EXPLAIN. (PART-B)
 Defining a remote RMI object involves specifying a remote interface for the object, then providing a
class that implements this interface.
 The remote interface and implementation class are then used by RMI to generate a client stub and
server skeleton for your remote object.
 The communication between local objects and remote objects is handled using these client stubs and
server skeletons.
Relationships among remote object, stub, and skeleton classes:
 When a client gets a reference to a remote object (details on how this reference is obtained come
later) and then calls methods on this object reference, there needs to be a way for the method request
to get transmitted back to the actual object on the remote server and for the results of the method call
5
 to get transmitted back to the client. This is what the generated stub and skeleton classes are for.
They act as the communication link between the client and your exported remote object, making it
seem to the client that the object actually exists within its Java VM.
 Remote objects are objects in a distributed computing environment that can be accessed and
manipulated across different machines or network nodes. These objects provide a way for software
components to communicate and interact with each other over a network, regardless of their physical
locations.
 These objects provide a way for software components to communicate and interact with each other
over a network, regardless of their physical locations. When defining remote objects, several aspects
need to be considered:
o Interface: Remote objects define interfaces that specify the methods and attributes that can
be accessed remotely. The interface acts as a contract between the client and the remote
object, ensuring that both parties understand how to interact with each other.
o Marshaling: Remote objects utilize marshaling or serialization techniques to convert method
calls, argument values, and return values into a format that can be transmitted over the
network. This ensures that the objects can be properly transported across different machines
and platforms.
o Location transparency: Remote objects enable transparent access to their methods and
properties, hiding the complexities of the underlying network and communication protocols.
This allows clients to invoke remote methods as if they were invoking local methods,
simplifying the development and maintenance of distributed systems.
o Remote object reference: Remote objects are typically accessed through remote object
references, which provide a means of identifying and locating the objects in a distributed
system. These references are used by clients to establish a communication channel with the
remote object and invoke its methods.
o Activation and lifecycle management: Remote objects may require activation and lifecycle
management mechanisms to control their instantiation, deletion, and availability.
These mechanisms ensure that remote objects are created, managed, and destroyed
appropriately in a distributed environment.
REMOTE OBJECT ACTIVATION
6. DISCUSS ABOUT REMOTE OBJECT ACTIVATION. (PART-B)
 Prior to the release of the Java 2 SDK, an instance of a UnicastRemoteObject could be accessed from
a program that (1) created an instance of the remote object, and (2) ran all the time.
 Activatable and the RMI daemon, rmid, programs can be written to register information about
remote object implementations that should be created and execute "on demand", rather than running
all the time.
 The RMI daemon, rmid, provides a Java virtual machine (JVM) from which other JVM instances
may be spawned
Creating the implementation class:
 The implementation class will be examples.activation.ActivatableImplementation. There are four
steps to create an implementation class:
o Make the appropriate imports in the implementation class
o Extend your class from java.rmi.activation.Activatable
o Declare a two-argument constructor in the implementation class
o Implement the remote interface method(s)
 Step 1: Make the appropriate imports in the implementation class
import java.rmi.*;
import java.rmi.activation.*;
 Step 2: Extend your class from java.rmi.activation.Activatable
public class ActivatableImplementation extends Activatable
implements examples.activation.MyRemoteInterface {
 Step 3: Declare a two-argument constructor in the implementation class
public ActivatableImplementation(ActivationID id, MarshalledObject data)
throws RemoteException {
// Register the object with the activation system
6
 // then export it on an anonymous port
super(id, 0);
}
 Step 4: Implement the remote interface method(s)
public Object callMeRemotely() throws RemoteException {
return "Success";
}
Creating the "setup" class:
 The job of the "setup" class is to create all the information necessary for the activatable class,
without necessarily creating an instance of the remote object. For this example the setup class will
be examples.activation.Setup.
 The setup class passes the information about the activatable class to rmid, registers a remote
reference (an instance of the activatable class's stub class) and an identifier (name) with the
rmiregistry, and then the setup class may exit. There are seven steps to create a setup class:
1. Make the appropriate imports
2. Install a SecurityManager
3. Create an ActivationGroup instance
4. Create an ActivationDesc instance
5. Declare an instance of your remote interface and register with rmid
6. Bind the stub to a name in the rmiregistry
7. Quit the setup application
Compile and run the code:
 There are six steps to compile and run the code:
1. Compile the remote interface, implementation, client, and setup classes
2. Run rmic on the implementation class
3. Start the rmiregistry
4. Start the activation daemon, rmid
5. Run the setup program
6. Run the client Step
OBJECT SERIALIZATION
7. DISCUSS ABOUT OBJECT SERIALIZATION. (PART-C)
 Object Serialization is the process of converting an object's state (its data) into a byte stream.
This byte stream can be transmitted over a network or saved to a file.
 Serialization allows objects to be persisted (stored) and later reconstructed (deserialized) back into
their original form.
 In Java, the java.io.Serializable interface is used to mark classes as serializable.
Why use Serialization in RMI?
 RMI allows objects to invoke methods on remote Java objects running in different Java Virtual
Machines (JVMs), possibly on different hosts.
 To achieve this, RMI uses object serialization:
o Parameters are marshaled (converted) into a byte stream before being sent over the network.
o Types are preserved, supporting true object-oriented polymorphism.
o Unmarshaling reconstructs the object graph from the byte stream.
Example: Implementing Serializable in RMI
 Let's consider a simple example with a Person object and an Address object:
o Person implements the PersonInterface (which extends Remote) and contains name, age,
and address information. Address is a separate class representing an address.
// Person Interface
package server;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface PersonInterface extends Remote {
void setName(String name) throws RemoteException;
String getPerson() throws RemoteException;
void setAddress(Address address) throws RemoteException;
7
}
// Person Implementation
package server;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
class Person extends UnicastRemoteObject implements PersonInterface {
private String name;
private int age;
private Address address;
Person() throws RemoteException {
super();
}
// Other methods...
}
// Address Class (Serializable)
package server;
import java.io.Serializable;
public class Address implements Serializable {
private static final long serialVersionUID = 227L;
private String address1;
private String address2;
public Address(String address1, String address2) {
this.address1 = address1;
this.address2 = address2;
}
}
// Server (binding Person object)
package server;
import java.rmi.Naming;
class Server {
public static void main(String[] args) {
try {
Person person = new Person();
String namePerson = "rmi://localhost:9999/person";
Naming.bind(namePerson, person);
System.out.println("Server is running...");
} catch (Exception ex) {
System.out.println("Server Exception...");
ex.printStackTrace();
}
}
}
// Client (looking up Person object)
package client;
import java.rmi.Naming;
import server.PersonInterface;
class Client {
public static void main(String[] args) {
try {
String namePerson = "rmi://localhost:9999/person";
PersonInterface person = (PersonInterface) Naming.lookup(namePerson);
// Other interactions...
} catch (Exception ex) {
// Handle exceptions...
}
}}
8
 JAVASPACES
8. EXPLAIN JAVASPACES DISTRIBUTED OBJECT SYSTEM. (PART-B)
 JavaSpaces is a new distributed object system being proposed by Sun as a package at a higher level
than the existing RMI and object serialization facilities built into Java.
 JavaSpaces provides a distributed, persistent object system that is roughly modeled after earlier
shared memory systems, such as LINDA.
 While it has some analogies with parallel shared memory systems such as the Posix shm_xxx library
and shared memory facilities in parallel languages like Python, it also has some important
differences.
Overview of JavaSpaces:
 The distributed application paradigm supported by JavaSpaces is one in which remote agents interact
with each other indirectly through shared data object spaces. Objects are stored in a JavaSpace in the
form of entries.

 Access to the entries in JavaSpaces is through a small set of basic operations:

 read: Read an entry from the space that matches a template.
 write: Add an entry to the space.
 take: Read and remove an entry from the space.
 notify: Send a notification through a given event handler if entries that match a template are
added to the space. A notification request has a time-out period associated with it: if a
matching entry isn't added within the time-out period, the notify request fails and is dropped
from the JavaSpace.
 Multiple basic operations can be assembled into transactions that group basic operations into a
single, atomic aggregate operation.
 There can be many clients and many JavaSpaces in a given distributed application. One client, and
even one transaction from one client, can access multiple JavaSpaces. So instead of one agent
sending a message to another, or invoking a remote method directly on another object within an
agent, agents interact by writing and reading objects in JavaSpaces.
 An important feature of the JavaSpaces specification is that all operations on a given JavaSpace are
considered unordered. If you have multiple threads or multiple remote agents issuing operations on a
JavaSpace, and for some reason you want to impose some order on the operations, then it's up to you
to synchronize your threads or agents as needed.
 Each JavaSpace holds data in the form of entries, which can either be read, written, or taken from a
JavaSpace. Each entry has one or more fields that are used to match incoming requests from clients.
Each request to read, take, or be notified about an entry includes a template for the entry to match. In
order for an entry in the JavaSpace to match, the entry must be of the same type as the template
object. Each field in the template can either have a non-null value, which must match the fields in a
matching entry in the JavaSpace, or a null value, which matches any value in that field.
 All operations on JavaSpaces are "transactionally secure," which means that each operation or
transaction is either entirely committed or entirely noncommitted to a JavaSpace. So if a write to a

9
 JavaSpace succeeds, then you can be assured that the Entry was written and will appear in the next
client read or take operation on the space. An operation on JavaSpaces can be either in the form of a
simple operation, or a group of operations within a single Transaction.
 The authors of the JavaSpace specification make a point of distinguishing JavaSpaces from a
distributed database system.
 A JavaSpace knows the type of its entries, and can compare field values, but it doesn't understand
anything about the structure of the data in its entries. It also isn't meant to provide opaque read/write
access to persistent data.
 An entry in a JavaSpace is a serialized copy of the object written to the space, and entries returned to
clients as a result of read or take operations are separate copies of the objects in the space.
QUESTION BANK
PART – A [1 Mark]
1. In RMI Architecture which layer intercepts method calls made by the client/redirects these calls to
a remote RMI service?
a) Stub & Skeleton Layer b) Application Layer c) Remote Reference Layer d) Transport Layer
2. An RMI Server is responsible for ----------
a) Creating an instance of the remote object b) Exporting the remote object
c) Binding the instance of the remote object to the RMI registry d) All mentioned above
3. Which package is used for Remote Method Invocation (RMI)?
a) java.lang.rmi b) java.lang.reflect c) java.applet d) java.rmi
4. In a RMI Client Program, what are the exceptions which might have to handled?
a) RemoteException b) NotBoundException c) MalFormedURLException d) All mentioned above
5. Which is built on the top of socket programming?
a) EJB b) RMI c) Both A & B d) None of the above
6. Which of these methods are member of Remote class?
a) checkIP() b) addLocation() c) AddServer() d) None of the mentioned
7. Which of these is a process of writing the state of an object to a byte stream?
a) Serialization b) Externalization c) File Filtering d) All of the mentioned
8. Which of these is an interface for control over serialization and deserialization?
a) Serializable b) Externalization c) FileFilter d) ObjectInput
9. Which of these interface extends DataOutput interface?
a) Serializable b) Externalization c) ObjectOutput d) ObjectInput
10. Java supports RMI, RMI Stands for?
a) Random Method Invocation b) Remote Memory Interface
c) Remote Method Invocation d) Random Method Invocation
PART – B [5 Marks]
1. Discuss about stub and skeleton.
2. Write a short note on distributed application architecture.
3. Write the steps to create stubs and skeletons. Explain.
4. How to define remote objects? Explain.
5. Discuss about remote object activation.
6. Explain Javaspaces distributed object system.
PART – C [10 Marks]
1. Explain remote method invocation.
2. Discuss about object serialization.

UNIT-II COMPLETED

10