Explore topic-wise InterviewSolutions in .

The registration of the remote object must be done by the server in ORDER for the CLIENT to look it up, is called the RMI Registry. In RMI, the client must contact an RMI registry, so that the server side APPLICATION will be able to contact the client’s registry which points the client in the direction of the service. The client registers the service with the registry so that it is transparent to even for the server.

The registration of the remote object must be done by the server in order for the client to look it up, is called the RMI Registry. In RMI, the client must contact an RMI registry, so that the server side application will be able to contact the client’s registry which points the client in the direction of the service. The client registers the service with the registry so that it is transparent to even for the server.

If an object implements the java.rmi.Remote INTERFACE, an object is to be bound to registry context. Each registry context implements the Referenceable interface.

The object factory is implemented by the RegistryContextFactory which converts the registry references into the CORRESPONDING registry contexts or remote objects. To construct the registry constructs, the URL of the registry must be determined. In this way the remote objects will be bounded with registry contexts.

If an object implements the java.rmi.Remote interface, an object is to be bound to registry context. Each registry context implements the Referenceable interface.

The object factory is implemented by the RegistryContextFactory which converts the registry references into the corresponding registry contexts or remote objects. To construct the registry constructs, the URL of the registry must be determined. In this way the remote objects will be bounded with registry contexts.

The methods of remote objects are to be invoked by implementing the java.rmi.Remote interface.

Methods:

• bind(): binds the specified name to the remote object. The name parameter of this method should be in an URL format.
• UNBIND(): Destroys the binding for a specific name of a remote method in the registry
• rebind(): Binds again the specified name to the remote object. The current binding will be replaced by rebinding.
• list(): Returns the names of the names that were bound to the registry in an array form. These names are in the form of URL-formatted STRING.
• lookup(): A stub, a reference will be RETURNED for the remote object which is RELATED with a specified name.

The methods of remote objects are to be invoked by implementing the java.rmi.Remote interface.

Methods:

Creation of RMI-based Server:

• Create the Servant interface and the Servant component class
• To host these servant CLASSES create the RMI Server
• Compile the class files and generate the Skeletons and IDL File
• START up the Server

Creation of RMI-based Client:

• Create the Client class
• Copy the IIOP Stubs and compile the Client
• Make sure the Server is running and then STARTUP the Client

Creation of RMI-based Server:

Creation of RMI-based Client:

In client-SERVER technology / architecture, a server RESPONDS to a remote client. A call back is a method invocation from ONE application (Application A) from another application (Application B), as a RESULT of action that was performed by the Application B earlier. The Application A may run on a client and the Application may run on a server. To perform the call back MECHANISM the system that Application A runs acts as a Server and that of the Application B runs acts as a client.

In client-server technology / architecture, a server responds to a remote client. A call back is a method invocation from one application (Application A) from another application (Application B), as a result of action that was performed by the Application B earlier. The Application A may run on a client and the Application may run on a server. To perform the call back mechanism the system that Application A runs acts as a Server and that of the Application B runs acts as a client.

Data in a FILE can be transferred by using the method getFileContents(filename) in the REMOTE INTERFACE.

RMI supports to transfer data that is AVAILABLE in JDOM data objects.

Data in a file can be transferred by using the method getFileContents(filename) in the remote interface.

RMI supports to transfer data that is available in JDOM data objects.

To marshal and unmarshall the parameters INVOLVES the object serialization and does not TRUNCATE types.

The methods of local object and their bytecodes are not passed directly in the ObjectOutputStream. At times the name of the class of the objects may be needed that is to be loaded by the receiver if at all the class is not available locally. Just LIKE the names of the classes, the class files themselves will not be serialized. All classes must load during the process of deserialization using the normal mechanisms of class LOADING.

To marshal and unmarshall the parameters involves the object serialization and does not truncate types.

The methods of local object and their bytecodes are not passed directly in the ObjectOutputStream. At times the name of the class of the objects may be needed that is to be loaded by the receiver if at all the class is not available locally. Just like the names of the classes, the class files themselves will not be serialized. All classes must load during the process of deserialization using the normal mechanisms of class loading.

When one SERVICE passes an object which is the proxy for another service, the RMI CALLBACK mechanism OCCURS. The methods will be invoked by the recipient in the object it received and be calling back to the calling point. The stub contains the information that is NEEDED to call back to SERVER at the time of the need.

When one service passes an object which is the proxy for another service, the RMI callback mechanism occurs. The methods will be invoked by the recipient in the object it received and be calling back to the calling point. The stub contains the information that is needed to call back to server at the time of the need.

Remote INTERFACES are defined by extending ,an interface CALLED Remote provided in the java.rmi package. The methods MUST throw REMOTEEXCEPTION. But application specific exceptions MAY also be thrown.

