jakarta-ee - 什么是 EJB，它有什么作用？

Question

一直在努力学习什么 EJB bean 是什么，它们的实例在池中管理是什么意思，等等。真的不能好好把握他们。

你能解释一下它们到底是什么(实际上对于 Java 程序员来说)？他们做什么？他们的目的是什么？为什么要真正使用它们？ (为什么不只是坚持 POJO ？)也许是一个示例应用程序？

请仅引用更新信息，即 EJB 3.1 .关于 EJB 的过时信息可能会产生误导。

EJB学习初学者请注意:

EJB 基于 分布式对象 ，这是指在由 链接的多台机器(虚拟或物理)上运行的软件片段。网络 .

Answer 1

Why really use them? (Why not just stick to POJO?)

如果您需要一个组件来访问数据库，或访问其他连接/目录资源，或从多个客户端访问，或用作 SOA 服务，那么当今的 EJB 通常“更大、更强、更快(或至少更具可扩展性)”并且比 POJO 更简单”。它们对于通过 Web 或公司网络为大量用户提供服务最有值(value)，而对于部门内的小型应用程序的值(value)稍低。

使用松耦合在多个应用程序/客户端之间重用/共享逻辑。
EJB 可以打包在它们自己的 jar 中，从很多地方部署和调用。
它们是通用组件。确实，POJO 可以(仔细!)设计为库和
包装成 jar 。但是 EJB 支持本地和远程网络访问——包括
通过本地 java 接口(interface)、透明 RMI、JMS 异步消息和 SOAP/REST Web 服务，
从具有多个(不一致？)部署的剪切和粘贴 jar 依赖项中保存。
它们对于创建 SOA 服务非常有用。当用于本地访问时，它们是
POJO(添加了免费的容器服务)。设计单独的 EJB 层的行为
促进对最大化封装、松散耦合和内聚的额外关注，以及
促进干净的界面(Facade)，使调用者免受复杂的处理和数据的影响
楷模。

可扩展性和可靠性
如果您应用来自各种调用消息/进程的大量请求
/threads，它们首先分布在池中可用的 EJB 实例中
然后排队。这意味着如果每秒传入的请求数是
大于服务器可以处理的，我们优雅地降级 - 总是有一些
请求被有效处理，多余的请求被等待。我们
不要到达服务器“崩溃” - 所有请求都会经历可怕的响应时间
同时，加上服务器尝试访问比硬件和操作系统更多的资源
可以处理并因此崩溃。 EJB 可以部署在单独的层上
集群 - 这通过从一台服务器到另一台服务器的故障转移提供可靠性，加上
可以添加硬件以线性扩展。

并发管理。
容器确保自动安全地访问 EJB 实例(串行)
由多个客户。容器管理 EJB 池、线程池、
调用队列，并自动执行方法级写锁定(默认)或
读锁定(通过@Lock(READ))。这可以通过以下方式保护数据免受损坏
并发写-写冲突，并通过防止数据的一致性读取
读写冲突。
这主要对 @Singleton session bean 有用，其中 bean 正在操作和
在客户端调用者之间共享公共(public)状态。这可以很容易地手动覆盖
配置或以编程方式控制并发代码执行的高级方案
和数据访问。

自动交易处理。
什么都不做，所有的 EJB 方法都会运行
在 JTA 事务中。如果您使用 JPA 或 JDBC 访问数据库，它会自动
参加了交易。 JMS 和 JCA 调用相同。指定
@TransactionAttribute(someTransactionMode) 在一个方法之前指定是否/如何
特定方法参与 JTA 事务，覆盖默认模式:“必需”。

通过注入(inject)非常简单的资源/依赖访问。
容器将查找资源并将资源引用设置为实例字段
EJB:如JNDI存储的JDBC连接、JMS连接/主题/队列、其他
EJB、JTA 事务、JPA 实体管理器持久化上下文、JPA 实体管理器
工厂持久性单元和 JCA 适配器资源。
例如设置对另一个 EJB 和 JTA 事务和 JPA 实体管理器的引用
JMS 连接工厂和队列:

@Stateless
public class MyAccountsBean {

    @EJB SomeOtherBeanClass someOtherBean;
    @Resource UserTransaction jtaTx;
    @PersistenceContext(unitName="AccountsPU") EntityManager em;
    @Resource QueueConnectionFactory accountsJMSfactory;
    @Resource Queue accountPaymentDestinationQueue;

    public List<Account> processAccounts(DepartmentId id) {
        // Use all of above instance variables with no additional setup.
        // They automatically partake in a (server coordinated) JTA transaction
    }
}

一个 Servlet 可以在本地调用这个 bean，只需声明一个实例变量:

@EJB MyAccountsBean accountsBean;    

然后根据需要调用它的方法。

与 JPA 的智能交互。
默认情况下，如上注入(inject)的 EntityManager 使用事务范围的持久性
语境。这对于无状态 session bean 来说是完美的。当一个(无状态)EJB 方法
被调用，在新事务中创建一个新的持久化上下文，所有
检索/写入数据库的实体对象实例仅在该数据库中可见
方法调用并与其他方法隔离。但是如果其他无状态 EJB 是
由该方法调用，容器向它们传播并共享相同的 PC，因此相同
实体通过 PC 以一致的方式自动共享
交易。
如果声明了@Stateful session bean，则通过以下方式实现与 JPA 的同等智能关联
将 entityManager 声明为扩展范围:
@PersistentContent(unitName="AccountsPU, type=EXTENDED). 这存在于生命周期
bean session ，跨多个 bean 调用和事务，缓存内存中的副本
之前检索/写入的 DB 实体的数量，因此它们不需要重新检索。

生命周期管理。
EJB 的生命周期是容器管理的。根据需要，它创建 EJB 实例，
清除和初始化有状态 session bean 状态、钝化和激活以及调用
生命周期回调方法，因此 EJB 代码可以参与生命周期操作以
获取和释放资源，或执行其他初始化和关闭行为。
它还捕获所有异常，记录它们，根据需要回滚事务，以及
根据需要抛出新的 EJB 异常或 @ApplicationExceptions。

安全管理。
可以通过简单的注释或 XML 配置对 EJB 的基于角色的访问控制
环境。服务器会自动传递经过身份验证的用户详细信息以及每个
作为安全上下文调用(调用主体和角色)。它确保所有 RBAC
规则是自动执行的，因此方法不会被非法调用
错误的角色。它允许 EJB 轻松访问用户/角色详细信息以进行额外的编程
检查。它允许将额外的安全处理(甚至 IAM 工具)插入到
容器以标准方式。

标准化和便携性。
EJB 实现符合 Java EE 标准和编码约定，提高质量
以及易于理解和维护。它还促进了代码向新的可移植性
供应商应用服务器，通过确保它们都支持相同的标准功能和
行为，并通过阻止开发人员意外采用专有
非可移植供应商功能。

真正的踢球者:简单。以上都可以用
非常精简的代码 - 使用 EJB 的默认设置
在 Java EE 6 中，或添加一些注释。编码
您自己的 POJO 中的企业/行业实力特征将
变得更加庞大、复杂和容易出错。一旦您
开始使用 EJB 进行编码，它们相当容易开发并提供大量“搭便车”的好处。

在 10 年前的原始 EJB 规范中，EJB 是一个主要的生产力问题。它们臃肿，需要大量代码和配置工件，并提供了上述 2/3 的好处。大多数 Web 项目实际上并没有使用它们。但随着 10 年的调整、大修、功能增强和开发精简，这种情况发生了显着变化。在 Java EE 6 中，它们提供了最高级别的工业强度和使用简单性。

不喜欢什么？？ :-) :-)