什么是EJB，它做什么？

Question

我一直在努力学习什么是EJB bean，这意味着他们的实例在池中被管理，等等。真的不能很好地掌握它们。

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

请仅参考更新的信息，即ejb3.1。关于EJB的过时信息可能具有误导性。

对于EJB学习初学者，请注意：

EJB基于分布式对象，这是指运行在由网络连接的多台机器（虚拟或物理）上的软件部件。

Answer 1

希望Oracle doc的这篇文章能帮助像我这样的人以一种简单的方式理解EJB的主题。

什么是企业Bean？企业bean是用Java编程语言编写的服务器端组件，它封装了应用程序的业务逻辑。业务逻辑是实现应用程序目的的代码。例如，在库存控制应用程序中，企业bean可以在名为checkInventoryLevel和orderProduct的方法中实现业务逻辑。通过调用这些方法，客户机可以访问应用程序提供的清单服务。

企业Bean的好处出于几个原因，企业Bean简化了大型分布式应用程序的开发。首先，因为EJB容器向企业bean提供系统级服务，bean开发人员可以集中精力解决业务问题。EJB容器而不是bean开发人员负责系统级服务，如事务管理和安全授权。

其次，因为bean而不是客户机包含应用程序的业务逻辑，所以客户机开发人员可以专注于客户机的表示。客户机开发人员不必编写实现业务规则或访问数据库的例程。因此，客户端更薄，这一好处对于在小型设备上运行的客户端尤为重要。

第三，由于企业bean是可移植组件，应用程序汇编程序可以从现有bean构建新的应用程序。这些应用程序可以在任何兼容的JavaEE服务器上运行，只要它们使用标准的API。

何时使用企业Bean如果您的应用程序具有以下任何要求，您应该考虑使用企业Bean：

应用程序必须是可伸缩的。为了适应越来越多的用户，您可能需要在多台机器上分发应用程序的组件。一个应用程序的企业bean不仅可以在不同的机器上运行，而且它们的位置对客户端仍然是透明的。

事务必须确保数据完整性。企业bean支持事务，即管理共享对象并发访问的机制。

该应用程序将有多种客户端。只需几行代码，远程客户端就可以轻松找到企业bean。这些客户机可以是瘦的、多种多样的，而且数量众多。

Answer 2

EJB是一个Java组件，包含业务逻辑，您可以将其部署在一个容器中，并受益于容器提供的技术服务，通常是以声明的方式，这要归功于注释：

• 事务管理：事务可以在调用EJB的方法之前自动启动，并在该方法返回后提交或回滚。这个事务上下文被传播到对其他EJB的调用。
• 安全管理：可以检查调用方是否具有执行该方法所需的角色。
• 依赖注入：可以将其他EJB或资源（如JPA实体管理器、JDBC数据源等）注入到EJB中。
• 并发：容器确保一次只有一个线程调用EJB实例的方法。
• 分布：一些EJB可以从另一个JVM远程调用。
• 故障转移和负载平衡：如果需要，您的EJB的远程客户端可以自动将其调用重定向到另一台服务器。
• 资源管理：有状态bean可以自动钝化到磁盘，以限制服务器的内存消耗。
• 我可能忘记了一些要点。

Answer 3

为什么真的要用它们？（为什么不坚持POJO呢？）

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

>

在多个松散耦合的应用程序/客户端之间重用/共享逻辑
EJB可以打包在自己的JAR中，可以在很多地方部署和调用。它们是常见的组件。没错，波乔可以（小心！）设计成库，包装成罐。但EJB同时支持本地和远程网络访问——包括通过本地java接口、透明RMI、JMS异步消息和SOAP/REST web服务，从而避免使用多个（不一致的？）jar依赖项进行剪切和粘贴部署
它们对于创建SOA服务非常有用。当用于本地访问时，它们是POJO（添加了免费容器服务）。设计一个单独的EJB层的行为促进了对最大化封装、松耦合和内聚的额外关注，并促进了一个干净的接口（Facade），使调用方免受复杂处理的影响

可伸缩性和可靠性如果应用来自各种调用消息/进程/线程的大量请求，它们首先分布在池中的可用EJB实例上，然后排队。这意味着，如果每秒传入的请求数大于服务器可以处理的数量，我们会优雅地降级——总是有一些请求得到有效处理，多余的请求会等待。我们没有达到服务器“崩溃”的程度——所有请求都会同时经历糟糕的响应时间，而且服务器试图访问比硬件更多的资源

并发管理。该容器确保多个客户端安全（串行）地自动访问EJB实例。容器管理EJB池、线程池和调用队列，并自动执行方法级写锁定（默认）或读锁定（通过@Lock（read））。这可以防止数据因并发写-写冲突而损坏，并通过防止读-写冲突来帮助数据一致地读取
这主要适用于@Singleton会话bean，其中bean在客户端调用方之间操作和共享公共状态。手动配置或以编程方式控制并发代码执行和数据访问的高级场景时，这一点很容易被忽略。

自动交易处理
什么都不做，所有EJB方法都在JTA事务中运行。如果使用JPA或JDBC访问数据库，它会自动登记到事务中。JMS和JCA调用也是如此。在方法之前指定@TransactionAttribute（someTransactionMode），以指定该特定方法是否/如何参与JTA事务，覆盖默认模式：“必需”。

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

@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的智能交互。默认情况下，如上所述注入的EntityManager使用事务范围的持久性上下文。这非常适合无状态会话bean。当调用（无状态）EJB方法时，在新事务中创建新的持久性上下文，检索/写入数据库的所有实体对象实例仅在该方法调用中可见，并且与其他方法隔离。但是，如果该方法调用其他无状态EJB，则容器将传播并共享相同的PC到它们，因此相同的实体将通过同一事务中的PC以一致的方式自动共享。
如果声明了@有状态会话bean，则等于智能与JPA的亲和性是通过将entityManager声明为扩展范围来实现的：@持久性内容（unitName="AcCountsPU， type=EXTENDED）。这存在于bean会话的生命周期中，跨多个bean调用和事务，缓存先前检索/写入的DB实体的内存副本，因此不需要重新检索它们。

生命周期管理。EJB的生命周期由容器管理。根据需要，它创建EJB实例，清除并初始化有状态会话bean状态，钝化

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

标准化

真正的关键：简单。所有这些都可以通过非常精简的代码来完成——或者使用Java EE 6中EJB的默认设置，或者添加一些注释。在您自己的POJO中编码企业/行业优势功能将更加庞大、复杂和容易出错。一旦你开始使用EJB编码，它们就很容易开发，并提供了一系列“免费”的好处。

在10年前最初的EJB规范中，EJB是一个主要的生产力问题。它们过于臃肿，需要大量代码和配置工件，并提供了上述好处的约2/3。大多数web项目实际上并没有使用它们。但经过10年的调整、检修、功能增强和开发，情况发生了显著变化。在JavaEE6中，它们提供了最高级别的工业强度和简单的使用。

有什么不喜欢的？？：-）：-）