什么是Enterprise Java Bean？
在Tomcat FAQ上，它说：“Tomcat不是EJB服务器.Tomcat不是一个完整的J2EE服务器。”
但如果我：
- 使用Spring提供应用程序上下文
- 用JPA注释注释我的实体（并使用Hibernate作为JPA提供者）
- 将C3P0配置为连接池数据源
- 用@Transactional注释我的服务方法（并使用Atomikos作为JTA提供者）
- 使用JAXB进行编组和解组
- 并可能添加我自己的JNDIfunction
那么我不是有效拥有Java EE应用服务器吗？ 然后不是我的bean EJB？ 还是有其他一些定义特征？
什么是Java EE兼容的应用服务器为您提供的，您不能轻易/轻松地从Tomcat获得某些第三方子系统？
但是如果我添加（…）那么我不是有效地拥有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而不是替代品。
EJB是符合javax.ejb API的JavaEE组件。
JavaEE是API的集合，您不需要使用它们。
Tomcat是一个“部分”JavaEE服务器，因为它只实现了一些JavaEE API，例如Servlets和JNDI。 它没有实现例如EJB和JMS，因此它不是完整的JavaEE实现。
如果您添加了一些额外的部分（例如OpenEJB，HornetQ），您将添加缺少的部分，并最终得到一个完整的JavaEE服务器。 但开箱即用，Tomcat不是那样，并不会尝试。
1）您将JPA实体与EJB混淆。 虽然JPA属于EJB3规范，但它始终是一种独立的技术。
2）EJB是：无状态bean，有状态bean和消息驱动bean。 虽然使用弹簧可以轻松实现这些function中的每一个，但弹簧不会使用此术语。 在Spring中，你没有像EJB那样的POJO +“魔法”，在Spring中它是POJO +你自己的配置（有时也感觉像魔术一样）。 主要区别在于spring做得更多而应用程序服务器做得更少，这就是为什么spring应用程序对tomcat感到满意而ejb3应用程序需要“真正的”应用程序服务器。
在我看来，90％的应用程序可以使用spring + tomcat进行部署，很少需要ejb3。
事实上，如果你付出足够的努力，你几乎可以将Tomcat / Spring变成一个成熟的重量级应用服务器:)你甚至可以嵌入一个可移植的EJB3容器……
什么是Java EE兼容的应用服务器为您提供的，您不能轻易/轻松地从Tomcat获得某些第三方子系统？
第三方模块仍然有一些难以获得的function：
- 有状态会话bean（SFSB）
- 扩展持久化上下文
- 应用程序客户端容器/ java web start
- 根据应用程序进行群集。 服务器
- CORBA互操作性
- JCA整合〜
- 远程〜
- 容器管理的事务〜
- 分布式事务的体面管理（例如恢复启发式tx）
带有〜的条目也得到Spring的支持，但不是那么简单，至少据我所知。
这个答案中有一些细节： EJB vs Spring
在严格定义什么是EJB和不是EJB的情况之外，你要向Tomcat添加很多东西。 即使你拥有的是EJB服务器，它也不再是纯粹的Tomcat。
FAQ是正确的：Tomcat不是EJB服务器。 但是，如果你有足够的额外库和代码，它可以是那个或许多其他东西。
EJB实现将是一个编写并打包的bean，可以在任何兼容的EJB服务器上运行。 如果您执行您描述的操作，它可能会起作用，但它不能移植到其他供应商的应用程序服务器。
因此，EJB是一种符合特定规范的标准，因此是可移植的。
在实践中，许多EJB不完全兼容或应用服务器中立。 但是，主要是它们，因此如果您更改应用程序服务器供应商而不是尝试将您描述的体系结构移动到GlassFish，JBoss或Weblogic服务器，那么小的不兼容性将更容易修复。
编辑：为了回应您的评论，您不会通过XML对EJB进行适当的注释和/或配置，以便以符合EJB的方式访问它的代码能够在不进行更改的情况下使用它。
您的评论有两个角度。 一个是你在JBoss或其他任何一个而不是Tomcat上部署的function是什么？ 如果你带来了你依赖的所有框架，可能没什么。 但是，如果您想将代码移动到Weblogic，例如，要使用它的某些function，那么您的代码需要进行一些可能的重大更改才能跟上。
我不是说你不能通过其他方式复制所有EJBfunction（当然是你关心的子集），只是它不是规范，因此不是独立于实现的。
那么我不是有效拥有Java EE应用服务器吗？ 然后不是我的bean EJB？ 还是有其他一些定义特征？
快速回答EJB实际上必须遵循Java EE规范。 Tomcat是Java EE容器而不是应用服务器。
什么是Java EE兼容的应用服务器为您提供的，您不能轻易/轻松地从Tomcat获得某些第三方子系统？
快速回答你的第二个问题。 在你的情况下，很可能没有。
EJB往往是非常重的对象，人们最终使用它们来解决问题，因为它们本质上是矫枉过正的。 创建像Spring这样的框架来解决这些问题而不使用EJB。 我认为引入Spring的第一本书甚至被称为“没有EJB的J2EE开发”。