最佳实践: 向 WebSphere Application Server 的 EJB 环境迁移

并不是所有应用程序都适合于在 Enterprise JavaBeans (EJB) 环境中使用。按照这篇最佳实践中所列的标准对您的应用程序进行评估，就可以确定该应用程序是否适合于迁移到 EJB 环境。

读者： 架构设计师、开发人员和项目经理

产品： WebSphere Application Server
版本： 3.0 或更高版本
平台： 所有平台

关键字： 企业 bean、 EJB

主题： 数据访问、EJB、迁移、可伸缩性和安全性

摘要

并不是所有企业应用程序都适合于在 Enterprise JavaBeans (EJB) 环境中使用。按照这篇最佳实践中所列的标准对您的应用程序进行评估，就可以确定该应用程序是否适合于迁移到 EJB 环境。

回页首

推荐

企业 bean 是用于企业应用程序的新 Java 组件模型。请注意：

• 企 业 bean 总是分布式的。它们将 Java 服务器端组件同分布式对象技术，如公共对象请求代理体系结构（Common Object Request Broker Architecture (CORBA)）以及远程方法调用（Remote Method Invocation (RMI)），结合起来。企业 bean 总是分布式的这一事实使得它们同标准 JavaBeans 有根本的不同。
• 企 业 bean 提供业务逻辑而不是表示逻辑。因此，您必须将它们同表示技术一起使用，例如用于 HTML 客户机的 servlet 或 Java Server Pages (JSP)，或者使用抽象窗口工具箱（Abstract Window Toolkit (AWT)）或 Swing 的 Java 应用程序。
• 企业 bean 可以通过提供处理安全性、资源合用、持久性、并发性和事务完整性的服务来简化应用程序。

在将您的应用程序迁移到 WebSphere Application Server 3.0 或更高版本 EJB 环境之前，需要考虑下列标准。如果您的应用程序符合其中的一条或多条标准，那么企业 bean 就适合于您的应用程序。

必须将业务逻辑组件同公共因特网隔离

应 用程序软件（尤其是组成业务逻辑的规则和数据结构）通常是关键的公司财产，而且需要加以保护。例如，维护股票交易网站的金融机构可能要确保公众无权访问他 们的私有分析工具的源代码或目标代码。在类似这种情况下，需要将业务逻辑置于一组安全防火墙之后（经常称为 DMZ）。

企业 bean 所提供的分布式对象组件体系结构允许将宝贵的公司财产置于防火墙之后加以隔离，同时仍然允许表示代码访问防火墙后的 EJB 服务器。图 1 说明了这种类型的分布式解决方案。

	图 1：防火墙内的企业 bean

该模型做了如下假设：

• 表示逻辑不如后端业务逻辑有价值。
• 防火墙的配置不同。在图 1 中，防火墙 1 有一个“洞”供端口 80 和 443（分别是 HTTP 和 HTTPS 端口）使用，而防火墙 2 有一个供 IIOP 和安全 IIOP 协议使用的洞。

应用程序需要多种客户机类型来访问共享数据

单个应用程序经常有需要访问相同数据的多种客户机类型。例如，应用程序可以有供外部客户使用的有限制的基于 Web 的 HTML 客户机，以及供内部用户使用的更完整的基于 Java 的客户机。这两种客户机都需要访问相同的数据源（数据库表）。

在 EJB 环境中，您可以将常用数据和业务逻辑置于单组企业 bean 中。这些 bean 被不同类型的客户机访问（例如，servlet/HTML 客户机和应用程序客户机）。企业 bean 控制对后端数据的访问，并且在内部管理当前事务和数据库锁定。

这一编程模型比传统解决方案更有效，传统解决方案为共享相同数据源的同一应用程序编写两个版本。使用企业 bean 除去了重复的应用程序代码需要，也减少了在编写数据库控制逻辑上所做的工作。

应用程序需要对共享数据进行并发读取和更新访问

传统的“胖客户机”解决方案要求应用程序在数据库级别上管理对共享数据的访问。在这一级别上访问数据涉及处理数据库锁定和并发以保持数据完整性的复杂方案。

WebSphere Application Server 3.0 中的企业 bean 自动处理复杂的线程操作和同时发生的数据共享问题。在保持数据完整性的同时，它们控制对后端数据的访问并在内部对当前事务和数据库锁定进行管理。

应用程序需要对多个数据源进行事务性访问

许 多应用程序必须能够访问多个数据源。例如，请考虑一个使用中间层 Oracle 数据库和具有 MQseries 接口的大型机 CICS 或 IMS 系统上的数据的应用程序。下订单时，应用程序将该订单信息存储在 Oracle 数据库中，并同时通过 MQSeries 接口将发货订单发送给大型机系统。在类似情况下，为了维护数据源内数据的完整性，对数据的访问必须完全是事务性的。如果数据库更新或 MQSeries 排队操作失败，整个事务就必须回滚。

