1)Do you need an HTTP server to use RMI?

Technically, you don't need an HTTP server to use RMI. You can always place the stub classes for the remote objects, along with any user-defined classes, within the client's CLASSPATH. But such a deployment is highly inflexible, and feasible only for the more simple implementations.

In most real-life RMI deployment scenarios, the client retrieves all the classes dynamically via the HTTP protocol, by interacting with an web server running on the same host as the remote server objects.

2)Can my remote object obtain notification when there are no live references to it?

Yes, you can enable remote objects to get notified as soon as there are no valid references to it. Although the distributed garbage collection mechanism takes care of memory management issues, explicit notification can help the remote server release valuable resources like network and database connections immediately.

Any remote object that implements java.rmi.server.Unreferenced interface can get immediate notification via the unreferenced() method as soon as the server does not have any valid references to it. The following code snippet demonstrates how:

public class RemoteServerImpl extends UnicastRemoteObject implements 
          MyRemoteInterface, Unreferenced {
          public RemoteServerImpl() {
            . . .
            //allocate resources
         . . .
         public void unreferenced() {
            //deallocate resources here

3)How does the Distributed Garbage Collection algorithm work?

The RMI subsystem implements a reference counting-based distributed garbage collection (DGC) algorithm to provide automatic memory management facilities for remote server objects.

Basically, DGC works by having the remote server keep track of all external client references to it at any given time. When a client obtains a remote reference, it is addded to the remote object's referenced set. The DGC then marks the remote object as dirty and increases its reference count by one. When a client drops a reference, the DGC decreases its reference count by one, and marks the object as clean. When the reference count reaches zero, the remote object is free of any live client references. It is then placed on the weak reference list and subject to periodic garbage collection.

4) By default, what port does the RMI registry listen to?

The rmiregistry program uses port 1099 by default. You can have it listen to a different port by specifying a different port from the command line:

rmiregistry 1234

5) How can I develop a chat system using RMI?

Well, to tell you exactly how to do it would take up too much space, but to give you an idea, you would basically create a server which listens for connections on a port and accept these connections and get each clients names. Then you would develop a client program which connects to this server. When one "client" types a message and presses 'Send', the message is routed through the server and out to all "client's" connected. This can be done by Input/Output streams, or (the easier way) RMI.

6) If a class implements both the Serializable and Remote interfaces, is the stub serialized and sent to the client or is the object?

If an object implements java.rmi.Remote, then it is treated as a remote object - that is, its stub is serialized and sent to the client. This is true whether or not the object also implements java.io.Serializable.

If the object is not an instance of java.rmi.Remote, then RMI will attempt to serialize the object itself. This will succeed only if the object is serializable, i.e. implements java.io.Serializable or java.io.Externalizable.

7) What is the benefit of using RMI over IIOP?

Remote Method Invocation (RMI) over Internet Inter-Orb Protocol (IIOP) delivers Common Object Request Broker Architecture (CORBA) compliant distributed computing capabilities to the JavaTM 2 platform and to the Java Development Kit (JDKTM) 1.1. RMI over IIOP was developed by Sun and IBM. The joint work by Sun and IBM to implement Object Management Group (OMG) standards demonstrates the spirit of collaboration that continually moves the Java platform forward.

RMI over IIOP combines the best features of RMI with the best features of CORBA. Like RMI, RMI over IIOP speeds distributed application development by allowing developers to work completely in the Java programming language. When using RMI over IIOP to produce Java technology-based distributed applications, there is no separate Interface Definition Language (IDL) or mapping to learn. Like RMI, RMI over IIOP provides flexibility by allowing developers to pass any serializable Java object (Objects By Value) between application components. Like CORBA, RMI over IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group. Like CORBA, RMI over IIOP uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform.

8) How can my servlet class which subclasses GenericServlet/HttpServlet provide an RMI service?

Instead of letting your service subclass the java.rmi.server.UnicastRemoteObject class it is possible to make a call to the static method in the same class: exportObject(Remote). Thus you should let your class subclass GenericServlet/HttpServlet and implement a Remote interface. In the init(ServletContext) method your instance can export itself.
A simple example follows (exception handling omitted) :

public class MyServlet extends HttpServlet implements MyRemoteInterface {

  public void init(ServletContext ctx) {
  // rest of code goes here...

9) Can my remote client also serve as a remote object?


Just make sure your remote client is implemented as an RMI service, implementing a Remote interface and beeing exported as a UnicastRemoteObject (either by subclassing UnicastRemoteObject or by using the static exportObject() method of that class).

If this is done, a reference to the client can be sent to the server as a parameter of a server method, and the object will not be serialized as other parameters, but a remote reference is established.

The server can now call methods of the clients remote interface via this reference!

No comments: