企业 Java Bean 到底是什么？答案

【问题标题】：What is an Enterprise Java Bean really?企业 Java Bean 到底是什么？
【发布时间】：2011-02-28 21:09:32
【问题描述】：

在 Tomcat 常见问题解答中它说：“Tomcat 不是 EJB 服务器。Tomcat 不是完整的 J2EE 服务器。”

但如果我：

使用 Spring 提供应用程序上下文
用 JPA 注释我的实体注释（并使用 Hibernate 作为 JPA 提供商）
将C3P0配置为连接池数据来源
注释我的服务方法使用 @Transactional （并使用 Atomikos 作为 JTA 提供者）
使用 JAXB 进行编组和解组
并可能添加我自己的 JNDI 功能

那么我不是有一个 Java EE 应用服务器吗？然后我的bean不是EJB吗？还是有其他一些定义特征？

兼容 Java EE 的应用服务器为您提供了哪些无法通过一些 3rd 方子系统轻松/轻松地从 Tomcat 获得的东西？

【问题讨论】：

附带说明，Apache Tomcat 可以用作完整 JavaEE 服务器的一部分；更具体地说是 JBoss 或 Apache Geronimo。
最近，Apache TomEE

标签： java tomcat ejb-3.0 enterprise javabeans

【解决方案1】：

EJB 实现将是一个编写和打包以在任何兼容的 EJB 服务器上运行的 bean。如果您按照您的描述进行操作，它可能会起作用，但它不能移植到其他供应商的应用程序服务器上。

因此，EJB 是一种遵循特定规范的标准，因此具有可移植性。

在实践中，许多 EJB 并不完全兼容或应用服务器中立。但是，它们大体上是这样，因此如果您更改应用服务器供应商，那么修复小的不兼容性要比尝试将您描述的架构迁移到 GlassFish、JBoss 或 Weblogic 服务器更容易。

编辑：在回应您的评论时，您不会有一个通过 XML 适当注释和/或配置的 EJB，这样以符合 EJB 的方式访问它的代码无需更改即可使用它。

您的评论有两个角度。一个是在 JBoss 或其他任何一个而不是 Tomcat 上部署时，您会失去哪些功能？如果你带来了你所依赖的所有框架，可能什么都没有。但是，如果您想将代码移至 Weblogic，例如，以使用它的某些功能，那么您的代码可能需要进行一些重大更改才能跟上。

我并不是说您不能通过其他方式复制所有 EJB 功能（当然是您关心的子集），只是它不是规范，因此不是独立于实现的。

【讨论】：

为什么我描述的架构不能移植到真正的 EJB 应用服务器上？它不会运行吗？是否需要重新配置或重写？

【解决方案2】：

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

JavaEE 是 API 的集合，您不需要全部使用。

Tomcat 是一个“部分”JavaEE 服务器，因为它只实现了一些 JavaEE API，例如 Servlet 和 JNDI。它没有实现例如EJB 和 JMS，因此它不是完整的 JavaEE 实现。

如果您添加了一些额外的零碎部分（例如 OpenEJB、HornetQ），您将添加缺少的部分，最终您将获得一个完整的 JavaEE 服务器。但是开箱即用的 Tomcat 不是那样的，也不会尝试那样做。

【讨论】：

所以基本上，我的注释 POJO 具有 EJB 的大部分功能（我关心的所有功能），但是因为 Tomcat 没有实现 javax.ejb（我的 bean 不使用那些API）它们不是正式的 EJB。假设我的架构可以在应用服务器中正常运行，我是否正确？
@HDave：EJB 不仅仅是 JPA 注释。它们涵盖了事务、安全性和生命周期等内容，它们补充和扩展 JPA 注释。
当然——我所说的注释是指 JPA + 事务 + 安全性。我假设这些都将在 JEE 应用服务器中工作。对吗？

【解决方案3】：

1) 您将 JPA 实体与 EJB 混淆了。虽然 JPA 属于 EJB3 规范，但它始终被认为是一种独立的技术。

