CS 5523 Operating Systems
Laboratory 4 - Spring 2001
Implementation a Remote Repository using Java Remote Invocation

Objectives:

• Learn about Java RMI.
• Learn to pass and use remote object references.
• Learn about object serialization and passing objects by value.
• Learn about using monitors for reader-writer synchronization.
• Learn about the basic operation of remote file services.

Overview:

In this laboratory you will write and test a shared file repository based on Java RMI. The project is divided on three parts:

• Part I: implement a local file repository and test by calling the methods of the FileRepository object from a main program.
• Part II: convert the code to be a remote file repository using Java RMI and test thoroughly using a single remote client to call the methods.
• Part III: make the methods synchronized to allow correct handling of multiple, simultaneous clients. Test by running multiple simultaneous clients on remote machines.

Note: Prior to starting this laboratory you should be sure that you have successfully run the SimpleHello remote server. If you have any problems in doing this, see your instructor.

Requirements:

• You will be writing three versions of the server, with associated test code.
• Your source code must be clean and clear. (It will be read and you will be graded on its quality as well as whether the code works.)
• This project must be done in Java according to the specification.
• You must hand in all source for each program separately.
• You must hand in the output files for each part separately.
• You must hand in a word-processed report of 3 to 5 pages summarizing the structure of your program, known bugs, how you tested the program, and answers to the questions posed in the assignment. Your report should also an introductory paragraph and a diagram of the architectural models implemented in this assignment.

Part I: The nonremote implementation

As part of this assignment, you will need to implement two interfaces: the Directory and the FileObject (e.g., DirectoryImpl and FileObjectImpl). In Parts II and III, the Directory will become a remote interface and FileObject will be passed to a remote object. You will need to modify them as described below.

• The repository: Design a DirectoryImplNonRemote class that implements the Directory interface:

  public interface Directory {
      public void create(String filename) throws Exception;
      public FileObject getFile(String filename) throws Exception;
      public Vector getListing( ) throws Exception;
      public void remove(String filename) throws Exception;
      public void update(FileObject f) throws Exception;
  }
  

  Your implementation should keep a Vector of the filenames of the FileObjects that have already been created in the repository. The Vector should be ordered alphabetically. Your implementation should keep the FileObjects of the repository in a hash table. Use the Hashtable class for this.
  • The create method creates a new FileObject object, puts the filename in its Vector of filenames and puts the FileObject in the Hashtable using the filename as the hash key. The create method throws an Exception if a FileObject with that filename already exists in the repository or if the object creation or insertion into the repository fails.

  • The getFile method returns a FileObject with the current contents of the file indicated by filename. The getFile method throws an Exception if an FileObject with that filename does not exist in the repository.

  • The getListing method returns the Vector with names of the FileObjects currently in the repository. If the repository is empty, an empty Vector will be returned.

  • The remove method removes the FileObject from the repository with the designated. The remove method should also invalidate the FileObject as described below. The remove method throws an Exception if the object is not in the repository.

  • The update method replaces the data of FileObject of the same name as f with data of f. The read and write methods of the FileObject are used. The update method throws an Exception if the object is not in the repository.

• The file objects: Design a FileObjectImpl class that implements the FileObject interface:

  public interface FileObject {
     public String getName();
     public int getSize();
     public int getVersion( );
     public byte [] read( ) throws Exception;
     public void write (byte [] b) throws Exception; 
  }
  

  The FileObject represents a file that has been put in the repository.
  • The getName method returns the filename of the object.

  • The getSize method returns the number of bytes of data in the file represented by the object.

  • The getVersion method returns the version number of the file represented by the object.

  • The read method returns an array of bytes containing a copy of the data in the file. The read method throws an Exception if there was an error in reading the file or in creating the array of bytes to return.

  • The write method replaces the data in the file with the bytes from the array b and increments the version number. The write method also updates the size. The write should first create a new local file to hold the data before removing the old one. The write method throws an Exception if it is unable perform the replacement.

  In your implementation, you must store the data for the FileObject in a disk file. Your FileObjectImpl should also implement a finalize method that removes the local data file associated with the FileObject. The finalize method will be called when the object is garbage collected. You can call Runtime.runFinalizersOnExit(true); to make sure that finalize is called on exit.

  Your FileObjectImpl should have a constructor that takes a String parameter filename. A newly created FileObjectImp must initially be empty. You will call the write method to actually put data in the file.

• Testing: You will need to test your implementation thoroughly before going on. You can either put test code in the main method of DirectoryImpl or write a separate test class.

Part II: Remote version with no synchronization

In Part II you will convert the Directory interface and the DirectoryImpl class to support remote invocation. As in part I, you can design a server class that instantiates a Directory object and registers it with registry. Alternatively, you can include that code in the main method of DirectoryImpl. In either case, pass the port number of the registry and the name that the Directory object will be registered under as command line arguments. These values should should be into the constructor of the DirectoryImpl class.

The FileObject interface represents a local object that will be passed remotely by value. In the remote implementation, the FileObjectImpl class must implement Serializable. The added complication in this problem is that the default technique for serialization will probably not work, because data from the object is kept on disk and local files only have meaning in a local environment. You will need to define your own methods with the following signature:

   private void readObject (ObjectInputStream in) throws 
                     IOException, ClassNotFoundException;
   
   private void writeObject (ObjectOutputStream out)
                     throws IOException;

    in.defaultReadObject( );

You can call:

    out.defaultWriteObject( );

Note: it would be wise to test the serialization of FileObjectImpl locally before trying to pass it by value in a remote call.

You should test your remote invocation and all of the methods with a single client. You should also find at least one other classmate to invoke methods in your remote object. You must report the names of the classmates whose remote repositories you accessed and those who accessed your remote repository.

Part III: Synchronization for multiple clients

If more than one client accesses your remote objects, you must provide synchronization. Each java object has its own monitor. When you declare a method to be synchronized, e.g.:

     public synchronized Vector getList( ) throws RemoteException

Test your synchronization by creating multiple simultaneous clients to access the repository.