Web Services 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引擎。

Spring通過技術不可知提供了很多選擇：持久性（Hibernate，iBatis，JDBC，JDO，JPA，TopLink），遠程處理（HTTP，Hessian，Burlap，RMI，SOAP Web服務）等。

EJB 3.0是許多供應商的規范; Spring只能來自Spring Source。

我會推薦Spring 。 它非常堅固，有很多牽引力，不會去任何地方。 它會打開您的所有選項。

Web服務在理論上很棒，但是有一些問題需要注意：

1. 潛伏。 福勒的第一個分布式對象定律：“不要！” 由許多細粒度分布式SOAP服務組成的體系結構將像糖蜜一樣優雅，美觀和緩慢。 分發之前要仔細考慮。
2. 從XML到對象和后端的編組會消耗CPU周期，除了允許客戶端使用與平台無關的協議之外，它們不提供任何業務價值。
3. SOAP是一種日常變得越來越臃腫和復雜的標准，但它有很多工具支持。 供應商喜歡它，因為它有助於推動ESB的銷售。 REST很簡單但不太清楚。 工具不支持它。

Spring的Web服務模塊非常好，但是選擇以這種方式部署時要小心。 根據POJO服務接口寫。 這些將允許您獲得所需的概念隔離，將部署選擇推遲到最后一刻，並且如果第一個想法不能很好地讓您改變主意。

Answer 2

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

在EJB和Web服務之間，如果您希望將來能夠從非Java應用程序調用它們，Web服務將為您提供更多可移植性。 EJB再次為您提供了事務管理和池化等功能，您可能無法通過Web服務“開箱即用”。

就個人而言，如果我這樣做，我可能會使用EJB或類似的遠程對象框架（也會想到spring remoting）。 如果您需要能夠從非Java應用程序調用對象，則可以根據需要隨時使用簡單的Web服務代理來使用EJB。

Answer 3

Re：Web服務（SOAP，REST）如果您的后端服務器不會公開公開，那么使用平台無關的Web服務接口（如SOAP / REST）就無法獲得任何好處。
事實上，你會因為在遠程調用中包裝數據的XML標記所增加的所有開銷而受到懲罰，更不用說你將從編組和解組XML到java對象的命中。
雖然任何分布式呼叫將需要系列化的一些水平 - 甚至RMI / EJB，但序列化到人類可讀的XML當時的價格是較大的。

您可能根本不需要在java中編寫遠程調用的代碼，您可以使用普通的apache httpd實例來處理您的服務，該實例配置為使用mod_jk或mod_proxy在多個Java服務器之間進行負載平衡。
這些模塊可以用來加載跨servlet容器如Tomcat /碼頭，或EJB容器例如JBoss / glassfish的平衡。