This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I would like to develop an application in a distributed computing environment. In my system, several clients have to communicate with the server simulateneously, and some network management functionality may need to be supported by my system.
Could anyone please tell me which would be the more suitable technology to be used -- RMI or Socket programming? If I have to run multithreading, RMI or socket programming which would work better?
How much of the wheel are you willing to invent? Java programmers have been thinking about this sort of thing for a long time and have come up with pretty good solutions. You really should look into them before getting out the socket "hand-tools." RMI is probably the most primitive - it is the basis for more advanced toolkits such as JMS, JINI and JavaSpaces. JMS - Java Message Service - could be exactly what you want JINI - JavaSpaces - very flexible and tolerant of network changes SOAP - web services - only if your clients need to go through firewalls with HTTP but still a possibility All of the above are designed for "simultaneous" multiple clients. Bill
I can at least do you the favour of debunking any myths that socket programming is much more efficient and much faster than RMI.
By implementing the java.io.Externalizable interface and implementing your own serialization, RMI becomes as fast as the "homegrown" solutions I have seen. Another advantage is that RMI is a more mature technology and thus more tested (and debugged).
Concerning multithreading and RMI: In modern JVMs, each invocation on an RMI server is, as far as I remember, handled in a separate thread. You don't have to create threads etc, but you will have to make your classes in the server thread-safe.
Good luck with the development!