什么是EJB,它有什么作用？

Question

一直试图了解EJB豆子是什么,这意味着他们的实例是在池中管理的,等等等等.真的无法抓住他们.

你能解释一下他们到底是什么(几乎是为了Java程序员)吗？他们在做什么？他们的目的是什么？为什么要真正使用它们 (为什么不坚持POJO？)也许是一个示例应用程序？

请参阅更新的信息EJB 3.1.有关EJB的日期信息可能会产生误导.

对于EJB学习初学者,请注意:

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

Answer 1

为什么要真正使用它们 (为什么不坚持POJO？)

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

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

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

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

4. 自动交易处理.
   什么都不做,所有的EJB方法都在JTA事务中运行.如果使用JPA或JDBC访问数据库,它将自动登记在事务中.JMS和JCA调用也是如此.在方法之前指定@TransactionAttribute(someTransactionMode)以指定特定方法是否/如何参与JTA事务,覆盖默认模式:"必需".

5. 通过注入非常简单的资源/依赖访问.
   容器将查找资源并将资源引用设置为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;    
   

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

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

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

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

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

10. 真正的踢球者:简单.所有这些都可以使用非常简化的代码完成 - 使用Java EE 6中的EJB的默认设置,或者添加一些注释.在自己的POJO编码企业/工业强度的特点是方式更volumous,复杂且容易出错.一旦开始使用EJB编写代码,它们就很容易开发并提供一系列"免费乘车"优势.

在10年前的原始EJB规范中,EJB是一个主要的生产力麻烦.它们很臃肿,需要大量的代码和配置工件,并提供了大约2/3的上述好处.大多数Web项目实际上并没有使用它们.但是,经过10年的调整,大修,功能增强和开发流程,这已经发生了重大变化.在Java EE 6中,它们提供了最高级别的工业强度和使用简便性.

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

Answer 2

EJB是一个包含业务逻辑的Java组件,您可以将其部署在容器中,并且通过注释,通常以声明方式从容器提供的技术服务中获益:

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

Answer 3

希望Oracle doc能帮助像我这样的人以简单的方式理解EJB的主题.

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

企业Bean的优点由于多种原因,企业bean简化了大型分布式应用程序的开发.首先,因为EJB容器为企业bean提供系统级服务,所以bean开发人员可以专注于解决业务问题.EJB容器而不是bean开发人员负责系统级服务,例如事务管理和安全授权.

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

第三,因为企业bean是可移植组件,所以应用程序组装者可以从现有bean构建新的应用程序.这些应用程序可以在任何兼容的Java EE服务器上运行,前提是它们使用标准API.

何时使用Enterprise Bean如果您的应用程序具有以下任何要求,则应考虑使用Enterprise Bean:

应用程序必须是可扩展的.为了适应越来越多的用户,您可能需要跨多台计算机分发应用程序的组件.应用程序的企业bean不仅可以在不同的计算机上运行,​​而且它们的位置也将对客户端保持透明.

事务必须确保数据完整性.Enterprise Bean支持事务,即管理共享对象的并发访问的机制.

该应用程序将拥有各种客户端.只需几行代码,远程客户端就可以轻松找到企业bean.这些客户可以很薄,种类繁多,数量众多.

Answer 4

我最感兴趣的问题是如何以及在哪里使用它们。要理解这一点，我们首先需要了解存在哪些类型的 EJB。有2大类：

1. 会话bean
2. 消息驱动 Bean

让我们考虑一下会话 Bean。它们有3种：

1. 有状态- 这些组件维护状态并且特定于跨多个请求的客户端。将其视为一个会话。这些可以立即使用的是购物车或其他类型的会话（登录会话等）
2. 无状态- 这些是自包含组件，不会在请求之间保留信息，但它们对于用户来说是唯一的。立即想到的就是服务层中的服务类。想象OrderService。它们的另一个重要用途是公开 Web 服务。同样，这可以在服务层中或完全独立。
3. Singleton - 这些是每个应用程序都存在的 bean，创建一次，可以重复使用/访问多次。我立即Configuration想到了组件 - 您可以在其中存储应用程序级别配置并在需要时从任何地方访问它们。

现在，在任何此类情况下，其余功能或特性都可以跨层使用：

• 安全性- 您可以通过调用的方法上的注释来检查权限。如果您愿意，这可以在服务层和控制器中发生。
• 事务管理——这是服务层或持久层中明显的候选者
• 依赖注入- 再次将在任何地方使用

现代的一大用途是所谓的微服务和面向服务的架构。您可以将一些业务逻辑组件打包为 EJB 并将它们分布在整个组织中，以供多个客户端使用（这里的客户端是指其他后端应用程序）。

等等。现在最大的缺点是您变得非常依赖 EJB 容器，尽管您可以在 2 个参考实现之间切换，但您将无法切换到更轻的东西 - 例如 Tomcat。但为什么你要牺牲所有的好处呢？