Java遠程方法調用是編程過程當中比較常見的問題，列舉一下主要包括以下幾類：
一、Java RMI (Remote Method Invocation)
二、EJB遠程接口調用
三、WebService，如jax-ws axis xfire cfx
四、Hessian以及Spring HttpInvoker
五、直接動態請求返回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數據，數據結構不夠靈活，安全性也不足。不過實現起來簡單，和業務代碼一塊兒就順帶寫完了，幾乎都不須要客戶端的概念，只要請求數據足夠簡單、安全措施作好也可使用。