在純Java環境中，Web服務和RMI有哪些優缺點？

Question

在開發分佈式應用程序時，所有由同一家公司用Java編寫的應用程序是否會選擇Web服務還是RMI？在性能，鬆散耦合，易用性等方面有什麼優點和缺點？有人會選擇WS嗎？你能用RMI構建一個面向服務的體系結構嗎？

Answer 1

我會去想想這樣說：

你要運行相互獨立下的服務，這些服務可以通過非Java應用程序在未來的某個時候訪問？然後去尋找網絡服務。

你只是想在幾臺服務器上傳播應用程序的部分內容（介意單數）嗎？然後去RMI，你不必離開Java的宇宙，讓所有的東西緊密結合在一起工作。

Answer 2

我會選擇WS。

• WS/RMI不太可能成爲您的瓶頸。
• 爲什麼要關閉未來其他可能的技術的大門？
• 如果客戶端/服務器上的類版本不同步，則RMI可能會有問題。

而且......我很可能會選擇REST服務。

Answer 3

我的選擇是：

標準Java序列化 - 優點：恕我直言提供最佳性能，易於執行（我使用Spring來暴露本地接口遠程之一）;缺點：序列化不不同的JVM版本

之間工作

二進制序列（從碼頭例如粗麻布） - 優點：相同的性能與Java序列化和不同的JVM版本

之間工作

WS：僅當有一個需要不同平臺之間的互操作性java + .net，否則就是太重量級了。

Answer 4

RMI是一種快速發展的交通工具，但我建議不要在生產環境中使用它。序列化兼容性問題會讓事情變得尷尬，您必須非常仔細地協調您的部署。

WebServices效率不高，是的，但只是通過它的硬件。或者，使用普通的輕量級XML-over-HTTP，而不是全脂肪SOAP/WSDL。

Answer 5

如果你不需要它（與非Java互操作），而你可能不是，RMI會更好;代碼少，配置少，帶寬開銷少。

一個選項，如果你害怕你會需要它是使用EJB3;它使用RMI，非常易於安裝和部署，還可以讓您在需要時輕鬆將您的呼叫轉換爲Web服務。

無論你做什麼，做不是創造你自己的東西;堅持一個標準。