Remote interfaces are defined by extending ,an interface called Remote provided in the java.rmi package. The methods must throw RemoteException. But application specific exceptions may also be thrown.

During communication between two machines through RPC or RMI, parameters are packed into a MESSAGE and then SENT over the network. This packing of parameters into a message is called marshalling.

On the other side these packed parameters are UNPACKED from the message which is called UNMARSHALLING.

During communication between two machines through RPC or RMI, parameters are packed into a message and then sent over the network. This packing of parameters into a message is called marshalling.

On the other side these packed parameters are unpacked from the message which is called unmarshalling.

SERVER SIDE STUB is REFERRED to as a SKELETON.

Server side stub is referred to as a skeleton.

The ROLE of the stubs is to MARSHAL and unmarshal the messages that are sent and received on the CLIENT or the server SIDE.

The role of the stubs is to marshal and unmarshal the messages that are sent and received on the client or the server side.

The Stub/Skeleton Layer: The stub/skeleton layer sits in between application layer and the rest of the RMI system and acts as an interface. This layer transmits the information to remote layer. This transmission is done through the marshalling of streams. These streams performs the object serialization.A stub is a remote object at the client-side. This stub implements all the interfaces which remote object implementation supports.A skeleton is a remote object at the server-side. This stub consists of methods that invokes dispatch calls to the remote implementation of objects.

The Remote Reference Layer: The lower level transport interfaces is dealt by this layer. This layer carries a specific remote reference protocol independent of stub and skeletons.Every remote object is IMPLEMENTED by CHOOSING their individual remote reference subclasses.

The Transport Layer: The transport layer sets up the connections to remote address SPACES, manages them, monitors the connection liveliness, and listens the incoming calls.

The transport layer maintains the remote object’s table available in the address space, in a table. For incoming calls, the transport layer ESTABLISHES a connection. It LOCATES the target dispatcher of the remote calls and passes the connection to the dispatcher.

The Stub/Skeleton Layer: The stub/skeleton layer sits in between application layer and the rest of the RMI system and acts as an interface. This layer transmits the information to remote layer. This transmission is done through the marshalling of streams. These streams performs the object serialization.A stub is a remote object at the client-side. This stub implements all the interfaces which remote object implementation supports.A skeleton is a remote object at the server-side. This stub consists of methods that invokes dispatch calls to the remote implementation of objects.

The Remote Reference Layer: The lower level transport interfaces is dealt by this layer. This layer carries a specific remote reference protocol independent of stub and skeletons.Every remote object is implemented by choosing their individual remote reference subclasses.

The Transport Layer: The transport layer sets up the connections to remote address spaces, manages them, monitors the connection liveliness, and listens the incoming calls.

The transport layer maintains the remote object’s table available in the address space, in a table. For incoming calls, the transport layer establishes a connection. It locates the target dispatcher of the remote calls and passes the connection to the dispatcher.

• The client procedure CALLS the client stub in the normal way.
• The client stub builds a message and traps to the kernel.
• The kernel sends the message to the remote kernel.
• The remote kernel GIVES the message to the server stub.
• The server stub UNPACKS the PARAMETERS and calls the server.
• The server does the work and returns the RESULT to the stub.
• The server stub packs it in a message and traps to the kernel.
• The remote kernel sends the message to the clients kernel.
• The clients kernel gives the message to the client stub.
• The stub unpacks the result and returns to the client.

• Assigning the SECURITY manager and then obtaining the REFERENCE to the service
• Contacting the RMI registry to OBTAIN the REMOTE object’s reference and invoking its methods
• Requesting the name for the service
• INVOKE the remote method.

The difference between unicast and MULTICAST is that in unicast approach the sender sends the DATA stream to a single receiver at a time. Thus there is ONE to one communication.

In a multicast the sender and the interested receivers communicate. This is one to many communication. This communication can take place between data terminals spread across VARIOUS LANs too.

The difference between unicast and multicast is that in unicast approach the sender sends the data stream to a single receiver at a time. Thus there is one to one communication.

In a multicast the sender and the interested receivers communicate. This is one to many communication. This communication can take place between data terminals spread across various LANs too.

RMI 

• The remote objects are accessed by the references.
• Implements object to object implementation among different java objects to implement distributed COMMUNICATION model.
• RMI passes the objects as parameters to remote methods.
• RMI invokes the remote methods from the objects.

RPC :

• The process is through methods / functions.
• Proxy SERVER is involved in processing the PROCEDURE calls.
• Calls a procedure remotely like invoking the methods.
• The remoteness is not exactly transparent to the client.

RMI 

RPC :

Advantages of RPC:

