Remote Method Invocation - what and why

The applet above is using Java's RMI mechanism to access structured matcher objects residing on the ai-web server. The idea here is the applet obtains a reference to a remote object, in this case a structured matcher, and sends messages to it. Processing therefore occurs on the server rather than on the applet. This reduces the amount of code the applet has to request from across the network, thereby yielding faster load and execution times. Unfortunately right now the applet is still a stub because of some technical issues which will be discussed.

How many remote objects do we have?

The short answer is one. Only a single instance of a remote class is bound to a service name and a virtual reference that particular instance is returned when a client looks the service up in the registry. This means that multiple clients share the same object for a given service. This is not good for our plans because we want different instances of a structured matcher for each client. If clients shared a structured matcher, confusion would reign as the matcher would not know which client is answering which question. This problem is solved by registering a structured matcher factory at the server which the client can then use to create individual instances of remote structured matchers (see Fig.).

Fig. After the server registers the factory, the applet looks up the service to get a factory.
The applet then uses the factory to produce an instance of the remote matcher.

Asking questions remotely

The remote structured matcher which resides on the server has to ask questions as part of it's function. In the original implementation, it would pop up a dialog from within its matching algorithm. Not a very good design since it is not very extensible. It was redesigned to use some nifty OO ideas such as listeners to allow the matcher to ask a question and a question listener to answer it. The problem still remains that this technique relies on call backs which a server cannot execute with RMI unless the client itself becomes a server. This is because with RMI, only clients can initiate requests and send messages. The server can respond only with the remote method returns. The server cannot initiate a callback method with an applet because an applet cannot start a remote registry. The solution to this is some sort of polling algorithm that the applet must implement to get the questions.

Applet limitations with RMI

It may come as a surprise to some that many java tools in the JDK are not stand alone executables but are shells into internal sun classes that can be invoked programmatically. These include the javac compiler (sun.tools.javac.Main) and rmiregistry (sun.rmi.registry.RegistryImpl). Attempt to start the registry from within the applet has been greeted with a security exception. Apparently, the registry tries to install it's own RMISecurityManager, an attempt the AppletSecurityManager did not appreciate. In the process of researching ideas on making the applet client become a server, an interesting security feature was revealed. It is possible for an applet to find the client host name through RMI. Try clicking on the applet button for a demo.

Polling the remote object for questions

This algorithm is based on the consumer producer problem and involves threads waiting on a question to be asked and on the answer. The remote structured matcher produces questions and the applet consumes them and returns a reply. The algorithm also relies on a remote object being able to handle more than one thread sending it messages. The burning question the researcher here are trying answer is whether the remote object can handle a new remote method call while the thread that is handling a previous call is waiting on a condition. Due to the urgency of a take home final from Zenor's class, research may have to be suspended while the Finals usurp processing priority in this researchers limited CPU and bandwidth.

Stay tuned for further developments