WebSphere Application Server 3.0 中的企业 bean 现在支持具有跨多个 DB2 数据源完全两阶段提交和回滚能力的多个并发事务。对其它数据源（例如 Oracle、MQSeries 和 CICS）的支持只具有一阶段提交能力。不必再为这类应用程序使用如 CICS、Encina 或 Tuxedo 之类的事务监视器。

应用程序要求对象级安全性同 HTML 和 JSP 文件、servlet 和客户机登录的安全性紧密集成

有些应用程序要求复杂的安全性限制。例如，基于保险的应用程序必须按照规章准则限制对病人数据的访问。

企 业 bean 现在允许任何企业 bean 或方法上的方法级安全性。创建用户和用户组并且要么给予要么拒绝它们对任何企业 bean 或方法的执行许可。此外，WebSphere Application Server 使您能够授权或拒绝用户组对 Web 资源（例如，JSP 和 HTML 文件）的访问，并且它通过底层安全性框架无缝地将用户 ID 从 Web 资源传递到企业 bean。

应用程序需要标准、可移植和基于组件的体系结构

许多应用程序开发人员迫切希望开发不依赖特定平台、供应商或应用程序服务器实现的应用程序。

EJB 体系结构是这一目标的理想选择。它是一种工业标准组件体系结构。在 WebSphere Application Server 中开发的企业 bean 经常部署在竞争者的应用程序服务器上，反之亦然。虽然还没有一个完全标准、可移植并且基于组件的体系结构，虽然利用先于标准化之前出现的一些特性通常更容 易、更快捷，但是使用企业 bean 却提供了最佳的长期优势。此外，有许多可以用来帮助应用程序开发人员的 EJB 标准的工具和优化实现。

应用程序需要多个服务器来处理吞吐量和可用性

应 用程序需要满足用户的需要。因此，应用程序开发人员需要一种编写可伸缩以满足使用需求的业务逻辑的方法，无论这意味着每天 24 小时、每周 7 天运行并且处理几百万并发用户的系统，还是只在营业时间运行并且处理几十个并发用户的系统。您必须获得可伸缩性又不牺牲开发或标准化的方便性。

WebSphere Application Server 3.0 中的 EJB 环境支持具有下列特性的这种类型的应用程序伸缩性和可用性：

• 对象高速缓存和合用：应用程序服务器自动在服务器级合用无状态会话 bean，这减少了花在对象创建和垃圾收集上的时间。结果，更多处理周期可以用来做实际的工作。
• 服 务器级的工作负载优化：WebSphere Application Server 支持 EJB 服务器群集管理。您可以创建跨节点的服务器组和模型（模型是服务器的抽象表示），您可以将模型克隆成多个 Java 虚拟机（Java Virtual Machines (JVM)）。克隆可以在群集中的任一台服务器机器上运行，单个服务器的多个克隆可以在单台机器上运行以利用多处理机体系结构。您也可以将克隆的集合作为 组管理，从而改善可用性，并且消除应用程序服务器中的单一故障点。
• 自动故障转移支持：因为可以使用几个克隆来处理请求，所以故障破坏吞吐量和可靠性的可能性就减小了。如果克隆分布于系统内的各个节点，即便是整个机器的故障也不会产生灾难性的后果。

您无需将这些特性特别地编程到您的应用程序中去。您可以不改变服务器端代码就可更改为 WebSphere Application Server 创建的 EJB 应用程序的大小。

虽 然 WebSphere Application Server 支持其它服务器端技术（如 Java Servlet 和 JSP 文件）的分布、克隆以及自动故障转移，但是这些面向表示的技术是充当企业 bean 的补充而不是竞争者。每当重要的是可用性和可伸缩性时，企业 bean 都应该是整体解决方案的一部分。

案例研究：到 EJB 环境的成功迁移

某金融机构的一组开发人员创建了一个基于 Java 和远程方法调用（RMI）技术的应用程序。他们的系统有以下体系结构：

	图 2：RMI 服务器体系结构

此外，开发人员包含了两个体系结构图中不可见的框架：

• 使用 Java 数据库连接（Java Database Connectivity (JDBC)）的数据库映射层。这一框架位于 RMI 服务器内，并且将 Oracle 表映射到 Java 类以及将 Java 类映射到 Oracle 表。
• 定制安全性框架。它对来自浏览器或应用程序客户机的用户进行认证，确定这些用户是否可以执行 RMI 调用和数据库调用。