• Server independent
• Process-oriented and thread oriented models supported by RPC
• The development of DISTRIBUTED systems is SIMPLE because it uses STRAIGHTFORWARD SEMANTICS and easier.
• Like the common communications between the portions of an application, the development of the procedures for the remote calls is quite general.
• The procedure calls preserves the business logics which is apt for the application.
• The code re-writing / re-developing effort is minimized.
• Enables the usage of the applications used in the distributed environment, not only in the local environment.
• RPC provides interoperability between CORBA ORB implementations.
• A lightweight RPC protocol permits efficient implementations.

Disadvantages of RPC:

• Context switching increases scheduling costs
• RPC is not a standard – it is an idea that can be implemented in many ways
• RPC does not solve the most of the distribution creation problems
• RPC is only interaction based. This does not offer any flexibility in terms of hardware architecture.
• RPC implementations are not yet mature.
• It requires the TCP/IP protocol. Other transport protocols are not supported yet.
• Not yet proven over wide-area networks.

Advantages of RPC:

Disadvantages of RPC:

A request from ONE program that is located in one computer can be used by another computer in a NETWORK environment without understanding the underlying network details. This is done by a protocol called Remote Procedure Calls. In this client / server environment (network environment), the request is from a client to the server that provides the service from a server.

RPC is also called as inter-process communication. RPC extends the normal procedure calls across the network which is necessary in distributed computing models and for harnessing the power of the multiple processors.

In distributed systems, a client calls a procedure stored on a server. This is called calling a remote procedure stored on a server. Though, the call is made as if the procedure was stored on the local machine.

The steps in which a RPC is made are:

• The client calls the procedure
• The client stub builds the message.
• The message is sent over the network.
• The Server OS gives the message to the server stub.
• The server stub unpacks the message.
• The stub makes a local call to the procedure.
• The server does the work and RETURNS the RESULT to the server stub.
• The stub packs the message and traps to the kernel.
• The remote kernel sends the message the client kernel.
• The client kernel gives the message to the client stub.
• The client stub unpacks the result and gives to the client.

A request from one program that is located in one computer can be used by another computer in a network environment without understanding the underlying network details. This is done by a protocol called Remote Procedure Calls. In this client / server environment (network environment), the request is from a client to the server that provides the service from a server.

RPC is also called as inter-process communication. RPC extends the normal procedure calls across the network which is necessary in distributed computing models and for harnessing the power of the multiple processors.

In distributed systems, a client calls a procedure stored on a server. This is called calling a remote procedure stored on a server. Though, the call is made as if the procedure was stored on the local machine.

The steps in which a RPC is made are:

The most significant difference between RMI and CORBA is that CORBA was made specifically for interoperability across programming languages. That is CORBA FOSTERS the notion that programs can be built to interact in multiple languages. The server COULD be written in C++, the business logic in Python, and the front-end written in COBOL in theory. RMI, on the other hand is a total JAVA solution, the interfaces, the implementations and the clients--all are written in Java.

RMI allows DYNAMIC loading of classes at runtime. In a multi-language CORBA environment, dynamic class loading is not possible. The important advantage to dynamic class loading is that it allows arguments to be passed in remote invocations that are subtypes of the declared types. In CORBA, all types have to be known in advance. RMI (as well as RMI/IIOP) provides support for polymorphic parameter PASSING, whereas strict CORBA does not. CORBA does have support for multiple languages which is good for some applications, but RMI has the advantage of being dynamic, which is good for other applications.

The most significant difference between RMI and CORBA is that CORBA was made specifically for interoperability across programming languages. That is CORBA fosters the notion that programs can be built to interact in multiple languages. The server could be written in C++, the business logic in Python, and the front-end written in COBOL in theory. RMI, on the other hand is a total Java solution, the interfaces, the implementations and the clients--all are written in Java.

RMI allows dynamic loading of classes at runtime. In a multi-language CORBA environment, dynamic class loading is not possible. The important advantage to dynamic class loading is that it allows arguments to be passed in remote invocations that are subtypes of the declared types. In CORBA, all types have to be known in advance. RMI (as well as RMI/IIOP) provides support for polymorphic parameter passing, whereas strict CORBA does not. CORBA does have support for multiple languages which is good for some applications, but RMI has the advantage of being dynamic, which is good for other applications.

RMI is a set of APIS that allows to build DISTRIBUTED APPLICATIONS. RMI uses interfaces to define remote objects to turn local METHOD invocations into remote method invocations.

RMI is a set of APIs that allows to build distributed applications. RMI uses interfaces to define remote objects to turn local method invocations into remote method invocations.

It STANDS for REMOTE METHOD INVOCATION.

It stands for Remote Method Invocation.

When the specified URL is not connected then the URL throw MalformedURLException and If INETADDRESS? methods getByName and getLocalHost are unable to RESOLVE the HOST NAME they throw an UNKNOWNHOSTEXCEPTION.

When the specified URL is not connected then the URL throw MalformedURLException and If InetAddress? methods getByName and getLocalHost are unable to resolve the host name they throw an UnknownHostException.

