純粹的轉載，我也只用過CXF與HttpInvoker和hessian
來源於：http://blog.csdn.net/noliyo/article/details/9474413
Java遠程方法調用是編程過程中比較常見的問題，列舉一下主要包括如下幾類：
1、Java RMI (Remote Method Invocation)
2、EJB遠程接口調用
3、WebService，如jax-ws axis xfire cfx
4、Hessian以及Spring HttpInvoker
5、直接動態請求返回JSON數據
本文從配置復雜性、編碼難度、執行效率、跨語言性、兼容性、安全性、協議類型、是否綁定特定框架等方面做一個簡單的比較分析。
JavaRMI是jdk中內嵌的一個最底層的解決方案，它應用起來最輕量級，也最簡單，它不需要任何的web服務器，直接在代碼中綁定IP地址和相應的端口，如果是非常簡單的小微應用比較適合，因為最底層其效率應該不錯，接下來的幾種調用方式其他有一些都是以這個為基礎擴展而來的。其缺點也很明顯，如果業務非常多而復雜、接口調用非常頻繁需要分布在多台服務器，那么其編碼很不優雅、也難於實現分布式等，且所有的東西都集中在代碼里了，可讀性可維護性等都不太理想，不具備跨語言的調用。
EJB遠程接口調用，其最本質的底層仍然是JavaRMI，通過JNDI來調用服務。不過EJB遠程接口調用的優點是，可以非常輕松的實現分布式，客戶端編碼有些版本比較復雜，但多數代碼一般可以借助IDE自動完成，EJB3.0以后的版本編碼和配置起來也更簡單。缺點是，EJB是個重量級的框架，需要EJB容器的支撐，很多web服務器都不具備這個功能，如resin、tomcat等，如果業務代碼不是使用EJB的話，遠程調用自然不適用。目前互聯網開發中EJB已經非常少見了，可能是spring的崛起以及非常有名的那本書《Expert One-on-One J2EE Development without EJB》，有中文版。
WebService是很常見的遠程調用方法，其最大的優勢就是跨平台語言，無論客戶端是Java還是.NET都能輕松的調用。它采用SOAP(Simple Object Access Protocol)協議來封裝序列化的消息，實際上是形成一個xml文件，可以通過http進行網絡傳輸。WebService的客戶端調用其實是使用生成文件的方式，只要知道發布接口的URL即可，而不需要額外傳遞jar包或者class文件。常見的WebService實現有jax-ws2.0、axis、xfire以及cfx，其中jax-ws2.0是jdk中封裝好的，有一定的靈活性，但是這種把框架內嵌進入JVM其實對其可控性大大降低；axis有1.0和2.0兩個版本，這個不是太了解；xfire和cfx其實是一個源頭，xfire在07年停止開發，和另外一個框架合並形成了cfx，是一個比較受歡迎的WebService實現。
Hessian是另外一個非常常用的遠程調用方案，它基於Binary-RPC協議，這個協議把請求和響應的數據統統使用標准的二進制格式進行封裝，所以它也具有跨語言平台傳輸數據的能力，而且它有自己的高效的序列化和反序列化機制。不過hessian在版本控制中經常出現互不兼容的情況，服務器端和客戶端通常要保持一致的版本，否則會出現莫名其妙的問題，還有常見的各種錯誤，如使用nginx反向代理后返回411錯誤等。spring對hessian提供了很好的支持，通常配合使用；同時spring還有一套自己的遠程調用方法HttpInvoker。如果你使用過Hessian和HttpInvoker的話，就會發現它倆的配置幾乎一模一樣，包括接口名稱、類名、字段名、調用和發布代碼。。。而且不能同時使用，會相互產生沖突。它們都是通過servlet進行請求處理，需要servlet容器支持，效率不錯。
直接動態請求返回JSON數據，是一個直觀上的方式，嚴格來說不屬於遠程方法的調用。這種方式就是通過一個servlet請求直接由容器返回封裝好的JSON數據，數據結構不夠靈活，安全性也不足。不過實現起來簡單，和業務代碼一起就順帶寫完了，幾乎都不需要客戶端的概念，只要請求數據足夠簡單、安全措施做好也可以使用。