| Introduction
What is RMI The Distributed Calculator:A Simple Example Scaling Up: Enterprise Concerns |
The Calculator as an Applet
--
Practical Experiences in RMI Programming
RMI Programming for Applets While there are many outstanding books and tutorials availble on the
topic of RMI, there are very few concrete examples of using RMI with an
applet interface. I found this to be an odd omission in the literature
at hand. As I now suspect the reason for this is because the applet application
injects a level of indirection into the Naming and Lookup Mechanism (the
server must talk to the remote methods as well as to the applet code) and
adds a level of complexity to Security issues by attempting to load an
applet with remote references into a browser.
RMI Programming for Applets - A Practical Example I began preparing for the Applet version by attempting to compile and
run several example programs - the RMIAuctionServer at http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/rmi.html,
I was able to quickly get each of these running as a command line application with little difficulty. The HelloWorld example was the only one which included any sample applet code, but the simple HelloWorld applet refused to load into either the browser or the appletviewer. Worse yet, the results were inconsistent between them - the appletviewer yeilded errors to the effect of "applet not initialized" while the browser would simply hang at "loading C:..." Not even the Java console yeilded an error on the browser. Undaunted, I set about converting YanPing's application code into an applet version extending the Naming, Lookup and Rebind methods to throw specific exceptions and adding them as the first methods called in the init() method of the calclientApplet.java. I extended the exceptions of the calculatorServerImpl as well and added System.out messages in order to track the startup sequence. After recompiling and meddling with the code for quite a while, I was able to coax the entire thing into starting in separate memory spaces and was able to get the applet to load into the browser as well as the appletviewer. The function method servers were started in separate memory spaces and no exceptions were thrown when loading the applet. This proves that server and all clients were entered into the registry. Calling a remote method, however produced an addServer NotBound exception from the applet: C:\$user\DS420\BP\calc\temp> java calculatorServerImpl
C:\$user\DS420\BP\calc\temp>java addServerImpl
C:\$user\DS420\BP\calc>appletviewer calculator.html
So it appears that in this version, both the calculatorServerImpl
and functionServerImpls start without throwing exceptions, i.e. all are
bound into the registry. The exception was thrown by the applet but not
until the method was called. It is unclear at this point as to why this
would occur. These problems grew more complex as I continued.
Comparison to CORBA I moved on to try the CORBA assignment with the idea of going back to the calculator applet. Since I had been using Java 1.1.7b, I downloaded Java 1.2 and was able to run the CORBA examples with few problems. In these simple examples, CORBA is very similar to RMI - CORBA requires the use of the idltojava compiler to generate stubs and skeletons while RMI uses rmic; both CORBA and RMI define a marshaling protocol which Java thankfully leaves in the background; CORBA uses tnamserv for Naming and Lookup services while RMI uses rmiregistry. Both require similar application code to find remote methods and invoke them. The big difference seems to be in RMI's use of the registry as a Security
mechanism and the more stringent security requirements of Java 1.2 in general.
RMI Security After installing Java 1.2, the same calclientApplet.java and serverImpls refuse to run at all: C:\$user\DS420\BP\calc\temp>java -classpath . calculatorServerImpl
Apparently Java2 requires a java.policy file in order to grant security
permissions [http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/rmi.html]
The security issues involved in using RMI with applets appear to be
that the applet running in the browser's VM must invoke methods outside
the VM, which are generally not allowed in applet programming. Since
the remote methods are not resident on the server from which the applet
was downloaded, it is hard to imagine how a local browser VM might
be coaxed into referencing a method located on a 3rd party. I suspect
that objects referenced by an applet must also extend Serialized. Some
more investigation is needed.
Conclusions At this point, although my attmepts to call RMI from a browser have
been futile, some interesting points have arisen. Java security issues
are clearly demonstrated. RMI programming in general appears to yeild a
number of benefits:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Late Update (and a small victory): finally was able to get calclientApplet to run in appletviewer by changing appletview-properties-class access to UNRESTRICTED. The Applet still does not run in the browser, however. It appears
that Netscape at least might accept some sort of Certificate attached to
the applet... this will require still further investigation.
|