Enterprise JavaBeans组件慨述（3）

使用 EJB 技术的好处

　　这些设计目标会使企业和开发人员得到什么好处呢？下面列出了可望从采用 Enterprise JavaBeans 环境获得的好处：

　　EJB 组件使编写应用程序更为简单。尽管 EJB 体系结构复杂，但应用程序开发人员一般都不必再编写用于访问系统服务的代码。一种称为 EJB 容器的系统组件使系统服务可用于 EJB 组件的任务。

　　服务器端商务逻辑可以移植。除了 Java 语言固有的可移植性外，EJB 体系结构还在 bean 和支持该 bean 的容器之间提供了一套标准化的应用程序编程接口。这使开发人员能够将 bean 从一种操作环境移植到另一种操作环境，而无须重新编写其源代码。

　　可以从现有的软件组件装配出服务器端应用程序，这与从现有的 Java bean 可以装配出客户端应用程序一样，从而使软件能够重用。

　　EJB 体系结构内置了对典型企业级系统服务的支持，包括分布式对象、事务处理、数据库、安全和全局命名。

　　多家 IT 供应商都采纳 EJB 体系结构，这是由于有这样的承诺：客户将能够从选定的供应商那里选购软件组件，如 EJB 组件、容器及 EJB 服务器；也由于承诺了不同供应商的产品，只要符合 EJB 体系结构，就都是可互操作的。

　　用 EJB 组件构建的应用程序可以从一个服务器移植到另一个服务器，从而支持可伸缩性，这是因为在 EJB 模型中，各个软件组件都是严格分离的。

　　EJB 体系结构能保障原有的 IT 投资，这是通过允许将现有的信息系统和资产“包裹”在这些应用程序中，而不要求客户更换现有技术。事实上，在关系数据库中存储数据的企业已经有了一套已有雏形的实体 bean，正等着通过 EJB 外壳去访问。

　　进一步考察 JNDI

　　Enterprise JavaBeans 组件使用 Java Naming and Directory Interface (JNDI) 来访问各种目录服务。JNDI 分两部分：应用程序编程接口 (API) 和服务供应商接口 (SPI)：

　　“JNDI 体系结构由 JNDI API 和 JNDI SPI 组成。JNDI API 允许 Java 应用程序访问各种命名和目录服务。JNDI SPI 则是设计来供任意一种服务的供应商（也包括目录服务供应商）使用。这使得各种各样的目录服务和命名服务能够透明地插入到使用 JNDI API 的 Java 应用程序中。（见 JavaSoft，“JNDI: Java Naming and Directory Interface”）

　　JNDI API 并不同某种专用的命名技术或目录技术连在一起，也不同任何供应商的目录服务连在一起，因此它对 EJB 组件的可移植性有所贡献。例如，客户可以从多种不同的技术中选择，来为其 EJB 应用程序提供目录服务，这些技术包括：

　　LDAP：Sun 的 LDAP 服务供应商支持 LDAP 协议的第 2 版和第 3 版。

　　NIS：Sun 提供一个 NIS 服务供应商（NIS 即网络信息服务，以前称为黄页）。

　　COS 命名：Sun 的 COS 命名服务供应商提供对 CORBA 命名服务的访问。

　　文件系统：Sun 提供一个服务供应商来访问文件系统。

　　RMI 注册：Sun 为 RMI 注册提供一个服务供应商。

　　Novell：有几个服务供应商可提供对目录服务 NDS 的访问以及 NetWare 3X 连接库、Novell 文件系统和其他 Novell 服务（如扩展 NCP）的访问。

　　虽然 JNDI 规范对供应商是中立的，但不应认为，实现 JNDI 接口的应用程序服务器一定要能访问来自多个供应商的服务供应商代码。

　　JNDI 命名体系结构的关键概念包括：

　　对象和名称之间的绑定。

　　若干称为命名上下文的绑定集。

　　命名系统，即若干组命名上下文。

　　命名空间，指一个命名系统中的所有名称。

