EJB概述：分布式多层体系结构

与数据库记录在数据库表中的存在方式类似， 在实体组件中定义了用于标识实体组件的主键（ Primary Key ）对象。该主键与标识数据库表记录的主键相对应，代表同一数据库记录的实体组件的主键值是相同的。客户端应用程序能够利用主键来定位 EJB 容器中的实体组件，进而定位实体组件表示的数据库记录。

按照实体组件的生命期管理方式， EJB 规范将实体组件划分为组件管理持久性（ Bean-Managed Persistence ， BMP ）和容器管理持久性（ Container-Managed Persistence ， CMP ）两种类型。在组件部署过程中，由部署工具为容器管理持久性类型 EJB 组件的生命期方法编写组件状态转换代码， EJB 容器调用这些方法实现组件的状态转换。相对而言，组件程序设计人员必须为组件管理持久性类型 EJB 组件编写控制组件的创建、删除、激活、关闭等生命期测量的 SQL 代码。

◇ 消息驱动组件

消息驱动组件（ Message Driven Bean ）是 EJB2.0 规范中引入的新型组件，用于在 EJB 容器中提供一种响应外部事件消息的组件类型机制。

在引入消息驱动类型 EJB 组件之前，基于 J2EE 的分布式应用对于事件消息的处理方式是利用独立的 Java 事件处理程序来监听来自于客户端应用程序、 EJB 组件、 JSP 组件甚至是 J2EE 平台之外事件源发出的符合 Java 消息服务（ Java Message Service ， JMS ）规范事件消息。引入消息驱动类型 EJB 组件后，部署在 EJB 容器中的消息驱动类型 EJB 组件利用组件中定义的 OnMessage 方法监听来自事件源的消息并做出反映，进而能够调用其它类型的组件来对消息进行响应。消息驱动类型 EJB 组件作为 EJB 容器中的事件监听器（ Listener ），可以在接收到来自 JMS 消息队列中的事件消息后由 EJB 容器来激活消息驱动组件对象实例。

消息驱动组件是服务器端的无状态类型组件。该类型的组件只有组件类定义，没有类似于会话组件和实体组件的 Home 接口和 Remote 接口。

EJB 规范定义的开发者角色

EJB 组件体系结构是基于 J2EE 规范构建的应用软件系统的主要部分。完整 J2EE 应用的核心内容是封装了商务逻辑的 EJB 组件。

按照 EJB2.0 规范的定义，基于 EJB 规范的分布式计算体系结构由六个角色组成，这六个角色可以是软件开发团队、系统软件供应商、应用软件集成商等，每个角色所完成的工作必须遵循 EJB 规范，以保证彼此之间的兼容性。这六个角色分别是：

◇ EJB 组件开发者

EJB 组件开发者 (Enterprise Bean Provider) 负责开发封装有商务规则的 EJB 组件。 EJB 组件开发者定义 EJB 组件的 Home 接口和 Remote 接口、编写组件类并且提供部署 EJB 组件的部署描述文件 (Deployment Descriptor) 。 EJB 组件开发者是商务应用开发领域的专家 ，不需要精通系统级编程方法以及系统级的组件事务管理、同步、安全性、分布式计算等细节。

◇ 部署者

部署者 (Deployer) 负责将打包后的 EJB 组件部署到 EJB 服务器等应用环境中。部署者应根据 EJB 组件的部署描述文件中声明的对各种类型的资源，如数据库、安全性管理等的需求来配置 EJB 服务器来为组件提供服务。部署者是 EJB 应用环境方面的专家。

◇ 应用组装者

应用组装者 (Application Assembler) 负责将各种类型的 EJB 组件组合成一个完整的应用系统，因此应用组装者必须明确待组装 EJB 组件的 Home 接口和 Remote 接口定义的详细内容。

◇ EJB 服务器提供者

EJB 服务器通常由操作系统开发商、中间件开发商或数据库开发商来提供。因此， EJB 服务器提供者 (EJB Server Provider) 是应用软件系统领域的专家，精通分布式系统管理、分布式对象管理及其它系统服务。

◇ EJB 容器提供者

EJB 容器提供者 (EJB Container Provider) 是系统级的编程专家，其工作主要集中于开发可伸缩的，具有事务、交易和安全管理功能的集成在 EJB 服务器中的 EJB 容器。 EJB 容器提供者为 EJB 组件开发者提供了一组标准的 API 来访问 EJB 容器，使 EJB 组件开发者不需要了解 EJB 服务器中的各种技术细节就能够开发出部署在 EJB 容器中的 EJB 组件。

在实际应用中，通常假定 EJB 服务器提供者和 EJB 容器提供者来自同一软件开发商，因而没有定义 EJB 服务器提供者和 EJB 容器提供者之间的接口标准。

