Web服務vs EJB vs RMI，優點和缺點？

Question

如果所有工作都在那裏完成，我的Web服務器會很快超載。我將站在第二臺服務器後面來處理數據。

EJB比RMI有什麼優勢，反之亦然？

Web服務（SOAP，REST）如何？

Answer 1

EJB構建在RMI之上。兩者都意味着Java客戶端和bean。如果您的客戶需要使用其他語言（例如，.NET，PHP等）編寫，請使用Web服務或其他可以說與平臺無關的有線協議的其他語言，例如HTTP或XML over HTTP或SOAP。

如果您選擇RMI，則不需要Java EE EJB應用程序服務器。您必須保持客戶端和服務器JVM同步;不升級服務器就無法升級客戶端。您必須編寫EJB應用服務器爲您提供的所有服務（例如，連接池，命名和目錄服務，池化，請求排隊，事務處理等）。

當您考慮它時，RMI是相當低的水平。爲什麼你會一路回到CORBA？

更好的選擇是EJB 3.0與Spring。這取決於你是否喜歡POJO開發，除了ORM和JPA之外還需要關係型技術的選擇。您可以支付Java EE應用服務器（例如WebLogic，WebSphere）或使用開放源代碼（JBOSS，Glassfish和OpenEJB和ActiveMQ），或者您可以堅持Spring並部署在Tomcat，Jetty，Resin上或任何其他的servlet/JSP引擎。持久性（Hibernate的，iBatis的，JDBC，JDO，JPA的TopLink），遠程（HTTP，黑森州，粗麻布，RMI，SOAP Web服務）等

：

春天由是技術無關提供了很多的選擇

EJB 3.0是許多供應商的規範;春天只能從Spring Source獲得。我會推薦Spring。這是非常堅實的，有很多的牽引力，不會去任何地方。它會讓所有選項都打開。

Web服務是在理論上很好，但也有一些需要注意的陷阱：

1. 延遲。福勒的第一個分佈式對象定律：「不要！」由許多細粒度的分佈式SOAP服務組成的體系結構將如蜜糖般優雅，美麗和緩慢。分發前仔細考慮。
2. 從XML到對象和回程的編組會消耗CPU週期，除了允許您的客戶說出平臺無關的協議外，這些CPU週期不提供任何業務價值。
3. SOAP是一種每天都變得更加臃腫和複雜的標準，但它有很多工具支持。供應商喜歡它，因爲它有助於推動ESB的銷售。 REST很簡單，但不太瞭解。它不受工具支持。

Spring的web服務模塊非常好，但要小心選擇這種方式部署。用POJO服務接口編寫。這些可以讓你得到你想要的概念隔離，推遲到最後一刻的部署選擇，並讓你改變主意，如果第一個想法表現不佳。

Answer 2

EJB和RMI之間，EJB肯定會更好 - 它的一切RMI擁有和更多通過容器（對象池，事務管理等）

EJB和Web服務之間，Web服務將給予如果您希望將來能夠從非Java應用程序中調用它們，那麼您便於攜帶。 EJB再次爲您提供事務管理和池化等功能，您可能無法通過Web服務「開箱即用」。就個人而言，如果我這樣做了，我可能會使用EJB或類似的遠程對象框架（Spring Remoting也浮現在腦海中）。如果您需要從非Java應用程序調用對象的功能，則可以根據需要隨時使用簡單的Web服務代理將EJB對準。

Answer 3

回覆：Web服務（SOAP，REST） 如果您的後端服務器不會公開暴露，那麼使用獨立於平臺的Web服務接口（如SOAP/REST）沒有任何好處。
事實上，你會因爲在遠程調用中包裝數據的XML標籤所添加的所有開銷而招致懲罰，更不用說從編組和將XML解組到Java對象所帶來的衝擊。
儘管任何分佈式調用都需要某種級別的序列化 - 甚至是RMI/EJB，但是在序列化爲人類可讀的XML時價格更高。

您可能不需要在java中編寫遠程調用，您可以使用普通的apache httpd實例爲您的服務提供服務，該實例配置爲使用mod_jk或mod_proxy跨多個java服務器進行負載平衡。
這些模塊可用於跨servlet容器（如tomcat/jetty）或ejb容器（如jboss/glassfish）進行負載均衡。