Monthly Archives: June 2014

Demystifying JINI: Non-Secure Server: Part 1


What is JINI?

JINI is a framework that enables us to write Java-based distributed systems. In simple terms, it allows you to expose Java classes as services, which can be then called remotely by other Java based clients over the network. For more details, refer to

How is it different from RMI?

  • In RMI, the client should explicitly know about the server and then make a look-up. But JINI has the concept of discovery, where it attempts to discover the service through some known search parameters.
  • RMI does not support distributed transactions or events, JINI has support for that and lot more.
  • RMI does not support dynamic code download from the server, JINI does. This means that the client is more loosely coupled and not necessarily tied to a particular protocol.

Where do I find it?

Its hosted at

Reason for this blog

I came across this in my current project and wanted to explore more about the hows and whys. The problem was acute shortage of documentation on the internet, probably because very few people use this. Also, the documentation and code sample available at the apache-river site were bloated and far from simple. They just created confusion. So I decided to write my own simple implementation using minimal amount of code and configuration.

Writing a bare bones, non-secure client/server using JINI

High Level Overview

Our implementation will consist of the following 3 components:

  1. The RmiServer: This will expose services which can be invoked as Java method calls across the network.
  2. The RmiClient: This will consume the remote services provided by the RmiServer.
  3. The Registry: This will act as an intermediary between the client and the server. The server will register the services its exposing, with the registry. And the client will do a look-up for the desired service from the registry. We will be using the reggie component of the apache-river project for our Registry.

Please note that to keep this simple, we are not using the dynamic code download feature that JINI provides. A downside of that is, the client also has to be bundled with the JINI-specific libraries at runtime. If you ask me thats not too bad actually.

 Setting up the Maven dependencies

Both the Client and the Server should have the following JINI-libraries dependency:

 Creating the Remote interfaces

We will have the following two interfaces which we will expose as services:

Note that these extend the java.rmi.Remote interface and also, each method throws the java.rmi.RemoteException exception. These two interfaces will be shared between the Server and the Client.

The Server

The Client

The Reggie

The reggie should be configured properly, and this must go hand-in-hand with the server. For example, they should use the same protocol, in this case, JRMP. If it uses JERI, then both the server and the reggie should use JERI.

This is the start config file for reggie [start-reggie.conf].

After that, we need the following file for specifying the protocol as well [jrmp-reggie.conf]:

Refer to the JINI documentation for the configuration details.

Putting it all together

To see this in action we need to first start the reggie service. Unpack the From the command prompt, cd into it and:

java -Djava.ext.dirs=lib -jar start.jar config/start-reggie.config

Then, start the server using the main method.

For running the client, you need to create a policy file [called policy.all] containing the following:

grant {

When running the client, give the following JVM arguments:

You should see the out from the remote server.


The code can be found in GitHub, under the code/jini/unsecure/plain: