This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
HI Ranchers, Lets discuss this hot topic once again. I have used RMI and would recomend the same, if i have to make the choiuce again in future.Why, because : 1)Easier to implement and debug. 2)No protocol needs to be developed for communication between two communicating parties, we just use a predefined protocol for sending and receiving request responses. 3)No thread management is required as this is being managed by RMI internally. 4)Better control on exceptions debugging & management. 5)Easier Extensibilty as clear seperation between client and server. What can be pros of using Sockets over RMI? Kindly comment. VikasSood
A client could be written in a language other than Java
The database could be written in a language other than Java
More explicit control over what is sent over the network could result in less network traffic, which could result in a more responsive system.
One less application to run on the server (no RMI Registry)
Easier communications through firewalls (yes, RMI can be used through a firewall, but it requires more work, and more understanding by the firewall maintainer)
Less chance of someone accidently disabling your server (with RMI someone could do a Naming.rebind() with the same name as your server - your server is lost. With sockets, once you have bound to the port, no-one else can bind to it).
Anyone have any others? By the way, I know the first two would be difficult, since the requirements state that we have to use serialized objects. However it is not impossible (in fact, with the well written specifications for Java, it is not all that difficult). Regards, Andrew
Other pros for sockets might include: Object serialization over sockets uses less levels of abstraction/indirection than RMI, and a well written, well-tuned socket solution can therefore out-perform an RMI solution when the server application scales to handle large databases or large numbers of clients. Using something like a Command pattern for the client-server communication protocol trivialises the objection that you have to develop a whole new protocol for socket communication. A deployer does not need to understand RMI policy files, security managers, RMI registries (and/or JNDI servers) to deploy the server application. Depending upon implementation details, it is possible to provide new server features with a Command pattern, WITHOUT recompliling the server code. This assumes server operations are embedded as executable code within the Command objects and is open to the criticism that this provides potential for malicious clients to embed arbitrary code that could cause a denial of service or worse, but properly handled security issues (well beyond the scope of the exam) could answer this problem. Not all people, contrary to popular opinion, find RMI an easier distributed programming paradigm than plain sockets. Just because a technology is older and less feature-rich, this doesn't mean it still can't be a suitable solution for a particular class of problems.
Always proofread carefully to see if you any words out.
I do agree with Damian Ryan to certain extent. Socket based communication is always faster compared to RMI. But code maintenance is more in future development. Protocols may need to be modified, which is another risky area. Socket programming needs experienced developers. But sockets can be tuned according to the situation. Comming to RMI, better use the existing architecture for distributed platform, else re-invent the whole wheel. So one may think of re developing the JVM, as IBM JVM is faster than SUN JVM. can we re-develop our JVM for this assignemnt, compatible to SUN's JVM? This is what actual code-reusability says. In the assignement problem, SUN clearly says, use existing classes in preference to your custom solutions. So they prefer pre built work. This is just a consideration. I use RMI in my assignment. Reasons are: 1. It is a proven architecture for distributed communication. 2. No need to put efforts in developing protocol for the solution. 3. No need to put more effort on writing multi threaded server. 4. Easy to make updations, and future enhancements. 5. Greatest advantage of RMI is design to interface, rather than abstraction. Ofcourse there are some drawbacks too like: 1. RMI server response is bit slow. 2. RMI uses java object serialization protocol, which inturn uses reflection mechanism, a very slower one. 3. Debugging an RMI program is difficult. But I strongly believe Vikas Sood is milking JavaRanch cow to the great extent for his assignment. [ June 15, 2003: Message edited by: S. Ganapathy ]
Hi , These are the reasons I added in my assignment. I. RMI has implemented the required multi-threaded server for you in an efficient way. Also it was throughly tested. II. RMI provides the frame work and some basic services for developing remote applications. Socket is a basic software component. So the programmer has to take care for all the services. III. It is easy to implement. IV. The application can talk to Other Distributed systems like CORBA and EJB in future using RMI/IIOP. V. RMI hides the wire protocols. VI. RMI allows both state and behavior to be passed over the network