Remote Method Invocation (RMI) - Revision history

80.185.148.15: /* Implementing an RMI programm */

2005-04-11T06:56:32Z

Implementing an RMI programm

← Older revision		Revision as of 06:56, 11 April 2005
Line 31:		Line 31:
	== Implementing an RMI programm ==		== Implementing an RMI programm ==

	The next few paragraphs will describe the basic steps of how to implement a simple RMI program		The next few paragraphs will describe the basic steps of how to implement a simple RMI program. The source code of a simple example program can be found at http://www.informatik.hu-berlin.de/~westmeie/rmi

	=== The Remote Interface ===		=== The Remote Interface ===

Zubow: /* The Client */

2005-02-08T08:27:44Z

The Client

← Older revision		Revision as of 08:27, 8 February 2005
Line 47:		Line 47:
	=== The Client ===		=== The Client ===

	When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion		When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion.
	dsdsd

	== Some further techniques ==		== Some further techniques ==

Zubow: /* Restrictions */

2005-02-08T08:25:49Z

Restrictions

← Older revision		Revision as of 08:25, 8 February 2005
Line 17:		Line 17:
	* Remote Methods must be defined in a Remote Interface		* Remote Methods must be defined in a Remote Interface
	* Remote Methods must throw a RemoteException		* Remote Methods must throw a RemoteException
	* ~~Arguments~~ to or return values of remote methods must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.		* arguments to or return values of remote methods must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.
	* each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original		* each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original
	* there is a call overhead		* there is a call overhead
Line 27:		Line 27:
	* there are no custom socket transports available		* there are no custom socket transports available
	* underscores in identifiers should be omitted to avoid name collisions with [[IDL]]		* underscores in identifiers should be omitted to avoid name collisions with [[IDL]]
	* [[IIOP]] does not support overloading		* [[IIOP]] does not support method overloading

	== Implementing an RMI programm ==		== Implementing an RMI programm ==

Zubow: /* Restrictions */

2005-02-08T08:24:18Z

Restrictions

← Older revision		Revision as of 08:24, 8 February 2005
Line 17:		Line 17:
	* Remote Methods must be defined in a Remote Interface		* Remote Methods must be defined in a Remote Interface
	* Remote Methods must throw a RemoteException		* Remote Methods must throw a RemoteException
	* Arguments to or return values of remote ~~methdos~~ must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.		* Arguments to or return values of remote methods must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.
	* each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original		* each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original
	* there is a call overhead		* there is a call overhead

Zubow: /* Restrictions */

2005-02-08T08:23:48Z

Restrictions

← Older revision		Revision as of 08:23, 8 February 2005
Line 15:		Line 15:

	Although transparency is indeed accomplished to a high degree the programmer will still notice that he deals with remote methods since certain restrictions apply:		Although transparency is indeed accomplished to a high degree the programmer will still notice that he deals with remote methods since certain restrictions apply:
	* ~~remote~~ ~~methods~~ must be defined in a Remote Interface		* Remote Methods must be defined in a Remote Interface
	* Remote Methods must throw a RemoteException		* Remote Methods must throw a RemoteException
	* Arguments to or return values of remote methdos must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.		* Arguments to or return values of remote methdos must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.
Line 28:		Line 28:
	* underscores in identifiers should be omitted to avoid name collisions with [[IDL]]		* underscores in identifiers should be omitted to avoid name collisions with [[IDL]]
	* [[IIOP]] does not support overloading		* [[IIOP]] does not support overloading


	== Implementing an RMI programm ==		== Implementing an RMI programm ==

203.112.80.142: /* The Client */

2004-12-06T09:23:32Z

The Client

← Older revision		Revision as of 09:23, 6 December 2004
Line 49:		Line 49:

	When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion		When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion
			dsdsd


	== Some further techniques ==		== Some further techniques ==

217.231.10.241 at 13:48, 22 November 2004

2004-11-22T13:48:28Z

New page

== General ==

RMI (Remote Method Invocation) is an Java API that allows for calling remote methods. Remote methods are methods that run in a JVM different from the one of the caller. Basically there are two different implementations: RMI/[[JRMP]] commonly just referred to as "RMI" and a [[CORBA]] compliant implementation called RMI-[[IIOP]].

=== Purpose ===

One of the foremost purposes of RMI is [[Wikipedia:transparency (computing)|transparency]]. Network communication is hidden from the application programmer. Calling remote methods thus (almost) does not differ from invoking local ones as far as programming is concerned.

=== Technical Overview ===

When the client invokes a remote method a so called stub on the client side marhalls the invokation and sends it to the actual server. There the data is demarshalled and the remote method is called. The return value takes the same way back.
The stub serves as a proxy to the client hiding the fact that the actual server is remote.

=== Restrictions ===

Although transparency is indeed accomplished to a high degree the programmer will still notice that he deals with remote methods since certain restrictions apply:
* remote methods must be defined in a Remote Interface
* Remote Methods must throw a RemoteException
* Arguments to or return values of remote methdos must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.
* each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original
* there is a call overhead
* security issues have to be considered

Some further restriction apply only to the [[IIOP]]-implementation:
* there is no distributed garbage collection available
* there is no dynamic class loading available
* there are no custom socket transports available
* underscores in identifiers should be omitted to avoid name collisions with [[IDL]]
* [[IIOP]] does not support overloading

== Implementing an RMI programm ==

The next few paragraphs will describe the basic steps of how to implement a simple RMI program

=== The Remote Interface ===

The Remote Interface simply defines methods that are supposed to be remotely available. The interface has to inherit from java.rmi.Remote, methods must throw a RemoteException, and there are some [[Remote_Method_Invocation_(RMI)#Restrictions|restrictions]] concerning the arguments and return values.

=== The Server ===

The Server then has to implement the just defined Remote Interface. It usually inherits from either java.rmi.server.UnicastRemoteObject or from java.rmi.activation.Activatable, the latter being able to start upon a clients call, whereas the former always has to be running.

=== The Stub ===

In order to be able to communicate with the server the client needs the server stub in its classpath. This stub is generated by the tool rmic, which is part of the Java SDK.

=== The Client ===

When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion

== Some further techniques ==

=== Serialization ===

Serialization is how Java marhalls objects. In order to make an object serializable the progammer has to have it implement the java.io.Serializable interface. Objects of this category are just copied in the process of serialization whereas only the stub is serialized with remote objects.

=== Registry ===

RMI brings its own naming server rmiregistry, which is accessed by java.rmi.Naming's static methods:
* bind(...) - which binds a server with a logical name to the registry
* rebind(...) - binding is successful even if the logical name existed before
* unbind(...)
* lookup(...) - returns a reference to the client that wants to connect to a server with a certain logical name
* list(...) - returns an array of all servers currently registerd with the registry

=== Dynamic Class Loading ===

Dynamic Class Loading allows the client during runtime to load remote class definitions that can be made accessible by a http- oder ftp-server.

=== Activation ===

Subclasses of Activatable can be indirectly started by calling clients. As the instance of redirection serves here the RMI Activation Daemon "rmid".

=== Custom Socket Factory ===

This allows for monitoring or encrypting the network traffic

=== Distributed Garbage Collection ===

In contrast to the normal Garbage Collector the dgc keeps track even of remote references to objects. When there are no local or remote references anymore the object is collected.