Is RMI the best way for Applet to Java communications?

Question

I have an application that uses a Java program to read values from a PLC (programmable logic controller) via ethernet. I want to display them in Internet Explorer. Currently, I use SQL statements in the application and an applet to pass the values, but this causes the hard drive to be busy all the time. A better way would be to have the applet pass which registers to read for the current page to the application. The application then reads these values once every second (to update the page) and passes them back to the applet. Is RMI the best way to do this? The application and the applet run currently on the same PC, but I can envision going with a client/server architecture at some point in the future. Please respond to: [email protected] or [email protected] Thanks!

Answer 1

Writing to the DB and reading back is not the best way of achieving IPC. You can use DB directly as long as both applet and application have permissions to do that. This has an advantage that it avoids RMI overhead (though not much). You would not be able to do this if your applet is going to be launched on a web environment (as typically, security policies do not allow you to write/read on local machine's DB or any m/c other than web-server's).
I feel your current approach has the following
advantages:
--> There's no RMI(or any other IPC mech.) overhead involved.
--> Best way to communicate if applet is permitted to do all the things that the application can do on DB.
limitations:
--> When applets are launched through web, this approach would work only if the DB resides on the same m/c as web-server(JDBC).
--> Lot of DB I/O, table locks etc... affect performance. Application alone can do all that activity(minimized) and communicate it to the applet through RMI/callbacks.
Alternate/better approach:
RMI and Servlet combination can be used in order to overcome those limitations. In this scenario, your applet gets downloaded on to the client's m/c, servlets (which make RMI calls to the application running anywhere) reside on the webserver's m/c. applet talks to servlets, which in turn communicate with application(DB). This approach would work in any scenario, but not without the overheads of RMI and/or HTTP. But in my experience, I have noticed that these overheads are not too large.
To decide upon the strategy to be employed, you should consider all the possible deployment scenarios of your system. For passing any object, you may use RMI for reliable, easy communication. It can serve more purposes than just passing DB data. This will make your system extensible.
regds,
CA