◇ 系统管理员

系统管理员 (System Administrator) 负责为 EJB 服务器和 EJB 容器提供一个企业级的计算环境并利用 EJB 服务器和 EJB 容器提供的监测管理工具监测 EJB 组件的运行情况。

EJB 容器

企业信息系统业务层中的 EJB 组件通常部署在被称为 EJB 容器的应用服务器中 ，由 EJB 容器提供 EJB 组件的状态管理、事务管理、线程管理、远程数据资源访问、连接管理和安全性管理等系统级服务。所有的 EJB 组件实例都运行在 EJB 容器中，由 EJB 容器控制着 EJB 组件的生命期。 EJB 组件可以被定制为提供安全和事务处理等各种系统级服务，但这些服务特性在本质上不属于 EJB 组件类，而是由部署 EJB 组件的容器来提供和实现的。

按照 EJB 规范编写的任何 EJB 组件均可以部署到任何一个与规范兼容的 EJB 容器中，可以根据应用系统的需要配置 EJB 容器来对组件的事务或安全性进行管理。在 EJB 组件部署过程中将业务逻辑的处理功能与底层的应用系统服务逻辑分开，使得 EJB 容器可以在运行时（ Runtime ）创建和管理 EJB 组件。

使用 EJB 组件
因为 EJB 体系结构被设计为高度灵活的，并支持使用任意复杂的方式连接企业级 bean ，所以可构建许多不同的方案，来说明应用程序可怎样使用企业级 bean 。一个有用的方案提出将 EJB 组件表示为三层信息系统的关键组件，该系统将企业数据、事务和应用程序资源连接到 Web 上。

基于 EJB 的三层编程模型视 Web 浏览器为第一层，视支持应用程序的 Web 服务器为第二层，视企业信息资源为第三层。在此编程模型中，除了 EJB 技术外，还实现了 Java servlet 技术、 JavaBeans 技术和 Java Server Page (JSP) 技术。下图显示了各层的排列情况：

第一层是瘦客户机 -- 通常是 Web 浏览器，它可以处理普通 Web 数据类型，如 HTML 和 GIF ，并支持 HTTP 通信。第二层是 Web 应用程序服务器，它是用代码扩充的 Web 服务器，用来对能够通过 Web 服务器调用的应用程序提供运行时支持。现有的 Web 应用程序都沿用 CGI-BIN 编程模型，但预计第二层应用程序开发将转向 Java servlet 编程模型，后者提供大幅改善的性能和可移植性。除支持 Java servlet 外， Web 应用程序服务器还将添加 EJB 服务器功能，以支持使用 EJB 组件的应用程序。第三层代表企业级信息资源，可以包括关系数据库和面向对象的数据库、事务监视器和定制的应用程序。 EJB 技术在这一设计中扮演着关键角色，因为，它使驻留在第二层上的应用程序组件，与组成第三层的企业资源之间的接口，得以标准化。

Java servlet 、 Java beans 和 Java server page 不是 EJB 应用程序方案的必需元素，但它们可与 EJB 组件一起工作，以提供基于 Java 的内聚性的应用程序环境。此处描绘的环境将以下职责指定给参与工作的 Java 组件：

• 给 Java servlet 指定了应用程序 “ 控制器 ” 的角色
• JSP 页面处理数据表示和用户界面的任务
• Java bean 充当 “ 数据封装器 ” ，存储中间结果的数据
• EJB 组件提供访问企业信息资源的机制

客户可以使用一个假定的、基于 EJB 的 Web 应用程序更新现有的库存，并用容器管理式持久性和容器管理式事务，将访问库存数据库的位置封装在实体 EJB 组件的内部。库存票据可通过 Web 浏览器输入，浏览器提供一个 HTML 表单来捕获产品编号、供应商，等等，并在提交时调用一个 servlet 。 servlet 代码充当应用程序控制器角色，确定哪些企业数据库需要更新，需要用户追加什样的信息。 servlet 可通过代表它的实体 bean 访问主库存数据库，并调用 JNDI 接口获取对此 bean 的本地对象的引用，然后使用 finder 方法定位所请求产品编号的远程对象。此时，通过调用远程对象的方法， servlet 可更新库存计数，接着容器将此方法委托给 EJB 组件。因为容器根据数据库更新，以对 bean 透明的方式划分一个事务，而且以对 bean 透明的方式将数据写入数据库来保证数据持久性，所以也就保持了数据的完整性。