A socket is ONE end-point of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the TCP layer can IDENTIFY the application that data is destined to be sent. Socket classes are used to represent the connection between a client PROGRAM and a server program. The java.net package provides two classes–Socket and ServerSocket–which implement the client side of the connection and the server side of the connection, RESPECTIVELY.

A socket is one end-point of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the TCP layer can identify the application that data is destined to be sent. Socket classes are used to represent the connection between a client program and a server program. The java.net package provides two classes–Socket and ServerSocket–which implement the client side of the connection and the server side of the connection, respectively.

You obtain a URL INSTANCE and then invoke openConnection on it. URLConnection is an abstract CLASS, which means you can’t directly CREATE instances of it using a constructor. We have to invoke openConnection method on a URL instance, to get the right kind of connection for your URL. Eg. URL url;

URLConnection connection;
try {
url = NEW URL(”…”);
connection = url.openConnection();
} CATCH (MalFormedURLException e) { }

You obtain a URL instance and then invoke openConnection on it. URLConnection is an abstract class, which means you can’t directly create instances of it using a constructor. We have to invoke openConnection method on a URL instance, to get the right kind of connection for your URL. Eg. URL url;

URLConnection connection;
try {
url = new URL(”…”);
connection = url.openConnection();
} catch (MalFormedURLException e) { }

RMI uses different parameters with values and EXCEPTIONS and they all has to be passed for RMI calls. It creates the object that is serializable.

RMI uses the serialization mechanisms to transfer the data from one machine to another using the virtualization concept. This is done so that the caller can receive the files on time. When the parameters return the values of the method invocation and unmarshals it then the live objects gets received by the java VIRTUAL machines.

The UNMARSHALLING process tries to resolve the name ISSUE of the classes by loading the context class using the current thread. RMI provides the dynamic loading of the class definition to be done using actual types of objects that are passed as parameters and return values for RMI.

This allows the dynamic loading of the REMOTE stub classes that are related to a particular remote object that takes part in implementation of the classes.

RMI also uses special subclasses of java.io.ObjectOutputStream and java.io.ObjectInputStream for marshilling and unmarshalling.

RMI uses different parameters with values and exceptions and they all has to be passed for RMI calls. It creates the object that is serializable.

RMI uses the serialization mechanisms to transfer the data from one machine to another using the virtualization concept. This is done so that the caller can receive the files on time. When the parameters return the values of the method invocation and unmarshals it then the live objects gets received by the java virtual machines.

The unmarshalling process tries to resolve the name issue of the classes by loading the context class using the current thread. RMI provides the dynamic loading of the class definition to be done using actual types of objects that are passed as parameters and return values for RMI.

This allows the dynamic loading of the remote stub classes that are related to a particular remote object that takes part in implementation of the classes.

RMI also uses special subclasses of java.io.ObjectOutputStream and java.io.ObjectInputStream for marshilling and unmarshalling.

Every object that can be remotely accessed have a corresponding skeleton that FUNCTIONS like the original object. It is responsible for DISPATCHING the call that is made to the actual remote object for the implementation and allow it to be IMPLEMENTED USING the services provided by RMI. It allows the incoming method invocation to unmarshals i.e. only read the parameters used for the remote method. It invokes the method that is used by the actual remote object and after implementation marshals the result to the caller who is the original caller for the object.

Every object that can be remotely accessed have a corresponding skeleton that functions like the original object. It is responsible for dispatching the call that is made to the actual remote object for the implementation and allow it to be implemented using the services provided by RMI. It allows the incoming method invocation to unmarshals i.e. only read the parameters used for the remote method. It invokes the method that is used by the actual remote object and after implementation marshals the result to the caller who is the original caller for the object.

RMI uses a mechanism that is standard for all the system and it is used to communicate with all the remote objects that are available. So, stubs are used to store the objects in the database so that it can be used later on. A stub is used for remote objects that act as a CLIENT’s local proxy for the remote object. This way the caller of the object calls the method on the local stub that becomes responsible to carry out the method call on the remote objects.

RMI uses stub for a remote object that implements the same set of remote interfaces that is implemented by remote object. The stub is used to initiate the connection between the object and the java virtual MACHINE. It marshalls that includes write and transmit the PARAMETERS to the remote java virtual machine that includes the method INVOCATION. It allows the unmarshalling of the object to return the true value or the exception to be returned to the caller. The stub is used to hide the serialization of the parameter at network-level for the communication to be PROCEEDED without any disturbance.

RMI uses a mechanism that is standard for all the system and it is used to communicate with all the remote objects that are available. So, stubs are used to store the objects in the database so that it can be used later on. A stub is used for remote objects that act as a client’s local proxy for the remote object. This way the caller of the object calls the method on the local stub that becomes responsible to carry out the method call on the remote objects.

