Java：RMI與Web服務

Question

我需要創建一個由多個客戶端組成的分布式應用程序，這些客戶端將文件（以及有關文件的信息）發送到一台服務器，同時查詢該服

客戶端必須從公司內部訪問該Web服務器以發送文件。 但是，偶爾某些特定查詢必須在公司外部運行。

我認為，根據我所知，RMI是一種更快（操作性能）的方式來連接桌面客戶端與索引引擎和存儲引擎。 我相信制作一個為搜索引擎提供訪問層的Web服務也是一個很好的決定，因為它將在公司網絡之外運行。

你怎么看待這件事？ 是一個好方法還是你必須考慮一些替代方案。

先感謝您。

Answer 1

RMI可以通過HTTP進行隧道傳輸（參見此處 ），因此不要讓這會影響您的決策。

如果兩端都能說RMI，那么RMI可能就是你應該使用的; 它比Web服務更容易上班。

Answer 2

這里要小心，我最近開發了一個類似的解決方案，發現套接字是傳輸文件最有效和最常用的方法，而RMI適用於簡單的方法調用（如查詢）。 我也很難設置RMI，配置有時會讓人感到困惑，而且關於這個主題的文檔也不多。

我當然相信RMI會為您提供比Web服務更好的性能; 但是，對於未來的需求，Web服務可能更具可維護性和靈活性。

Answer 3

是什么讓你認為RMI更快？ 根據我的經驗，它可能很慢，難以配置，難以保護並且通常難以使​​用。

由於Web服務通常只是基於HTTP的XML，因此您通常可以構建一個可以更好地擴展的解決方案。

Answer 4

如果你想用服務支持的API不能很好地映射到HTTP，我可能會選擇RMI（但要小心不必要的往返。）

如果它確實很好地映射到HTTP，我會選擇使用REST，它本質上是實現API作為操作的HTTP Servlets。 如果大多數流量是上傳/下載您提到的文件以及一些API調用，那么這可能是最佳選擇。

順便說一下，你的RMI比網絡服務更快的經驗與我的相符。 （結果兩者都可以以較慢的性能實現，主要是在設計不佳的API中進行往返。）

Answer 5

無論如何，它永遠不會結束辯論。 這是我的拙見：

• Web服務確實允許松散耦合的體系結構。 使用RMI，即使存在最小的更改，也必須編譯所有內容（因為類序列UUID等等）。
• WS允許與其他企業組件（ESB，SSO，身份管理，負載平衡，安全過濾器，安全證書）更容易共存，因為HTTP是底層網絡協議。
• RMI（和EJB）中的反射似乎比HTTP協議本身更昂貴。

如果您認為EJB更適合應用程序服務器環境，並且根據您的文章更容易與WS和CORBA進行比較，（EJB支持事務管理，bean管理; WS具有WS +擴展（安全性，事務））：

• 根據文章，EJB比WS慢： 遠程EJB比7.1中的WebService慢3倍
• 在編譯/構建EJB時，我們必須使用完全相同版本的應用程序服務器，包括開發和生產中的補丁，以避免可疑的生產運行時錯誤（這看起來很簡單 - 生產（數據中心）團隊並不總是說他們有哪個補丁，當我們為應用程序修復時，我們總是要重新詢問服務器的確切版本。
• 部分修復應用程序並不容易，如果由於小修復而重建EJB，則必須重建客戶端jar，因此使用客戶端jar的應用程序需要重新部署。

（根據我的經驗，這些都是問題，也許其他人更幸運）

我會得出結論，WebServices更靈活，使用更少的反射，並且如果仔細設計，希望更快。 如果在MVC控制器中使用RESTful作為結果，ESB可以幫助提供轉換（更少的代碼，只是轉換）和安全注入直接到HTTP頭（例如ivheader，ivgroup - 如果使用ibm web seal，Tivoli訪問管理器）。 只有在使用WS作為斷言與XML一起使用時才可以使用SAML XACML。 因此，對於分布式和錯位的企業應用程序，由於上述原因，WS更加靈活。

你提到的文章說WS沒有交易而只有提案。 這篇文章錯了或太舊了。 請參閱OASIS WSAT 1.0和WSAT 2.0 。 Microsoft，JBoss，Oracle和其他一些人在其應用服務器中開箱即用地支持技術。 Apache Metro似乎支持它很好（請驗證）。

Answer 6

RMI基本上適用於小型應用程序。 是的，它更快，但隨着時間的推移，您會覺得為了在流量增加時對應用程序進行更多增強，webservice比RMI更易於維護，如果您選擇REStFull webservice，那將是最佳選擇。

謝謝