Question:
We are now developing a Java-based remote monitoring systemapplication for our SCSI RAID subsystem products. This application canenable our customers to monitor the status, and change theconfiguration, of the SCSI RAID device being monitored. We are usingC++ for the SCSI programming part and we are using JNI to interfacewith the rest of the server side of our application. Should we use RMIfor the networking needs of the client and the server, or should wejust use simple socket-based networking?
Answer:
RMI has the advantage of being relatively powerful and easy toprogram. Remote objects look like local objects and networkcommunication happens transparently when their methods are invoked.
However, RMI also has the disadvantage of being relatively slow and not veryfault-tolerant. Remote methods are synchronous, which canfreeze applications when the network is down. That makes RMIunsuitable for applications that need to abort communicationwhen stalled.
Although this deficiency can be worked around with the use of threads, it does not possess the flexibility of using sockets withtimeouts and non-blocking I/O. Then again, non-blocking I/O is not possible withJava, so this has little bearing.
RMI is more suitable for use in the configuration part of your clientapplication because configuration utilities are not fault-sensitiveand have little need for optimized network communication. Themonitoring part of your application is very likely unsuitable for usewith RMI if it is a constantly running monitoring system that requiressome level of real-time information delivery. Using a custom protocolover sockets will yield better results. However, if the monitoringis only single snapshot monitoring, where a user observes the statusof the device only occasionally, then RMI is a good implementationapproach.