2) EJB 是：无状态 bean、有状态 bean 和消息驱动 bean。虽然这些功能中的每一个都可以使用 spring 轻松实现，但 spring 只是不使用这个术语。在 Spring 中，您不像在 EJB 中那样拥有 POJO +“魔法”，在 Spring 中它是 POJO +您自己的配置（有时也感觉像魔法）。主要区别在于 spring 做的更多而应用程序服务器做的更少，这就是为什么 spring 应用程序对 tomcat 感到满意而 ejb3 应用程序需要一个“真正的”应用程序服务器。

在我看来，90%的应用都可以使用spring+tomcat部署，很少需要ejb3。

【讨论】：

【解决方案4】：

那么我不是有效地拥有 Java EE 应用服务器？然后不是我的 bean EJB 的？或者有没有其他的定义特征？

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

什么是符合 Java EE 的应用程序服务器给你你不能轻松/轻松地从 Tomcat 获取一些第 3 方子系统？

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

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

【讨论】：

首先，Tomcat 不是 Java EE 容器。其次，EJBs = heavy 对于 J2EE 1.4 来说是正确的，但 NOT 适用于 EJB3。我们已经不是 2004 年了……
对我来说，如果您的容器不支持 EJB，那么它就不是 Java EE 容器。然而，根据 Wikipedia，Tomcat 是一个应用服务器（我相信这在技术上是正确的，虽然令人困惑）：en.wikipedia.org/wiki/Application_server

【解决方案5】：

除了对什么是和不是 EJB 的严格定义之外，您还向 Tomcat 添加了很多东西。即使您拥有的是 EJB 服务器，它也不再是普通的 Tomcat。

FAQ 是正确的：Tomcat 不是 EJB 服务器。但是，如果您堆积了足够多的额外库和代码，则可能是这样或许多其他事情。

【讨论】：

一个罕见而开明的答案。更多的人应该有这样的看法。一旦您有效地构建了自己的类似 JavaEE 的堆栈，您就不能真正说“只是 Tomcat”。

【解决方案6】：

确实，如果你付出足够的努力，你几乎可以将 Tomcat/Spring 变成一个成熟的重量级应用服务器 :) 你甚至可以嵌入一个可移植的 EJB3 容器......

什么是符合 Java EE 的应用程序服务器给你你不能轻松/轻松地从 Tomcat 获取一些第 3 方子系统？

仍有一些功能难以通过 3rd 方模块获得：

有状态会话 bean (SFSB)
扩展的持久性上下文
应用程序客户端容器/java web start
集群取决于应用程序。服务器
CORBA 互操作性
JCA 集成 ~
远程处理 ~
容器管理事务 ~
分布式事务的体面管理（例如恢复启发式 tx）

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

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

【讨论】：

+1 好答案。但我也会添加故障转移和恢复，你不会在 Tomcat 上获得这些，这是成熟的中间件规范和实现的重要组成部分。
没错。我考虑了集群的那一部分，即使它不完全相同。此外，JEE 规范的编写是为了支持集群，但它们并不强制要求它是合规的。但我完全同意这是选择应用程序的一个重要方面。服务器。

【解决方案7】：

但是如果我添加 (...) 那么我实际上不是拥有一个 Java EE 应用程序服务器吗？然后我的bean不是EJB吗？还是有其他一些定义特征？

不，您没有 Java EE 应用程序服务器，一个成熟的 Java EE 应用程序服务器不仅仅是 Tomcat + Spring + 一个独立的事务管理器。即使您添加了 JMS 提供者和 EJB 容器，您仍然不会拥有 Java EE 服务器。所有部分之间的粘合剂在 IMO 中很重要，并且是 Java EE 容器附加值的一部分。

关于 EJB，EJB 规范远不止 JPA，还详细说明了会话 Bean 和消息驱动 Bean（实际上，即使 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 的应用服务器为您提供了哪些您无法通过一些 3rd 方子系统轻松/轻松地从 Tomcat 获得的东西？

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

集群和故障转移（实现容错）
管理设施

是的，一个好的 Java EE 服务器会做一些非常巧妙的事情来提高容错性（连接池的集群、JNDI 树、JMS 目标、使用幂等 bean 自动重试、智能 EJB 客户端、事务恢复、服务迁移等） .对于“关键任务”应用程序——绝大多数不是——这很重要。在这种情况下，基于 Servlet API 的库不是 IMO 的替代品。

【讨论】：