什么是Enterprise Java Bean？

Question

在Tomcat FAQ上，它說：“Tomcat不是EJB服務器.Tomcat不是一個完整的J2EE服務器。”

但如果我：

• 使用Spring提供應用程序上下文
• 用JPA注釋注釋我的實體（並使用Hibernate作為JPA提供者）
• 將C3P0配置為連接池數據源
• 用@Transactional注釋我的服務方法（並使用Atomikos作為JTA提供者）
• 使用JAXB進行編組和解組
• 並可能添加我自己的JNDI功能

那么我不是有效擁有Java EE應用服務器嗎？ 然后不是我的bean EJB？ 還是有其他一些定義特征？

什么是符合Java EE的應用服務器為您提供的，您不能輕易/輕松地從Tomcat獲取某些第三方子系統？

Answer 1

EJB是符合javax.ejb API的JavaEE組件。

JavaEE是API的集合，您不需要使用它們。

Tomcat是一個“部分”JavaEE服務器，因為它只實現了一些JavaEE API，例如Servlets和JNDI。 它沒有實現例如EJB和JMS，因此它不是完整的JavaEE實現。

如果您添加了一些額外的部分（例如OpenEJB，HornetQ），您將添加缺少的部分，並最終得到一個完整的JavaEE服務器。 但開箱即用，Tomcat不是那樣，並不會嘗試成為。

Answer 2

但是如果我添加（...）那么我不是有效地擁有Java EE應用服務器嗎？ 然后不是我的bean EJB？ 還是有其他一些定義特征？

不，您沒有Java EE應用服務器，完整的Java EE應用服務器不僅僅是Tomcat + Spring +獨立的事務管理器。 即使您添加了JMS提供程序和EJB容器，您仍然沒有Java EE服務器。 所有部分之間的粘合劑都是IMO的重要部分，並且是Java EE容器的附加值的一部分。

關於EJB，EJB規范不僅僅是JPA，還有Session Beans和Message Driven Beans（實際上，我並不認為JPA實體是EJB，即使JPA是Java EE 5中EJB 3.0規范的一部分，因為歷史原因 - 在Java EE 6中不再適用，JPA 2.0和EJB 3.1是單獨的規范。 我還要提一下，用@Transactional注釋的Spring bean不等同於Session Bean。 Java EE容器可以使用會話Bean執行更多操作（請參見下文）。 你可能不需要它們但是，它們並不完全等同。

最后，Java EE容器實現了一個標准，Spring容器沒有，它是專有的。

什么是符合Java EE的應用服務器為您提供的，您不能輕易/輕松地從Tomcat獲取某些第三方子系統？

正如我所說，我認為“膠水”是附加值的一部分，並且對整體的穩健性有很大貢獻。 然后，ewernli的答案強調了很難實現的目標。 我只想補充一下：

• 群集和故障轉移 （實現容錯）
• 行政設施

是的，一個好的Java EE服務器將做很好的事情來提高容錯能力（連接池的集群，JNDI樹，JMS目的地，冪等bean的自動重試，智能EJB客戶端，事務恢復，服務遷移等）。 對於“關鍵任務”應用 - 絕大多數都不是 - 這很重要。 在這種情況下，Servlet API之上的庫是IMO而不是替代品。

Answer 3

1）您將JPA實體與EJB混淆。 雖然JPA屬於EJB3規范，但它始終是一種獨立的技術。

2）EJB是：無狀態bean，有狀態bean和消息驅動bean。 雖然使用彈簧可以輕松實現這些功能中的每一個，但彈簧不會使用此術語。 在Spring中，你在EJB中沒有POJO +“魔法”，在Spring中它是POJO +你自己的配置（有時也感覺像魔術一樣）。 主要區別在於spring做得更多而應用程序服務器做得更少，這就是為什么spring應用程序對tomcat感到滿意而ejb3應用程序需要“真正的”應用程序服務器。

在我看來，90％的應用程序可以使用spring + tomcat進行部署，很少需要ejb3。

Answer 4

實際上，如果你付出足夠的努力，你幾乎可以將Tomcat / Spring變成一個成熟的重量級應用服務器:)你甚至可以嵌入一個可移植的EJB3容器......

什么是符合Java EE的應用服務器為您提供的，您不能輕易/輕松地從Tomcat獲取某些第三方子系統？

第三方模塊仍然有一些難以獲得的功能：

• 有狀態會話bean（SFSB）
• 擴展持久化上下文
• 應用程序客戶端容器/ java web start
• 根據應用程序進行群集。 服務器
• CORBA互操作性
• JCA整合〜
• 遠程〜
• 容器管理的事務〜
• 分布式事務的體面管理（例如恢復啟發式tx）

帶有〜的條目也得到Spring的支持，但不是那么簡單，至少據我所知。

這個答案中有一些細節： EJB vs Spring

Answer 5

在嚴格定義什么是EJB和不是EJB的情況之外，你要向Tomcat添加很多東西。 即使你擁有的是EJB服務器，它也不再是純粹的Tomcat。

FAQ是正確的：Tomcat不是EJB服務器。 但是，如果你有足夠的額外庫和代碼，它可能是那個或許多其他的東西。

Answer 6

EJB實現將是一個編寫並打包的bean，可以在任何兼容的EJB服務器上運行。 如果您執行您描述的操作，它可能會起作用，但它不能移植到其他供應商的應用程序服務器。

因此，EJB是一種符合特定規范的標准，因此是可移植的。

在實踐中，許多EJB不完全兼容或應用服務器中立。 但是，主要是它們，因此如果您更改應用程序服務器供應商而不是嘗試將您描述的體系結構移動到GlassFish，JBoss或Weblogic服務器，那么小的不兼容性將更容易修復。

編輯：為了回應您的評論，您不會通過XML對EJB進行適當的注釋和/或配置，以便以符合EJB的方式訪問它的代碼能夠在不進行更改的情況下使用它。

您的評論有兩個角度。 一個是你在JBoss或其他任何一個而不是Tomcat上部署的功能是什么？ 如果你帶來了你所依賴的所有框架，可能沒什么。 但是，如果您想將代碼移動到Weblogic，例如，要使用它的某些功能，那么您的代碼需要進行一些可能的重大更改才能跟上。

我不是說你不能通過其他方式復制所有EJB功能（當然是你關心的子集），只是它不是規范，因此不是獨立於實現的。

Answer 7

那么我不是有效擁有Java EE應用服務器嗎？ 然后不是我的bean EJB？ 還是有其他一些定義特征？

快速回答EJB實際上必須遵循Java EE規范。 Tomcat是Java EE容器而不是應用服務器。

什么是符合Java EE的應用服務器為您提供的，您不能輕易/輕松地從Tomcat獲取某些第三方子系統？

快速回答你的第二個問題。 在你的情況下，很可能沒有。

EJB往往是非常重的對象，人們最終使用它們解決問題，因為它們本質上是矯枉過正的。 創建像Spring這樣的框架來解決這些問題而不使用EJB。 我認為引入Spring的第一本書甚至被稱為“沒有EJB的J2EE開發”。