Most (all?) people here seems to have chosen RMI and not sockets, why is that? What are the pros and cons of RMI compared to sockets? Especially the cons of RMI are interesting to here, but also the pros.
CONS: 1) Server and client sides need to be written in Java 2) Overhead is more compared to Sockets and serialization PROS: 1) Thread management is done by the RMI system in the server 2) RMI Registry helps you deploy your server side code dynamically with out distributing to the every client 3) RMI Registry helps you to locate the remote server objects 4) Very less code to communicate with the server compared to sockets 5) RMI takes care of marshalling and communication between the client and the server 6) By implementing Unreferenced interface, remote objects can be notified when the lease time expires between the client and the server. This nofitication can be used to remove unreferenced locks held by that client 7) RMI env provides a way to export and bind the remote object to the RMI Registry. The remote class should extend UnicastRemoteObject and no need to write any code. 8) Handles security via RMI Security Manager to avoid malicious code distribution
Thanks for good answer, Sai. I'm not sure about cons 1, since serialization of java objects is pretty much a Java specialty. Here are two RMI cons: a) You need to handle a security manager even in those cases were security isn't an issue- like explicitly written in the requirements for the assignment. b) You can't use the thread object as client id in lock manager, since you can't be sure that a client always gets the same thread. And a RMI pro: a) Less thread intensive, compared to keeping socket sessions with a thread for every client. My statements above are as much questions as statements, sinceI have limited knowledge in RMI. Please continue argue this one.
My PROS and CONS are for RMI. You don't have to use RMISecurityManager in RMI. In my submission, I didn't use RMISecurityManager since you bundle the _Stub instances with the client class files. Also you are right about identifying thread id with the client. You cannot rely on RMI assigning a unique thread for each client.
Here are 2 more RMI pros 1) It already has a mechanism for using HTTP when the the client and server are separated by a firewall. 2) In real-world situations, people are usually pretty bad about documenting protocols they write themselves; with RMI you know the protocol. This matters because, unlike RMI, protocols written from scratch are usually very limited, and later another developer will run into problems that can only be solved by either modifying the protocol (if it is documented) or scrapping it and creating a new one (expensive but happens too frequently). [ June 01, 2002: Message edited by: Reid M. Pinchback ]
Hi, Stefan Nilsson You wrote : b) You can't use the thread object as client id in lock manager, since you can't be sure that a client always gets the same thread. I don't think you are asked to identify clients. I think in the lock method what is asked is to make sure that the Thread that locks a record is the one that unlocks it. Not the client, even though it will always be the same client that creates this one Thread to lock and unlock. So the Thread Object can be used to lock and unlock with no problem at all. So I don't agree with your CONS b)
Originally posted by raphael Bereh: even though it will always be the same client that creates this one Thread to lock and unlock. So the Thread Object can be used to lock and unlock with no problem at all.
Not true. When the same client makes two seperate calls to lock and unlock, RMI doesn't guarantee to use the same thread for those two calls.
may be I did not explain myself clearly. I mean if client A creates a thread to lock, if the same thread does not unlock, the thing will not work if you are using the thread object to identify locking and unlocking thread. Of course different attempts to lock and unlock from the same client get different thread numbers.