RMI uses stub for a remote object that implements the same set of remote interfaces that is implemented by remote object. The stub is used to initiate the connection between the object and the java virtual machine. It marshalls that includes write and transmit the parameters to the remote java virtual machine that includes the method invocation. It allows the unmarshalling of the object to return the true value or the exception to be returned to the caller. The stub is used to hide the serialization of the parameter at network-level for the communication to be proceeded without any disturbance.

To implement the distributed object model a class is required that implements a remote interface extending the functionality of java.rmi.Remote and other classes such as java.rmi.server.UnicastRemoteObject.

The implementation then take the RESPONSIBILITY for exporting the object having the CORRECT use of remote semantics provided using hashCode, equals, and toString METHODS that are INHERITED from the java.lang.Object class.

The code is given below as:

public void withdraw(FLOAT amount) throws OverdrawnException,
RemoteException
// write your own statements
}
public float getBalance() throws RemoteException
{
// write your own statements
}

To implement the distributed object model a class is required that implements a remote interface extending the functionality of java.rmi.Remote and other classes such as java.rmi.server.UnicastRemoteObject.

The implementation then take the responsibility for exporting the object having the correct use of remote semantics provided using hashCode, equals, and toString methods that are inherited from the java.lang.Object class.

The code is given below as:

public void withdraw(float amount) throws OverdrawnException,
RemoteException
// write your own statements
}
public float getBalance() throws RemoteException
{
// write your own statements
}

Remote INTERFACE allows the extension of the interface of java.rmi.Remtoe.

This interface EXTENDS it non-remotely using the condition that this extend the interface when all the methods used are also extended in the interface that satisfy all the requirements of a remote method declaration.

The example CODE shows the remote interface that is used in GENERAL:

public interface Bank extends java.rmi.Remote
{
public void deposit(float amount)
throws java.rmi.RemoteException;
public void withdraw(float amount)
throws OverdrawnException, java.rmi.RemoteException;
public float getBalance()
throws java.rmi.RemoteException;
}

The class of this extends the java.rmi.Remote to inherit the behavior and properties used by this specified class.This also uses several other class OBJECTS for example:

java.rmi.server.RemoteObject and java.rmi.server.RemoteServer.

Remote interface allows the extension of the interface of java.rmi.Remtoe.

This interface extends it non-remotely using the condition that this extend the interface when all the methods used are also extended in the interface that satisfy all the requirements of a remote method declaration.

The example code shows the remote interface that is used in general:

public interface Bank extends java.rmi.Remote
{
public void deposit(float amount)
throws java.rmi.RemoteException;
public void withdraw(float amount)
throws OverdrawnException, java.rmi.RemoteException;
public float getBalance()
throws java.rmi.RemoteException;
}

The class of this extends the java.rmi.Remote to inherit the behavior and properties used by this specified class.This also uses several other class objects for example:

java.rmi.server.RemoteObject and java.rmi.server.RemoteServer.

RMI uses a remote INTERFACE DECLARING the methods that are invoked from a virtual machine and further forwarded to the server to take any request coming from the client.

Java.rmi.Remote provides an interface declaring a set of methods that invokes the virtual machine to fulfill the REQUIREMENTS.

This allows the extension of the interface directly or indirectly.

Each method declaration in remote interface must have the exception policy such as java.rmi.RemoteException or java.io.IOException or java.lang.Exception clause that can be made application SPECIFIC and it reduces the effort to extend java.rmi.RemoteException.

Remote method DECLARES the object as a parameter or the return value and that has to be declared using the remote interface

RMI uses a remote interface declaring the methods that are invoked from a virtual machine and further forwarded to the server to take any request coming from the client.

Java.rmi.Remote provides an interface declaring a set of methods that invokes the virtual machine to fulfill the requirements.

This allows the extension of the interface directly or indirectly.

Each method declaration in remote interface must have the exception policy such as java.rmi.RemoteException or java.io.IOException or java.lang.Exception clause that can be made application specific and it reduces the effort to extend java.rmi.RemoteException.

Remote method declares the object as a parameter or the return value and that has to be declared using the remote interface

RMI distributed applications uses certain steps that defines the path mentioned in the registry. It has the following steps:

• It uses the registry that stores the location and important information about the remote object.
• It uses the registry to OBTAIN the references to a remote object that keeps all the information and allow further communication to be done.
• The SERVER calls the registry to associate the name with the remote object and then the client sends the request for the object.
• The client searches the remote object by its name in the registry on the server and INVOKES a method on it.
• RMI uses a web server to load the bytecodes of CLASSES to use the communication for the client and server.
• RMI can load the class using the Internet protocols LIKE HTTP, FTP, file, and etc.

RMI distributed applications uses certain steps that defines the path mentioned in the registry. It has the following steps:

