Project 1

Designed by Kohei Honda

Department of Computer Science, Queen Mary and Westfield College, University of London
March 2000

Design and Implementation of Basic RMI Mechanisms: my pet RMI for Java

This document together with the following offer the guide for this project.

• Further Technical Specifications
• Simple Registry describes the registry that is provided because you cannot use the Java RMI Registry for this exercise.
• Testing Method explains how I intend to test your RMI.
• Test Programs describes the programs used to test your program.
• Hints are available in case you are really stuck.

The following Java program code is also provided:

• Registry and remote object references
  • SimpleRegistryServer.java. The simple registry server
  • SimpleRegistry.java The client code to access the simple registry
  • LocateSimpleRegistry.java The client code to locate the simple registry
  • testRebind.java for using the registry
  • testLookup.java for using the registry
  • RemoteObjectRef.java gives a definition of a class for representing remote object references
• First test program: the zip code server and client
  • ZipCodeServer.java the interface for the server of zip codes (post codes).
  • ZipCodeServerImpl.java the implementation of the interface of the zip code server.
  • ZipCodeList.java A class used by ZipCodeServer
  • ZipCodeClient.java a client program for testing your program.
  • Example data for the zip code client.
• Second test program: the zip code server and client that returns remote references
  • ZipCodeRList.java  the interface for the server
  • ZipCodeRListImpl.java  the implementation of the interface of the server
  • ZipCodeRListClient.java a client program for ZipCodeRList for testing your program.
• Alternative second test program: the name server
  • NameServer.java interface
  • NameServerImpl.java implementation
• Some programs showing how to carry out part of your task
  • yourRMI.java an outline of the implementation of the CM in the server
  • RORtbl.java an outline of the remote object table implementation

1. Objective

To deepen the understanding of basic RMI mechanisms through:

1. The design of a general framework of (your own) RMI for Java on top of TCP; and
2. an implementation of (1) which functions for a  restricted set of classes  and primitive data types;

focussing on: (i) marshalling and unmarshalling mechanisms, and (ii) communication mechanisms.

Once (1) is done, part (2) cannot be difficult. I hope you will enjoy this project, and that it will be intellectually rewarding.

2. Your Task

In short, you produce:

1. one short document, and
2. a few classes, including hand-compiled proxy and skeletons for two given programs.

You are not expected to implement an RMI compiler.

The work will be carried out by teams with about four members. Each team will work together to produce the following:

1. A document describing a basic design for "your pet RMI". A "pet RMI" means an RMI mechanism which realises the same RMI functionality as Java RMI but which does not use Java RMI itself. (That is, you can denote an invocation of a remote method in a program in the same way as when you use Java RMI.)

   Since RMI with full functionality is a too big a task, I have restricted the classes you need to handle to simple ones: see (3) below and the "further details" for this.

   There are a few basic conditions for your RMI:

   • It should include the standard RMI components (described in CDK3 Section 5.2.5), such as proxy, skeleton, communication modules, remote object tables, etc.
   • You do not change the Virtual Machine (VM): you implement everything using the Java libraries.
   • It is to run on top of TCP.

   Meeting these conditions, the document should be short (10 pages to 20 pages (exceptionally ~30 pages), and should include:

   • A very short introduction outlining the content of your report.
   • A description of the general architecture, with an illustration of how its components interact with each other to realise RMI.
   • Key design decisions, including the fundamental data structures such as remote object tables, and the marshalling/unmarshalling mechanisms.
   • Basic classes and their non-private methods, together with brief descriptions of them (important ones would be given long descriptions; while trivial ones very short descriptions).
   • Observations on your design, including a comparison with other possible designs.

   The internal structure of (your) RMI registry and (your) rmi compiler need not be discussed: a description of what they input and what they output are enough.

   The document as a whole should make it clear how an invocation of the form:

   x=r.method(v,...);

   can be compiled and can act as a RMI, where r is a your remote object residing in a different VM (well in fact r is a proxy, but conceptually speaking it is remote).

2. A Java program (classes) which implements (1) above *except* the registry and the rmi compiler: you should however have a hand-compiled stub and a hand-compiled skeleton of supplied test classes. I hope you remember how RMI works - further technical details offers some more hints, but basically:
   • You need to build an object (class) which is called by a proxy and communicates with a remote host via TCP. It should use a "marshalling" mechanism (do you remember what marshalling is?).
   • You need to build an object (class) which can receive such a communication via TCP and call an appropriate skeleton.
   • I do not say further what would be needed, except that: the returned value should come back to the invoking object.

   You also need hand-compiled stubs and skeletons.

   NOTE: The implementation does not have to be strictly faithful to (1) but should follow its general design. The default registry service with source codes is provided. The test programs should be able to run combined with your corresponding proxy and skeleton. Your implementation should work for general RMI programs of restricted class as specified, with the supplied registry and if you had implemented an rmi compiler (the latter you do not have to provide, as noted above).

3. For simplicity, your RMI need only deal with a restricted subset of classes: those classses which directly subclass Object. That is, your marshalling and unmarshalling procedures need deal only with those classes. [Of course, your implementation may use any class excepting those that provide Java's RMI functionality itself].

Further detailed technical specifications which you should consult before starting to work can be found here. That document in addition offers suggestions for both design and implementation, and points out those Java classes which may be useful for this project, such as those related to TCP and reflection.

As noted above, I offer a default simple registry server with a specific format for remote object references. If you refine/enhance the format for remote object references, then you will need to revise/change the way they are use in the registry. After and the test programs.

3. Assessment

The key aspects I wish to check are:

1. design: whether it is functioning as a whole, with emphasis on marshaling/unmarshalling and communication mechanisms; interesting design ideas.
2. implementation: whether a test program does run or not; it soundly implements the basic framework in (1) or not (*); good implementation ideas.

The basic requirement is that your design is sound, that your implementation is basically faithful to the design, and that the test program runs. If so you will get a major portion of the marks. On this basis, you can further develop your ideas. (*)  Some discrepancy between (1) and (2) would be allowed, though it is better that the difference is well-documented in some way.

                                                                                                                                  [K. H. , March, 2000]