从 EJB 组件返回到 servlet 的任何结果信息，都可以使用 setter 方法存储在一个（非企业的） Java bean 的属性中。此时 servlet 可将控制权转让给一个适当的 JSP 页面，以便将这些结果组合到表示格式中，并将结果返回给用户。 JSP 页面很可能主要由静态文本和有关单个事务的可变信息占位符组成。在向浏览器发送表示数据之前， JSP 页面使用 getter 方法从 Java bean 的属性中获得可变数据元素。

基于 EJB 的三层设计提供了几个好处，包括：

• 访问企业数据的业务逻辑可封装在可重用、可移植的企业级 bean 中。
• 现有的企业系统只需很少修改或者根本不需要修改，就可以集成为企业级 bean 。
• 企业应用程序所需的运行时服务，如事务和持久性，可以从 bean 中分解出来，并指定给此 bean 的容器。
• 无须更改 EJB 组件，即可修改控制应用程序流程的 Servlet 。
• Servlet 代码可将注意力集中在应用程序控制逻辑上，而无须考虑数据表示。
• JSP 页面可将静态和动态内容混合在一起，生成表示信息。
• 用 Java 语言编写的系统组件，对于具有 JVM 的任何平台都是可移植的。

结论
在开发能够支持关键任务的企业级信息系统的过程中， EJB 规范代表了 Java 技术的下一个发展阶段。 EJB 组件将随 JavaBeans 规范引入的 Java 组件模型，扩展到服务器领域，从而使业务逻辑组件的开发可以跨企业应用程序重用，并且可以跨支持 Java 的平台移植。由于包含了基于 RMI 技术的对象分布，所以支持跨多层的可执行组件的分立，从而允许最大的实现灵活性和高度可伸缩性。如果将常规的企业应用程序运行时服务重新定义为可指定给容器抽象的对象服务，则允许 EJB 组件的开发人员将精力集中在业务逻辑上，从而减小了通常与运行时服务相关的复杂性和平台相关性。

增强 Java 运行环境，以包括命名和目录服务的标准接口、关系数据库访问、事务服务和远程对象访问，使 Java 开发人员能够编写强健的企业应用程序，而不必离开 Java 编程环境。将其它 Java 技术 -- 如 Java servlet 和 JavaServer Pages 技术 -- 与 EJB 组件一起使用，可创建一个对于大型企业系统来说足够强健的紧凑编程模型，但由于使用了巧妙的接口，从而简化了开发工作。 而且，因为 EJB 体系结构是 JavaBeans 组件模型的逻辑扩展，所以作为 EJB 组件开发的业务逻辑可跨多个企业应用程序重用。

企业级 bean 体系结构的另一个好处是，提供了现有企业信息系统的直接集成通道，此通道可能与 Java 编程语言或 bean 编程模型毫无共同之处。因为现有的企业信息资源 -- 如关系数据库、事务监视器和业务应用程序的定制新品种 -- 可通过将它们封装在 EJB 组件中连接到 Web 前端，而无须替换应用程序或重写主要代码段，所以，客户可保护其现有的 IT 投资。

考虑到 EJB 技术的巨大前景， IT 业界以相当大的兴趣欢迎 EJB 规范，就不是什么令人惊讶的事了。 EJB 体系结构提供的一个最大好处可能是，把业务逻辑编程与将业务逻辑和企业级服务器端运行环境的复杂集成分离开来 。如果部署了 EJB 组件的容器承担了管理运行时服务（如持久性、事务和并发数据库访问）的职责，则 bean 的开发人员就可以自由地将精力集中在开发封装业务逻辑的软件组件上。 JavaSoft 副总裁表述了 EJB 技术的重要性（引自 Sun Microsystems 网站）：

“‘Enterprise JavaBeans API 将为企业开发人员和解决方案提供商提供一种新的战略武器，供他们建立下一代行业领先的、基于关键业务的应用程序， ’Sun Microsystems 的 JavaSoft 软件产品部副总裁， Jon Kannegaard 说： ‘ 因为用 Enterprise JavaBeans API 设计的应用程序将与现有的企业系统一起工作，所以企业利用 Java 平台会获得新的竞争优势，同时还保留他们对现有技术的投资， ’Kannegaard 继续说。

“ 使用 Enterprise JavaBeans API ，开发人员将能够消除应用程序开发过程中的复杂性。这是可能的，因为每个 Enterprise JavaBeans 组件都封装了一个基本的业务功能。目前开发人员必须懂得如何编写业务逻辑和专门的系统级程序，以控制诸如安全性功能部件和处理多个事务的能力 -- 一项既枯燥又复杂的任务。 Enterprise JavaBeans API 使全体开发人员能够将精力集中在编写解决业务问题的逻辑上，而不是将精力集中在编写用以简化不同技术间交互作用的代码上。