Hi Richard,
Using sockets is a valid choice - Sun say so explicitly in their assignment. However I think there are some things you are misunderstanding, so the following will try and explain a few things so you can make your choice with the right facts.
Sun's method entails setting up an HTTP server Not sure which tutorial you downloaded. RMI
can use a HTTP server, but it is not required.
This thread has some links to other tutorials at Sun, which from memory do not require a web server or a security manager.
Java comes with it's own RMI Registry program (called
rmiregistry ) which you can use. Even better - you do not have to start an external program to use it ... you can start it programatically within your own application. And although it defaults to listening on port 1099, this is just a default - you can change that programatiically as well.
Sun's method entails setting up .... a security manager There is no need for a security manager for this application. You need a security manager if you are downloading code from the server, however you do not need to do this for this application. When you decide which methods you wish to use remotely, you will run the RMI Compiler (
rmic) which will generate a file named
<class name>_stub (so if your class was called Server.java, you would get a new file created called Server_stub.java). Since this stub file will be in your executable jar file, the client application will already know where it is, and it will not attempt to download the stubs dynamically.
As for the point that, if I don't use RMI, I must work out an ad-hoc protocol to transfer info: I must implement a stand-alone mode where there is no object serialisation. So I must work out an ad-hoc protocol to transfer info *anyway*, so what's the extra difficulty with sockets? In stand alone mode, you are not using an ad-hoc protocol (or any protocol) to pass data - you are calling methods in classes and using the data it returns.
But if you use sockets, then you have to work out a protocol for connecting the clients to the server, creating new threads to handle the connections, transfering the query from the client to the server, and for transferring the results from the server back to the client.
With RMI, you simply write your application as though it was all being run locally. Then you just declare some methods to be remote methods, do a recompile, and let Java handle all the messy bits.
OK, I left out a few steps, but not much. To make this clearer, here is example code to run locally:
Now lets make it RMI:
And on the server side, I have an interface:
And server code:
That was not very difficult!
Actually I left stuff out - primarily exception handling. And this is in no way the correct code for the assignment, but you should be able to see how easy this is.
Contrast this with writing raw socket code. Just connectivity would be more than this. Then you have to serialize your objects and pass them over the network and rebuild them on the other side, and you would have to work out your protocol to handle all this.
Hope this cleared some things up.
Regards, Andrew