什么是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是Java EE 5中EJB 3.0规范的一部分，我也不会将JPA实体视为EJB）由于历史原因 - 在Java EE 6中不再适用，JPA 2.0和EJB 3.1是单独的规范）。 我还要提一下，用@Transactional注释的Spring bean不等同于Session Bean。 Java EE容器可以使用会话Bean执行更多操作（请参见下文）。你可能不需要它们，但它们并不完全等同。

最后，Java EE容器实现了一个标准，Spring容器没有，它是专有的。

  

Java EE兼容的应用服务器为您提供的服务是什么？您无法轻松/轻松地从Tomcat获取某些第三方子系统？

正如我所说，我认为“胶水”是附加价值的一部分，并且对整体的稳健性有很大贡献。然后，ewernli的answer强调了很难实现的目标。我只想补充一下：

• 群集和故障转移（实现容错）
• 行政设施

是的，一个优秀的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整合〜
• remoting~
• 容器管理的交易〜
• 分布式事务的体面管理（例如恢复启发式tx）

带有〜的条目也得到Spring的支持，但不是那么简单，至少据我所知。

此答案中的更多详细信息：EJB vs Spring

Answer 5

除了严格定义什么是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   应用服务器？然后不是我的   豆EJB？或者还有其他一些   定义特征？

快速回答EJB实际上必须遵循Java EE规范。 Tomcat是Java EE容器，而不是应用服务器。

  

符合Java EE的应用程序是什么？   服务器给你你不能   很容易/很容易从Tomcat获得   一些第三方子系统？

快速回答第二个问题。在你的情况下很可能没有。

EJB往往是非常重的对象，人们最终使用它们来解决问题，因为它们本质上是矫枉过正的。创建像Spring这样的框架来解决这些问题而不使用EJB。我认为引入Spring的第一本书甚至被称为“没有EJB的J2EE开发。”