應用程序服務器（帶有EJB）是Java EE客戶端/服務器通信的唯一方法嗎？

Question

想象一下，一個Java客戶端/服務器ERP應用程序可同時服務100個並發用戶，包括Web和Swing客戶端。 對於持久性，我們可以使用Persistence API和Hibernate。 但是，當涉及到客戶端/服務器通信時，我們是否真的可以替代使用帶有EJB的AS來降低遠程通信的編程成本？

似乎僅是為了進行遠程處理而拋出EJB和應用程序服務器是一個非常重量級的解決方案。 還有使用RMI的標准方法，但是如今誰想要自己編寫所有代碼...

我知道，除了遠程處理部分之外，您還將通過AS免費獲得許多功能。 而且，也許這是要走的路。 但是，對於企業應用程序進行客戶端/服務器通信，真的有AS的其他替代方法（低編程成本）嗎？

Answer 1

就我個人而言，我認為Seam是解決我沒有的問題的最終解決方案，但除此之外，還有很多選擇，大多數情況下使用Spring：

• RMI ;
• Hessian （基於二進制HTTP的協議）；
• HTTP調用程序 （通過HTTP進行Java序列化）；
• Web服務 ; 要么
• 甚至JMS 。

基於HTTP的遠程處理方法的優點在於，它們可以輕松地插入Spring的安全模型中。 另外，您還可以訪問攔截器之類的東西。

Answer 2

您可以使用輕量級遠程處理框架。 在本節中，Spring有許多選項。

如果您兩個都問我一個字，我會建議兩個。 接縫或彈簧。 我本人喜歡Seam，但是對於輕量級遠程處理， Spring提供了更多可行的解決方案和支持。 同樣，如果您的AS是JBoss，請考慮一下Seam 。

Answer 3

應用服務器是一個非常重量級的解決方案。 根據您的要求，我將嘗試確保您可以在簡單的servlet容器（例如Tomcat）上運行。 我發現使用Spring遠程處理而不是完整的EJB 進行遠程處理要容易得多。 彈簧遠程處理提供了對所使用的實際遠程處理技術的抽象。 粗麻布作為lightweigth協議享有很高的聲譽。

擁有某種服務器框架（AS或Servlet容器）是一件好事，因為您無需考慮所有低級問題（連接建立，線程處理...）。