由于该应用程序具有下列特征，因此它是到 EJB 环境的迁移的一个好的侯选者：

• 它有多个共享相同业务逻辑的客户机（基于浏览器和基于应用程序的客户机）
• 它使用事务
• 它需要与对象-关系映射
• 它需要方法级安全性

开发小组迅速重新设计应用程序以使用企业 bean，如图 3 中所示。

	图 3：新的基于 EJB 的体系结构

应 用程序开发人员用在 WebSphere Application Server 和 VisualAge for Java 中提供的实体 bean 容器管理的持久性（CMP）实现替换其数据库映射框架。他们还用基于 EJB 的安全性替换定制安全性框架，这使得他们能够维护方法级安全性，同时却极大地简化了代码。

总之，通过使用与实体 bean 一起部署的会话 bean 系统重新设计使网络流量最小化。

回页首

应被取代的方法

这一节描述了可为该最佳实践所用的应被取代的方法。对于满足向 EJB 环境迁移的任一标准的应用程序，不推荐使用这些方案。

将业务逻辑同公共因特网隔离的应被取代的方法

该最佳实践假定后端业务逻辑比表示逻辑更有价值。您仍然可以使用 图 1中 描绘的略加修改的体系结构。您必须将整个 WebSphere 安装（除 servlet 插件和可选的用于 servlet 的因特网 ORB 间协议（Internet Inter-ORB Protocol (IIOP)）重定向器之外）置于第二层防火墙之后。然而这降低了整体性能。

使多个客户机类型能够访问共享数据的应被取代的方法

您 可以使用与企业 bean 不同的技术来使多个客户机类型能够访问共享数据。例如，Java 应用程序客户机和浏览器客户机可以通过 HTTP 访问 Java servlet。然而，如果 servlet 用于在浏览器中显示信息，则强制它包含一些表示逻辑，而向另一个程序传输信息时并不需要它们。结果，您有两套部分重叠的 servlet 用来处理这两种情形。

此外，对于程序到程序通信，HTTP 可能是低效的。您必须在程序之间沿 HTTP 管道传送信息，通常要么以类似 XML 的基于文本的格式要么以类似 Java 序列化的面向对象格式来传送。两种选项都涉及大量的编程工作，并且二者都没有和使用本机 IIOP 一样快。

对多个数据源提供事务性访问的应被取代的方法

您 可以使用与企业 bean 不同的技术来创建需要对多个数据源进行完全事务性访问的应用程序。您可以使用事务处理软件（例如 CICS、Encina 或 Tuxedo）来编写这类应用程序。然而，这些软件产品使用非标准接口，并且通常需要您用例如 COBOL、C 或 C++ 之类的语言来编写应用程序。

案例研究：EJB 环境的不成功使用

一组以评估新技术为任务的开发人员设计了一个使用企业 bean 的应用程序。图 4 说明了系统体系结构。

	图 4：蹩脚的基于 EJB 的体系结构

虽然企业 bean 似乎是项目的最好选择，但是比起本文档中描述的标准，下面的体系结构性细节表明并非如此：

• 应用程序的目的是为了通过 Java servlet 显示信息。企业 bean 仅仅用来检索和更新数据。
• 没有到后端大型机事务的符合 XA 的连接。因此，事务不能以组的形式回滚或提交。每次访问大型机都需要单独的函数调用。
• 应用程序不使用由企业 bean 提供的安全性框架。项目小组不能在通过浏览器客户机访问应用程序的用户和大型机环境内的用户之间创建映射。
• 每次 servlet 访问实体 bean 时，都需要一个网络调用。查找程序方法内的逻辑和 ejbLoad() 方法执行实际的大型机调用，但是从更进一步的意义来说，企业 bean 仅仅充当了数据高速缓存。提交事务时， ejbStore() 方法将信息写回大型机。这一过程需要实质性的网络开销。

总之，这一应用程序只不过将企业 bean 用作 servlet 和大型机中存储的数据之间的一种数据映射机制。这一应用程序没有利用任何 EJB 环境的下列特性：

• 企业 bean 的事务性本质
• 企业 bean 提供的方法级安全性
• 企业 bean 的伸缩和分布能力（这一应用程序只有一个 EJB 服务器）
• 在多个客户机和不同客户机类型之间共享业务逻辑的能力
• 由具有 CMP 的企业 bean 提供的自动数据映射能力

企业 bean 的使用极为显著地降低了系统的速度。可以通过直接将数据映射编码成在与 Java servlet 相同的 JVM 中运行的 JavaBeans 来改进性能。

另外，企业 bean 的使用给应用程序添加了不必要的复杂性。它需要宿主和远程接口以及分布代码。