　　名称分类为原子名称、复合名称和合成名称。原子名称是不可分割的，可以绑定到一个对象上。复合名称是原子名称的组合，而合成名称则跨越多个命名系统。

　　命名上下文特别重要：所有的命名操作均是在上下文对象上进行的，并且名称解析过程总是从最初的命名上下文开始。

　　EJB 应用程序是如何使用 JNDI 的呢？JNDI 的主要用途是检索对 EJB 组件的引用。因为 EJB 框架是一个分布式对象框架，所以 EJB 应用程序不应当假定 EJB 组件的位置。JNDI 就是获取对 bean 的起始引用的一种机制。当一个 bean 安装到一个 enterprise bean 服务器上时，一个被称为 EJB 容器的软件组件就负责创建各个名称-对象绑定，使所需的 Java 类文件能使用这个 bean。应用程序使用 JNDI 的查找方法来检索对象引用，如下例所示：

　　Context initialContext = new InitialContext( );
　　 CartHome cartHome = javax.rmi.PortableRemoteObject.narrow(
　　 initialContext.lookup("applications/shopping_cart"), CartHome.class);

　　应用程序有责任知道外部名称，应用程序就是通过这个名称才得以引用一个 enterprise bean，并通过 JNDI 来获取对该 bean 的引用的。

　　进一步考察 JTA

　　除 JNDI 以外，Enterprise JavaBeans 体系结构还使用 Java Transaction API (JTA)。因为事务对维护数据完整性和可靠性很重要，所以支持事务处理是 EJB 体系结构的一个基本部分。如果企业应用程序是分布式的，事务处理就会更加重要：

　　“事务的概念是一个重要的编程范例，其目的在于简化既要求可靠性又要求可用性的应用程序结构，特别是那些需要同时访问共享数据的应用程序。事务的概念最早是用在商务运作的应用程序中，其中它被用于保护集中式数据库中的数据。后来，事务的概念已扩展到分布式计算的更广泛的环境中。今天，事务是构建可靠的分布式应用程序的关键，这一点已得到广泛承认。”（见对象管理组的“Transaction Service Specification”）

　　有时将事务描述为具有下列特征的工作单元：

　　原子性 — 如果因故障而中断，所有结果均撤销

　　一致性 — 事务的结果保留不变的特性

　　孤立性 — 中间状态对其他事务是不可见的

　　持久性 — 已完成的事务的结果是持久的

　　事务的终止有两种方式：提交一个事务会使其所有的更改永久不变，而回滚 (rolling back) 一个事务则撤销其所有的更改。

　　对象管理组织 (OMG) 为一种面向对象的事务服务，即对象事务服务 (OTS)，创建了一种规范。OTS 是 EJB 体系结构内的事务服务的基础。下列事务规范就是为 enterprise bean 所采用的事务模型而设：

　　OMG 的对象事务服务 (OTS)

　　Sun Microsystems 的 Transaction Service (JTS)

　　Sun Microsystems 的 Java Transaction API (JTA)

　　开放组 (X/Open) 的 XA 接口

　　这种与语言无关的对象事务服务，为一个强健的分布式事务服务提供了基本概念、定义和功能。

　　Java Transaction Service 是 OTS 的 Java 映射，在 org.omg.CosTransactions 和 org.omg.CosTSPortability 这两个包中定义。JTS 对事务分界和事务环境的传播之类的服务提供支持。JTS 功能由应用程序通过 Java Transaction API 访问。

　　Java Transaction API 指定事务管理器与分布式事务中涉及的其他系统组件之间的各种高级接口，这些系统组件有应用程序、应用程序服务器和资源管理器等。JTA 功能允许事务由应用程序本身、由应用程序服务器或由一个外部事务管理器来管理。JTA 接口包含在 javax.transaction 和 javax.transaction.xa 这两个包中。

　　XA 接口定义了资源管理器和分布式事务环境中外部事务管理器之间的约定。外部事务管理器可以跨多个资源协调事务。XA 的 Java 映射包含在 Java Transaction API 中。