S.N.S. - Simple Naming Service (Java/RMI)

Created by: Harris Georgiou - mailto:xgeorgiou@yahoo.com

University of Athens - Department of Informatics,
Postgraduate Program (MSc),
Digital Signal Processing & Computer Systems.

Introduction

This page describes the structure and functionality of the SNS application, aimed as a tutorial application for the introduction of Remote Method Invocation (RMI) technologies in Java, for the development of a simple distributed naming service. All package compiled and source files can be downloaded in one .zip file archive:

SNSpack.zip (~20K)

As always, all software is distributed fro free use under the terms of MPL-Mozilla-v1.1 licence. For any comments, questions or bug reports, feel free to contact the author.

1. General Description

The SNS application is an example of using the Java/RMI framework in order to implement a simple distributed naming service. The application is employed according to the client-server model and the basic functions provided are:

register ( svr_name, svr_version, interface, address )

unregister ( svr_name, svr_version )

lookup ( svr_name, svr_version, interface )

The first two functions are used for the registration and removal of interfaces from the registry of the service, according to the name and version of the related server. The third function is used for the retrieval of the address related to a specific interface.

2. Functionality

2.1 Distribution

The implementation of the SNS services are based on the RMI framework for remote method calling from the clients. As the main factor in similar distributed services is modularity and flexibility, at startup the server saves all the necessary information to a local file (SNSRemote.cfg), containing the current address and port of the RMIregistry service, along with the nameID by which it is registered. That local file can be distributed off-line along with each client program package, or posted on-line and updated periodically, so that the clients can access the SNS server dynamically.

2.2 Registry

The registration records on the SNS server are organized using a multi-level hashing table. In practice, the registry structure contains two separate hashing tables (Hashtable), the first one used as an index directory for the second. Every new registration request gets separated in two sections: name/version and interface/address pairs. The first pair is registered in the index directory for later references to the specific name and version info, while the second pair is registered in the interface/address directory at the second level, in relation to the index record at first level. Thus, all registry information are available at any time, with the interface/address records accessible by one specific server/version reference at the index diretcory. In case of server registration removal, the whole sub-index is destroyed. Naturally, mutli-level hashing tables are not the optimal way to organize large registration records, but it is more than enough for this specific application as it is a very simple and efficient way to implement a fully dynamic structure for organizing the naming service registry.

3. Implementation

3.1 Source Code Structure

The source code of the application is made up from two source packages. The first one refers to the server program and the second to the client program. Aside from the source code of the client program, all other files refer to the server program.

SNSException
     .
     . . . . SNSNotFoundException
                   |
                   |
                   |
                SNSRemote . . . . SNSRemoteImpl
                                      |
SNSKey - - - - - +                    |
                 |                    |
              SNSRecord - - - - - - - +
                 |
SNSValue - - - - +

(SNSNotFoundException) - - +
                           |
                        SNSClient
                           |
(SNSRemote) - - - - - - - +

This figure above presents the functional (-) and hierarchical (.) dependencies between the modules of the whole package. Classes SNSException and SNSNotFoundException implement the generic exception and failed search exception classes accordingly. Classes SNSKey, SNSValue and SNSRecord are used for registry organization and management on the server side. Class SNSRemote is the main remote interface shared between the client (remote access) and the server (implementation) programs. The main client program is in class SNSClient, while the main server program is in class SNSRemoteImpl.

3.2 Compiling and Installing

The application contains the client and the server program packages. For the corrent compilation of both packages, the following procedure is proposed:

α) Compile the server program:
    /svr: javac *.java
β) Create the stub and skeleton modules:
    /svr: rmic SNSRemoteImpl
γ) Copy all necessary dependencies into the client sources path:
    copy *.class: SNSException, SNSNotFoundException, SNSKey, SNSRemote, SNSRemoteImpl_Stub
δ) Compile the client program:
    /cli: javac *.java

3.3 Running

Due to some technical problems with v1.2 of Sun's Java SDK in Windows platforms, in order for the RMI registry service to function with no problem, rmiregistry executable may have to be copies and executed from the server program path. When the RMI registry service is up and running, the SNS server program can be started. Local address and port number are displayed and stored in the SNSRemote.cfg configuration file (local), which can be copied or posted for use from the client programs. Finally, client programs can be started too, providing four basic functions: register, lookup(1), unregister and lookup(2). The first option registers an interface, the second runs a lookup of that interface in the server and the third one unregisters the interface. The fourth option is used to test the case of a failed lookup in the server directories. All client requests and results are presented in the client console, while incoming requests are displayed in the server console while they are processed.

4. Technical Details

4.1 Comments

Due to technical problems with interface creation (RMI socket connections) even in localized connections, default security managers (SecurityManager) present too strict restrictions for RMI connections, making remote calling impossible in some cases. As the application is fairly simplistic and tutorial in nature, no active RMISecurityManager was used in the final implementations.
There are some changes in RMI API implemented in version 1.2 of Sun's Java SDK. Specifically, UnicastRemoteObject is used instead of UnicastRemoteServer and RMISecurityManager is used instead of StubSecurityManager. For further details, please refer to the RMI API documentation of each specific version of Java SDK.
Although Sun's documentation on RMI API and rmiresigtry program reports that the remote stub can be automatically fetched by the client program, however this does not seem to be the case in all platforms.Furthermore, rmiregistry program should be started after the server path has become the current path, otherwise the stub modules cannot be located by the RMI registry.

4.2 Development

Development Platform:

O.S.: MS-Windows98, MS-WindowsNT, RedHat Linux 4.2
Java: Sun's Java 2 JDK 1.2.2, Guava/Kaffe (GNU/Linux)
H/W: iPentium/133-32MB, amdAthlon-K7/500-128MB, SunSPARC/station4-16MB
Net: TCP/IP on EtherLAN, TCP/IP on PPP (both local & remote)

4.3 Bibliography-References

"Hacking Java - The Java Professional's Resource Kit", Mark Wutka, QUE - 1997.
"Java Quick Reference", Michael Afergan, QUE - 1996.
"White Paper: Java Remote Method Invocation - Distributed Computing for Java", Sun Microsystems - 1999.

Last updated: 15-Apr-2000.
Harris Georgiou
http://xgeorgio.n3.net
mailto:xgeorgiou@yahoo.com