RMI HANDLES the remote objects that are being provided between the server and client COMPUTERS. The difference between the objects are handled using RMI as well. RMI USES the standard method invocation to communicate between one object or another object. It loads the class byte-codes for objects that are passed using the defined parameters and return the values to the server in case of failure or success of it. RMI also allows the transmission to be done when PASSING the data as well.

The string that is used by the RMI registry is “rmi://hostname:port/remoteObjectName", this allows the RMI registry to know the correct object and create a connection between different objects through this. If the hostname is not defined then local host can be used INSTEAD of it and this will also establish the connection

RMI handles the remote objects that are being provided between the server and client computers. The difference between the objects are handled using RMI as well. RMI uses the standard method invocation to communicate between one object or another object. It loads the class byte-codes for objects that are passed using the defined parameters and return the values to the server in case of failure or success of it. RMI also allows the transmission to be done when passing the data as well.

The string that is used by the RMI registry is “rmi://hostname:port/remoteObjectName", this allows the RMI registry to know the correct object and create a connection between different objects through this. If the hostname is not defined then local host can be used instead of it and this will also establish the connection

RMI consists of a server and a client program. The application in RMI creates a number of remote objects that makes the references to the objects that are to be accessible. This way when a client makes a call to the method on remote objects then the reference is PASSED to one or more remote objects in server.

It then invokes certain methods on them to provide few functionalities. RMI provides the MECHANISM to communicate and PASS the information from one part to another using the distributed object applications. It requires to locate the remote objects so that the registry can be MAINTAINED for the remote objects with RMI's naming facility, rmiregistry, and the application that can pass the remote object references and RETURN it as a normal operation.

RMI consists of a server and a client program. The application in RMI creates a number of remote objects that makes the references to the objects that are to be accessible. This way when a client makes a call to the method on remote objects then the reference is passed to one or more remote objects in server.

It then invokes certain methods on them to provide few functionalities. RMI provides the mechanism to communicate and pass the information from one part to another using the distributed object applications. It requires to locate the remote objects so that the registry can be maintained for the remote objects with RMI's naming facility, rmiregistry, and the application that can pass the remote object references and return it as a normal operation.

The implementation is the easy phase of the serializable class. At first this interface remains as an empty interface and it declares no methods or behavior at all. It has additing feature that is added to the implements serializable class to follow the class declarations. It is not required to make every object as serializable as there will also be some classes that might not be having any serialization required. 

For example, an instance of a file that actually REPRESENTS a file GETS created by using File file = new File("c:\career\ride");

so to make this WORK there is no SURITY that is it require a serialized code to be written. The file class is having a different lifecyle than the serialized data and MODIFICATION in it might remove the entire information. There are also platform dependencies that involves native code not used for serialization.

The implementation is the easy phase of the serializable class. At first this interface remains as an empty interface and it declares no methods or behavior at all. It has additing feature that is added to the implements serializable class to follow the class declarations. It is not required to make every object as serializable as there will also be some classes that might not be having any serialization required. 

For example, an instance of a file that actually represents a file gets created by using File file = new File("c:\career\ride");

so to make this work there is no surity that is it require a serialized code to be written. The file class is having a different lifecyle than the serialized data and modification in it might remove the entire information. There are also platform dependencies that involves native code not used for serialization.

To create a class serializable there is mechanism of SERIALIZING an object on the client code. 

There are four things that are required to make a class serializable and these are: 

• The first thing that has to be done is to implement the serializable interface that makes the process easy to convert the set of object references to the linear STREAM of bytes.
• Check whether the instance level that is locally defined state is in SERIALIZED mode or not. Check that it has been implemented PROPERLY or not.
• Check whether the superclass state in the serialized phase is properly managed and adjusted. If it is adjusted then with the help of few function the process can create a class serializable.
• Then use the methods like equals( ) and hashCode( ) to override the already USED functions. This will allow the addition of new code to be inserted

To create a class serializable there is mechanism of serializing an object on the client code. 

There are four things that are required to make a class serializable and these are: 

The conditions that has to be kept in mind while using serialization is that: 

The class should be declared as public and it should implement the serializable VERSION identifier that is given as serialVersionUID to read the serial versions that are being loaded or updated. 

The class should not consists of any ARGUMENT constructor and all the FIELDS of the class should have a serializable field in it. This can be either primitive types or Serializable objects type. 

The class doesn't itself declare any methods and an execption can be made in the fields that are made transient and these are ignored during serialization.

The conditions that has to be kept in mind while using serialization is that: 

The class should be declared as public and it should implement the serializable version identifier that is given as serialVersionUID to read the serial versions that are being loaded or updated. 

The class should not consists of any argument constructor and all the fields of the class should have a serializable field in it. This can be either primitive types or Serializable objects type. 

The class doesn't itself declare any methods and an execption can be made in the fields that are made transient and these are ignored during serialization.

The classes define the BLUEPRINT that consists of the methods and behavior of a particular STRUCTURE.

