RMI verifications/questions

[Timothy Johnson]

Not to be a complete "reposting the same topic for the 18th time" goober, but I'd really like to verify a few things about my RMI implementation.
Below, I've pasted a piece of my requirements regarding RMI...
******
Restrictions on RMI
To avoid unnecessary complexity in the marking environment certain restrictions are placed on solutions that use RMI. Specifically:

You must not require the use of an HTTP server.
You must not require the installation of a security manager.
You must provide all classes pre-installed so that no dynamic class downloading occurs.
You must use RMI over JRMP (do not use IIOP)
*****
Being an RMI newbie, I zipped through the jGuru tutorial on the Sun site and I also have Max Habibi's book, which contains some very useful RMI information. That said, my RMI server startup code looks like:
LocateRegistry.createRegistry(serverPort);
DataRMIServer drmis = new DataRMIServer();
Naming.rebind(RMI_SERVER_NAME, drmis);

And my client code looks like:
server_ = (ApplicationFunctionalityIF)
Naming.lookup(
"rmi://"+serverLocation+":"+serverPort+"/"+RMI_SERVER_NAME);

Now for the questions/verifications:
- I'm not doing anything with an HTTP server because I'm not setting any of the relevant JVM parms (ex. java.rmi.server.codebase) and my network clients will have all of the rmic generated code (only the stub and interface extending Remote are required I believe).
- Even though I think a SecurityManager is required for dynamic class loading, I haven't written any code referring to a SecurityManager. And I haven't tweaked any settings that should affect one either, so I must not be "requiring the installation" of one, eh?
- Since I don't specify the -iiop option when I use the rmic tool, I must be using JRMP.
- My RMIServer extends UnicastRemoteObject and implements DataRMIServerIF (which extends the Remote and ApplicationFunctionalityIF interfaces) and since I have gone with UnicastRemoteObject, there is no need to worry about clients dealing with "disappearing objects" (jGuru tutorial mentioned this in regards to Distributed Garbage Collection), right?
- Since I have gone with UnicastRemoteObject (I'm assuming this implementation runs the whole time the server is up), there is no need to consider using the Unreferenced interface, right?
- I don't need to handle starting the RMI registry because my server code does this programmatically.

Thanks a lot.
-Tim

[Mark Spritzler]

Almost all correct.
"there is no need to consider using the Unreferenced interface, right?"
No, you should consider the Unreferenced interface, or the WeakHashMap for handling crashed clients.
Other than that, I think you put it beautifully.
Mark

[Timothy Johnson]

Hey Mark,
Thanks for the input, much appreciated. In my implementation, I have a business layer in between the RMI server and the data layer. So, locking is invisible to the client. Is the "lock expiration" issue (in cases where a client dies) the reason for considering the use of a WeakHashMap or the Unreferenced interface? Other than that scenario, I can't think of a reason why I'd care to do anything if a client crashes or all references to my RMI server are gone?
Thanks again,
Tim

[Mark Spritzler]

Yes, just for that reason.
Mark

[Jim Yingst]

[Timothy]: there is no need to consider using the Unreferenced interface, right?"
[Mark]: No, you should consider the Unreferenced interface, or the WeakHashMap for handling crashed clients.
Slight modification - I'd certainly encourage you to consider it, but if you don't, you can still get a perfactly good score on the assignment. So there's not exactly a need to consider it. And if you do consider it, you can certainly still reject it later as either (a) too much added complexity for negligible gain, or (b) not necessary in view of other aspected of your design (e.g. if you've got a 3-tier solution in which unlocking is taken care of by a server-side finally block, there's not really a way for a disconnect to cause deadlock.)
Personally I am using Unreferenced, and don't find it too complex - but I don't want you to think it's mandatory by any means.

[Mark Spritzler]

Jim, aren't you done your assignment yet?
Mark

[Timothy Johnson]

Thanks fellas.
For the sake of this project and the exam do you think that I should further explore going the Activatable (vs. UnicastRemoteObject) route? I'm perfectly content with the UnicaseRemoteObject functionality but I'm terrified that I'm going to get an exam question requiring me to go into detail regarding why I chose UnicastRemoteObject over Activatable. I can give high level info but not having done anything with Activatable, I'd kinda be screwed in that situation.

Thanks,
Tim

[Mark Spritzler]

"do you think that I should further explore going the Activatable"
For this assignment, NO.
Mark

[Timothy Johnson]

cool.
-Tim