从 EJB 2 容器管理的持久性迁移至 IBM Master Data Management Server 的 pureQuery
背景知识
在 2007 年，IBM Master Data Management 小组正在计划 WebSphere® Customer Center 产品的一个重要的新发行版，新发行版将更名为 IBM InfoSphere Master Data Management Server。这个小组在架构方面必须做出的一个关键决策是，如何对待现有的持久性机制，该机制基于 Enterprise JavaBeans（EJB）2 容器管理持久性（container-managed persistence，CMP）实体 bean 和本地 JDBC 调用，并且正逐渐过时。这个包含两部分的系列描述如何以及为何作出使用 pureQuery 技术的决定；我们实现和迁移至 pureQuery 的计划；最后，介绍为了验证这一决定而进行的性能和功能测试的结果。
InfoSphere Master Data Management Server 概述
IBM InfoSphere Master Data Management（MDM）Server 管理在组织内驱动最重要的业务流程的主数据实体（即客户、帐户和产品）。IBM 提供了一个全面的 MDM 解决方案，该解决方案拥有可为所有主数据管理方法服务的高度即开即用的功能。使用 MDM Server，组织可以将最关键的数据集中到单个受信任的源 —— 使他们可以识别最有价值的客户，增加收益并降低成本。这种功能使他们可以从已有的系统中获取更大的价值，提高客户满意度，并快速发现新的市场。
主数据通常有很多用途（运营系统、数据仓库、业务流程、数据治理等），不同用途有不同的需求。但是，对于 MDM 系统，这些用途却有一些共同的关键需求。这种系统有如下需求：
提供一个统一的多域（参与方、帐户、产品)主数据库 —— 知识层。
提供 SOA 业务服务，用于操纵和查询这种数据
管理数据的质量和正确性
提供智能的、前摄性的业务逻辑，使 MDM 积极参与到数据生命周期中
提供数据治理功能，实现并审计事务和数据访问安全
下面的 MDM 产品概览说明了这些需求是如何被满足的：
图 1. MDM 产品概览
实际上，IBM InfoSphere MDM Server 是一个 SOA 应用程序，具有一套丰富的预定义业务服务，用于维护它的数据库中的主数据（或主数据引用）。例如，MDM 服务器接受一个 XML 格式的对更新的请求，并将它解析成对象形式；接下来检查它的安全性；验证、标准化和复制它的内容；然后通过一个持久层应用更改。持久层是本文的关注点。
IBM InfoSphere Master Data Management Server 是 IBM WebSphere Customer Center 的后继者。它对 WebSphere Customer Center 的功能进行了增强，具有附加的主数据域 Account 和 Product。因此，当本文提到 WebSphere Customer Center 时，是指之前的架构，而当提到 MDM Server 时，是指新的架构。
Data Studio Developer 和 pureQuery 概述
IBM Data Studio 产品组合提供了一个集成的、模块化的数据管理环境，该环境可以跨整个数据管理生命周期设计、开发、部署和管理数据、数据库和数据驱动的应用程序。本文的焦点是 Data Studio Developer 和 Data Studio pureQuery Runtime 中提供的 pureQuery 技术。pureQuery 是一项高性能的 Java™ 数据访问技术，构建在 JDBC 之上，它使开发和部署数据库应用程序和服务变得更容易。pureQuery 在 Java 和数据库之间搭起一座桥梁，而要连结这两个领域，需要解决大量性能和生产率问题。
编写直接的 JDBC 可能非常冗长乏味。此外，成为一名 JDBC 和 SQL 专家的确有助于确保 JDBC 数据访问的高效性。为获得最佳性能，开发人员必须掌握 JDBC API，并利用诸如批处理和结果优化之类的特性。实际上，必须使用大量代码才能编写一个使用 JDBC 的简单查询。
冗长乏味的 JDBC 开发导致对象关系映射（ORM）框架的诞生，该框架提供一个数据访问抽象层。ORM 通常需要更少的初始工作就能创建数据访问层。然而，在诊断运行时性能问题时，这些框架会增加开销和额外的复杂性。调优和诊断变得更加困难，因为开发人员再也不能控制发送到数据库的 SQL；因此，很难更改 SQL 或者确定是哪个应用程序发出它。IBM 创建了 pureQuery，可以为 Java 数据访问开发解决这些问题和其他问题。pureQuery 引入了一个新的 API，它是用于 Java 开发人员的一个简单而直观的 API，通过它可以预览针对 JDBC 标准化而考虑实现的功能。而且，pureQuery 使您可以在 Java 集合和数据库缓存中利用 SQL 的威力。
pureQuery 工具简化了大多数常见的任务，包括存储和检索 bean 以及与数据库之间的来回映射等即开即用支持。SQL 是完全可定制的，所以没什么值得惊奇的。而它又是可扩展的，这意味着可以插入定制结果（custom-result）处理模式。扩展的 Java 编辑器包括一个集成的 SQL 编辑器，它为开发人员提供了与 Java 相同级别的用于 SQL 的代码完成、验证和执行辅助。它为使用 Java 和 SQL 最佳实践提供了便利。
DB2 中 pureQuery 编程的一个关键标志是使用单个 API 进行编程以及使用 SQL 的静态或动态执行进行部署的能力。在 DB2 数据库中使用静态 SQL 早已被公认为可以提高性能、稳定性和安全性，但是在过去需要专门化的编程才能利用它。虽然我们还没有用过这个功能，但是我们清楚它的优点，在将来的增强中我们会加以考虑。
在一个即将到来的发行版中，pureQuery 还将使管理员或开发人员能够跟踪 SQL 回到初始的应用程序，从而缩短问题判别时间和帮助进行影响分析。
参考资料 小节包括很多文章，在这些文章中可以学到更多关于 pureQuery 和 Data Studio Developer 的知识。
IBM pureQuery 不是一个成熟的持久层。它没有提供受管对象支持。如果需要一个成熟的持久层和/或受管对象支持，那么很可能需要使用像 openJPA 之类的东西。在一个即将到来的发行版中，pureQuery 有望向所有 Java 应用程序（而不仅仅是用 pureQuery API 编写的应用程序）实现它的众多优点。
WebSphere Customer Center 之前使用的持久性机制
WebSphere Customer Center 中使用了两种持久性机制。由于使用 EJB2 查询存在性能问题，我们很早就决定对于查询操作使用直接 JDBC 调用，而对于创建、检索、更新和删除（CRUD）操作则使用 EJB2 CMP。
EJB2 CMP 实体 bean 中的 ORM 层向对象操作隐藏了 JDBC 操作的细节。这个层还帮助生成用于检索、更改和持久表记录的适当的 SQL 语句。对于我们来说，这个 ORM 层是简单的、轻量级的，因为我们不需要它的所有特性：
它只映射 CMP 实体 bean 与一个表之间的一对一的关系。
它不将表关系映射到 CMP 实体 bean 关系。
它不将表继承映射到 CMP 实体 bean 继承。
在将一条记录插入到一个表中和对它进行更新之前，我们使用 EJB2 CMP 实体 bean 生命周期事件。
在插入记录之前，使用 ejbCreate 方法设置主键。
在更新记录之前，我们通过实体对象方法 set 使用了乐观并发控制。
在插入或更新记录之前，设置常见实体字段的逻辑出现在 ejbCreate 和 set 实体对象方法中。
如前所述，对于复杂的查询操作，我们使用了直接 JDBC 调用，从而避免 EJB2 查询中的性能开销。不幸的是，我们因此不能重用在 EJB2 CMP ORM 中使用的代码，所以我们需要手动地编写用于 JDBC 查询的对象关系映射。
WebSphere Customer Center 中 CMP 实体 bean 的架构视图
图 2 显示了 WebSphere Customer Center 中用于 CRUD 操作的使用 CMP 实体 bean 的持久性机制的架构视图。
图 2. Add/Update/Delete 服务中的 CMP 实体 bean
WebSphere Customer Center 是一个 J2EE 应用程序，在一个应用服务器中运行。它有以下 4 个层（图中从左到右排列）：
请求框架（Request framework）操纵和转换请求和响应消息。
Tx 控制器（Tx controller）处理事务级逻辑，可能调用一个或多个用于组件级逻辑的业务组件。
业务组件（Business component）处理组件级逻辑，并且可用于创建不同的事务。
持久层（CMP 实体 bean）由业务组件为执行 CRUD 操作而调用。
首先在业务组件层从业务对象（BObj）中获取实体对象（EObj），然后将它发送到持久层（CMP 实体 bean），执行 CRUD 操作。从持久层返回后，再次使用业务对象包装实体对象（EObj）。实体对象与表之间有一对一的映射，是用于在持久层和业务组件层之间传递数据的传送对象。
WebSphere Customer Center 中的直接 JDBC 调用的架构视图
图 3 是用于查询操作的持久性机制的架构视图，该机制使用 WebSphere Customer Center 中的 JDBC 调用。代码层与 图 2 显示的一样，只是持久层受到我们自己的框架代码的支持，可以执行直接 JDBC 调用。
图 3. 查询服务中的直接 JDBC 调用
请求框架 操纵和转换请求和响应消息。
finder 控制器（finder controller）处理事务级逻辑，可能调用一个或多个用于组件级逻辑的业务组件。
业务组件