The classes are:

Remote class: It is the class that consists of the instances that can be accessed remotely from the server and also consists of different properties that are required to be accessed by the CLIENT and server during request and response time.

Remote class object: Wherever this object is defined the instances of the class can be accessed using other object. On other computers that are not in network it can be accessed through the use of object handles.

Serializable class: It is the class that consists of instances that can be marshaled or turned in a linear sequence to represent the BITS.

Serializable class objects: It ALLOWS the request to be transmitted from one computer to another. It allows the easy implementation of the serializable class.

The classes define the blueprint that consists of the methods and behavior of a particular structure.

The classes are:

Remote class: It is the class that consists of the instances that can be accessed remotely from the server and also consists of different properties that are required to be accessed by the client and server during request and response time.

Remote class object: Wherever this object is defined the instances of the class can be accessed using other object. On other computers that are not in network it can be accessed through the use of object handles.

Serializable class: It is the class that consists of instances that can be marshaled or turned in a linear sequence to represent the bits.

Serializable class objects: It allows the request to be transmitted from one computer to another. It allows the easy implementation of the serializable class.

There are different terms that are used in RMI that helps in calling the remote servers and allow an easy to use terminology to be created:

• Remote object: It is an object that is provided on another computer to request the object by sending a message to the object to the remote servers.
• Server object: It is an object of the server side that receive the request and respond to the request of the client in SUCCESS or failure.
• rmiregistry: It is the registry that keeps the look ups of all the objects in a LIST by given name. This registry consists the list of all the COMPONENTS that are given in it.
• RMIC: It is a compiler for RMI object.

After creating the object the compiler compiles the object and it will generate the actual code that is to be transferred to the client side.

There are different terms that are used in RMI that helps in calling the remote servers and allow an easy to use terminology to be created:

After creating the object the compiler compiles the object and it will generate the actual code that is to be transferred to the client side.

RMI is a distributed object system that provides and enable to easily develop the distributed JAVA applications. It is easier to develop applications using the RMI method then using the sockets. It doesn't require any protocol for design that makes it less prone to error for the tasks performed by it. RMI is allows the local method to be called from a local class file and the remote METHODS are interpreted and are sent back to the callers.

The CORBA also having the same features that are seen in RMI. It is a platform and language independent ARCHITECTURE that can be run on any platform. It can be located from anywhere on the network and can be used in any language that has a mapping with IDL (INTERFACE definition language). The objects of this are SPECIFIED with interfaces that are specified in the interface language.

RMI is a distributed object system that provides and enable to easily develop the distributed Java applications. It is easier to develop applications using the RMI method then using the sockets. It doesn't require any protocol for design that makes it less prone to error for the tasks performed by it. RMI is allows the local method to be called from a local class file and the remote methods are interpreted and are sent back to the callers.

The CORBA also having the same features that are seen in RMI. It is a platform and language independent architecture that can be run on any platform. It can be located from anywhere on the network and can be used in any language that has a mapping with IDL (Interface definition language). The objects of this are specified with interfaces that are specified in the interface language.

RMI uses a runtime client that a virtual machine detects of the REMOTE object that is not referenced locally. It notify the server in came of any disconnections and this way the server can be updated by the object's set. The GARBAGE COLLECTOR that is distributed associate an address with each client remote object reference.

It also renew the remote objects while the client still consists of the references. This mechanism will ALLOW the abnormal termination of the clients so that server can hold the remote objects that are not referenced using the message that are stopped running. The function System.exit() can be invoked for abnormal termination, as it doesn't allow the RMI runtime to send a proper messages to the server. This function will terminate the client virtual machine and will keep the remote references that will be cleaned up before exiting.

The other functions that are USED for this are:

• System.gc();
• System.runFinalization();

RMI uses a runtime client that a virtual machine detects of the remote object that is not referenced locally. It notify the server in came of any disconnections and this way the server can be updated by the object's set. The garbage collector that is distributed associate an address with each client remote object reference.

It also renew the remote objects while the client still consists of the references. This mechanism will allow the abnormal termination of the clients so that server can hold the remote objects that are not referenced using the message that are stopped running. The function System.exit() can be invoked for abnormal termination, as it doesn't allow the RMI runtime to send a proper messages to the server. This function will terminate the client virtual machine and will keep the remote references that will be cleaned up before exiting.

The other functions that are used for this are:

HTTP-Tunneling is a method that requires no setup and works within the firewall ENVIRONMENT. It allows the handling of HTTP through proxy server and doesn't allow REGULAR outbound TCP connections. If the RMI fails to make any connection specially SOCKS then connection is made through an intended server that allow the HTTP proxy server to be configured. This will allow the request to be passed through the proxy server one by one.

