Which choose RMI or Sockets ?

[Luis Felipe Bacca Arango]

Hi, I want to know when it is necesary to use sockets.

I had work in several projects but always the discussion show up, which choose, RMI or Sockect.


Regards,

[Joe Ess]

The Remote Method Invocation (RMI) is a Java system that can be used to easily develop distributed object-based applications. RMI, which makes extensive use of object serialization, can be expressed by the following formula:

RMI = Sockets + Object Serialization + Some Utilities

The utilities are the rmi registry and the compiler to generate stubs and skeletons.

If you are familiar with RMI, you would know that developing distributed object-based applications in RMI is much simpler than using sockets. So why bother with sockets and object serialization then?

The advantages of RMI in comparison with sockets are:

* Simplicity: RMI is much easier to work with than sockets
* No protocol design: unlike sockets, when working with RMI there is no need to worry about designing a protocol between the client and server -- a process that is error-prone.

The simplicity of RMI, however, comes at the expense of the network. There is a communication overhead involved when using RMI and that is due to the RMI registry and client stubs or proxies that make remote invocations transparent. For each RMI remote object there is a need for a proxy, which slows the performance down.

Advanced Socket Programming by Qusay H. Mahmoud

[Luis Felipe Bacca Arango]

Hi Joe, thanks a lot for your answer. It is very clear.

Thanks and Regards,

[Elliotte Rusty Harold]

When I was writing the third editon of Java Network Programming, no single chapter was more of a pain than the RMI chapter. I am very much not a fan of RMI. Details depend on what you're doing but in general I would say avoid it at all costs. RMI is broken at a very deep level, and that's become clearer and clearer with each passing year.

I think the community is slowly beginning to realize that there is something fundamentally wrong with the whole idea of technologies like RMI. Something like it is reinvented every four or five years; it's always hyped massively; and it always fails to achieve broad-scale adoption. It failed when it called RPC. It failed when it was called CORBA. It failed when it was called RMI. And it's failing now when it's called SOAP. At some point you have to realize that it's not that each and every one of these technologies designed by very smart, very experienced people was poorly written and poorly implemented. There is a fundamental problem with the whole idea of treating network services as some funky kind of object or function.

Some of the reasons RMI and similar technologies are doomed to fail were identified by Peter Deutsch in the Eight Fallacies of Distributed Computing The correct architecture for many (not all) network services was identified by Tim Berners-Lee, Roy Fielding, and others; and it's called REST. REST is not appropriate for all applications--it doesn't work for telnet, for example--but I question whether RMI/RPC-like architectures are appropriate for any.

[Luis Felipe Bacca Arango]

Hi, Mrs Harold, i really apreciate your comments.

I want to congratulate you about your book, I heard it is very good, and very illustrative.

Regards,

[Ko Ko Naing]

Originally posted by Elliotte Rusty Harold:
When I was writing the third editon of Java Network Programming, no single chapter was more of a pain than the RMI chapter. I am very much not a fan of RMI. Details depend on what you're doing but in general I would say avoid it at all costs. RMI is broken at a very deep level, and that's become clearer and clearer with each passing year.

I think the community is slowly beginning to realize that there is something fundamentally wrong with the whole idea of technologies like RMI. Something like it is reinvented every four or five years; it's always hyped massively; and it always fails to achieve broad-scale adoption. It failed when it called RPC. It failed when it was called CORBA. It failed when it was called RMI. And it's failing now when it's called SOAP. At some point you have to realize that it's not that each and every one of these technologies designed by very smart, very experienced people was poorly written and poorly implemented. There is a fundamental problem with the whole idea of treating network services as some funky kind of object or function.

Some of the reasons RMI and similar technologies are doomed to fail were identified by Peter Deutsch in the Eight Fallacies of Distributed Computing The correct architecture for many (not all) network services was identified by Tim Berners-Lee, Roy Fielding, and others; and it's called REST. REST is not appropriate for all applications--it doesn't work for telnet, for example--but I question whether RMI/RPC-like architectures are appropriate for any.

So do you suggest people not to solely learn RMI? I feel the explanation of RMI topic in your second edition is really great and you are still covering it in the third editon... And the great success story of EJB is based on RMI, isn't it? So industries who use EJB cannot still run away from RMI, I guess...

Thanks...

[Elliotte Rusty Harold]

I still cover RMI in the third edition, and I've updated the discussion to include newer features like stubless/skeletonless code. However, unless you're faced with an existing system or framework that depends on RMI, I really don't recommend that anybody use it. I really can't think of any case where I'd recommend someone starting from scratch on a new project should use RMI. It's simply to baroque, too complex, and too hard to get right. It makes the simple things complex, and the hard things impossible.

[Catalin Merfu]

Last year I had to pick the best Java networking technology for a project.
I evaluated Sockets, RMI, EJBs and HTTP (Tomcat). RMI was the fastest, about twice the speed of EJBs.

The major problem with RMI was the number of sockets wasted, 4 times more than for the other techs. This may be because:
- client connects to server;
- client connects to registry;
- server connects to registry;
- client connects to http server.

So this would make the RMI implementation I tested unusable for servers that must service hundreds of clients at the same time.

Another major problem were client callbacks. It seems the server needs to connect back to the client, the client acting like a server. But sometimes the IP address of the client machine is not accesible from the Internet, for example is the client is behind a firewall.

These RMI issues may have been resolved in Java 5.