Rmi和Socket比较

RMI技术比较socket的网络编程主要有以下几个方面：
第一、RMI是面向对象的，而后者不是。
第二、RMI是与语言相绑定的。比如当你使用Java RMI技术的时候，客户端与服务器端都必须使用Java开发。而socket的网络编程是使用独立于开发语言的，甚至独立于平台。基于socket的网络编程，客户端与服务器端可以使用不同开发语言和不同的平台。
第三、从网络协议栈的观点来看，RMI与socket的网络编程处于不同层次上。基于socket的网络编程位于TCP协议之上，而RMI在TCP协议之上，又定义了自己的应用协议，其传输层采用的是Java远程方法协议(JRMP)。可见，在网络协议栈上，基于RMI的应用位置更高一些，这也决定了，与socket的网络编程相比，RMI会丧失一些灵活性和可控性，但是好处是它带给了应用开发者更多的简洁，方便和易用。比如：如果你用的是RMI,你不需要关心消息是怎么序列化的，你只需要像本地方法调用一样，使用RMI。代价是：应用开发者无法很好地控制消息的序列化机制。
第四、这是最后一点不同，我认为也是比较重要的一点，就是两种方法的性能比较，其往往决定着你将使用那种技术来开发你的应用。
实验的结果是：RMI与TCP based socket相比，传输相同的有效数据，RMI需要占用更多的网络带宽（protocol overhead）。从这里，我们可以得出一个一般性的结论：RMI主要是用于远程方法的”调用“（RMI是多么的名符其实:)），其技术内涵强调的是 “调用”，基于此，我能想到的是：移动计算，和远程控制，当你的应用不需要在client与server之间传输大量的数据时，RMI是较好的选择，它简洁、易于开发。但是，一旦你的应用需要在client与server之间传输大量的数据，极端的，比如FTP应用，则RMI是不适合的，我们应该使用 socket。
PS: RMI的效率还是很高的，一般情况下会比Hessian更高效，比Web Service更是高效很多；当然和socket这种东东相比，当然要低效一点了，socket更底层一些啊。RMI的具体实现，依然是依赖于底层的Socket编程。