The forms of HTTP-tunneling are http-to-port: where the RMI attempt to use HTTP POST request USING a URL that will be directed at the hostname and port number of the server that is GIVEN. If the proxy accepts the URL it will FORWARD a POST request to listen to RMI server that will remove the request of the name. There is an http-to-cgi tunneling that will consists of the requests and allow the proxy request to be binded to their defined port numbers.

HTTP-Tunneling is a method that requires no setup and works within the firewall environment. It allows the handling of HTTP through proxy server and doesn't allow regular outbound TCP connections. If the RMI fails to make any connection specially SOCKS then connection is made through an intended server that allow the HTTP proxy server to be configured. This will allow the request to be passed through the proxy server one by one.

The forms of HTTP-tunneling are http-to-port: where the RMI attempt to use HTTP POST request using a URL that will be directed at the hostname and port number of the server that is given. If the proxy accepts the URL it will forward a POST request to listen to RMI server that will remove the request of the name. There is an http-to-cgi tunneling that will consists of the requests and allow the proxy request to be binded to their defined port numbers.

The UnkownHostException error can come for many reasons. To find out first there is a need to know the network's name SERVICE that is having a fully-qualified hostname RECOGNIZED by RMI host. The possible problems that might come are:

There is a POSSIBILITY of having misconfigured DHCP servers that allows fully-qualified domain name of RMI server machines. RMI client in this case try to access the outside server's DHCP domain that will make it unavailable for the server.

There is a possibility of having the error DUE to WINS server. It is possible that only registered users might not be reachable by hosts.

There is a possibility of having a firewall that is blocking the RMI client and server side requests. If the server resides inside the firewall and the client outside then the client won't be able to make any REMOTE calls to the server that is inside due to the firewall.

The UnkownHostException error can come for many reasons. To find out first there is a need to know the network's name service that is having a fully-qualified hostname recognized by RMI host. The possible problems that might come are:

There is a possibility of having misconfigured DHCP servers that allows fully-qualified domain name of RMI server machines. RMI client in this case try to access the outside server's DHCP domain that will make it unavailable for the server.

There is a possibility of having the error due to WINS server. It is possible that only registered users might not be reachable by hosts.

There is a possibility of having a firewall that is blocking the RMI client and server side requests. If the server resides inside the firewall and the client outside then the client won't be able to make any remote calls to the server that is inside due to the firewall.

The java.net.UnknownHostException method is used as remote calling and for callback routine fail. RMI uses default settings to RESOLVE the server HOSTNAME like WINS NAMES, DHCP names, etc. This happens due to which RMI client invokes the remote method using the reference that consists of unresolved server hostname and the client will produce UnknownHostException. RMI servers provide fully qualified hostname or IP ADDRESS to resolve all RMI clients error reports. RMI provides an operation to remotely callback a program that serves RMI object and provide resolvable hostname to pass it to the RMI clients. UnkownHostException is thrown when an applet is failed to provide a useable server hostname. The property java.rmi.server.hostname can be set to GET from the server the correct IP address or hostname.

The java.net.UnknownHostException method is used as remote calling and for callback routine fail. RMI uses default settings to resolve the server hostname like WINS names, DHCP names, etc. This happens due to which RMI client invokes the remote method using the reference that consists of unresolved server hostname and the client will produce UnknownHostException. RMI servers provide fully qualified hostname or IP address to resolve all RMI clients error reports. RMI provides an operation to remotely callback a program that serves RMI object and provide resolvable hostname to pass it to the RMI clients. UnkownHostException is thrown when an applet is failed to provide a useable server hostname. The property java.rmi.server.hostname can be set to get from the server the correct IP address or hostname.

RMI is known as REMOTE method invocation and to for the RMI client to connect to remote RMI server first thing is to get hold on a reference of the server.

The Naming.lookup method is used to as a mechanism that is used to PROVIDE the way to obtain the references to remote servers. The remote servers can be obtained by using the remote calls that return remote references. This also uses a stub to make a remote method call used in RMIREGISTRY that sends back to remote reference.

Then the references consists of a server hostname and port number, which allow clients to locate a virtual machine. This virtual machine is used to allow the remote object to be FOUND and connected. After the remote reference are PROVIDED to RMI client, then it will be easy to use hostname and port that is provided to open the socket connection to a remote server.

RMI is known as Remote method invocation and to for the RMI client to connect to remote RMI server first thing is to get hold on a reference of the server.

The Naming.lookup method is used to as a mechanism that is used to provide the way to obtain the references to remote servers. The remote servers can be obtained by using the remote calls that return remote references. This also uses a stub to make a remote method call used in rmiregistry that sends back to remote reference.

Then the references consists of a server hostname and port number, which allow clients to locate a virtual machine. This virtual machine is used to allow the remote object to be found and connected. After the remote reference are provided to RMI client, then it will be easy to use hostname and port that is provided to open the socket connection to a remote server.