从 EJB 2 容器管理的持久性迁移至 IBM Master Data Management Server 的 pureQuery

核心提示：背景知识在 2007 年，IBM Master Data Management 小组正在计划 WebSphere® Customer Center 产品的一个重要的新发行版，从 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）处理事务级逻辑，可能调用一个或多个用于组件级逻辑的业务组件。

业务组件 处理组件级逻辑，并且可用于创建不同的事务。

持久层（Direct JDBC） 由业务组件为执行 CRUD 操作而调用。

查询参数通过不同的代码层传递到 BObjQuery。 对于不同的业务组件，BObjQuery 类有不同的实现。 BObjQuery 调用一个公共的 SQLQuery 类来获得一个 SQL ResultSet。该 ResultSet 被传递到 ResultSetProcessor，用来创建业务对象。每个业务组件都有一个特定的 ResultSetProcessor 实现。

WebSphere Customer Center 持久性机制的问题

我们的产品使用前面描述的持久性机制已有数年，它们工作得很好。我们可以扩展 WebSphere Customer Center 应用程序，从而满足大规模的用户、事务和数据量，并为我们的客户机提供很多扩展机制。然而，随着时间的推移，我们也遇到一些缺点，希望您对此有所了解。

EJB2 CMP 实体 bean 的问题

下面是我们发现的 CMP 实体 bean 的问题：

CMP 只能解决我们的部分 ORM 需要。实体 bean 不仅仅是传统 Java 对象（POJO），不能到处传递，所以我们创建了自己的实体对象。这迫使我们手动地在 CMP 实体 bean 与我们自己的实体对象之间来回移动属性值。

如前所述，CMP 中用过的 ORM 不能在 JDBC 查询中重用。CMP 中的 ORM 生成 CMP 实体 bean 与表之间的映射代码。由于不能将 CMP 实体 bean 当作 POJO 来对待，因此在 JDBC 查询中这种映射没有用处。

即使借助 IDE，CMP 开发仍然相当复杂。仅仅对于一个 CMP 实体 bean，就需要创建 6 个类：Local Home、Remote Home、Remote Interface、Local Interface、Key Class 和 Bean Class。此外，还需要有 EJB 实体 bean 部署描述符和一个映射文件及数据库模式。即使是简单地调用 CMP 实体 bean 也涉及到很多步骤。例如，对于一个更新操作，需要获得 JNDI 上下文，查找 EJB home，发现 EJB 实体 bean 并更新这个 bean。

CMP 实体 bean 依赖于 J2EE 服务器。不同的服务器需要一套不同的部署代码和部署描述符。这些都需要在代码维护和产品分发中投入额外的工作。

直接 JDBC 调用的问题

当编写 JDBC 查询时，ORM 依赖于手动编程。这样做很麻烦，容易出错，而且会降低开发的生产率。

将 JDBC 与 EJB2 CMP 相结合的问题

如果同时使用 JDBC 和 EJB2 CMP 访问数据库，那么当在一个事务中同时执行更新和查询时会发生数据同步问题。在一个事务中，通过 EJB2 CMP 实体 bean 的更新直到事务结束才会被发送到数据库中，这意味着更新的数据对于同一个事务中随后的 JDBC 查询是不可见的。

性能问题

下面是我们在现有的持久性机制中遇到的性能问题列表：

CMP EJB 查询在查询场景中不能执行，这正是我们为查询使用直接 JDBC 调用的原因。

CMP 实体 bean 更新效率不高，因为它需要在数据库中进行读取和更新。这是因为 CMP 实体 bean 是由容器管理的。

对实体 bean 使用容器管理会生成很多代码。这对于将关系层与对象层分离是必需的，但这种便利是以牺牲性能为代价获得的。在我们的编程模型中，将为复杂的本地 SQL 处理关系层，而不必对程序员隐藏 SQL。这使得实体管理对于我们基本上没有用处。

技术路线图问题

现在是时候对我们使用的技术路线图作一个评估了。我们发现一些缺陷，这使我们不得不重新思考我们的持久性机制。

我们正在计划使用 XML 数据类型，它不是一种标准的 JDBC SQL 类型。 我们的产品可以在 DB2 和 Oracle 上运行，它们以不同的方式解释 XML 数据类型。这意味着对于每种数据库，我们将修改基本的 CRUD SQL 语句。然而，CMP 实体 bean 生成的基本 CRUD SQL 语句是不能修改的，这使得我们不可能采用 XML 数据类型。

EJB2/CMP 在 JEE5 中已被弃用，并且被 EJB3/Java Persistence API（JPA）替代。EJB3/JPA 被设计用来简化开发，并为复杂的查询场景提供更大的灵活性。EJB3/JPA 仍然基于实体管理的概念。

对新的持久性机制的期待

基于我们遇到的问题和未来计划，我们将需要一种新的持久性机制。下面列出了我们对于持久性机制的要求：

只需简单的对象到关系的映射功能，特别是：

Java bean 属性名到表列名的映射，而不是实体关系或继承的映射

超类映射支持；超类中定义的属性到列的映射应该可用于它的子类。但是，超类本身不映射到表。这是为了避免用于很多常见的属性和列的映射。

用于基本实体 CRUD 操作的 SQL 生成

用于在插入、更新和删除前后处理一些逻辑的实体生命周期事件回调

所有生成的代码应该可以移植到不同的应用服务器上。

实现持久性机制的开发过程可以很容易地降低与升级相关的开发成本。这包括对于可以处理 “自下而上” 和 “中间会合” 方法的开发工具的支持。

“自下而上” 方法假设已经有数据库表模式，而需要根据表模式开发一个对象层和对象关系映射。

“中间会合” 方法则假设已经有数据库表模式和一个对象层，而需要开发两者之间的一个 ORM。

可扩展性和灵活性，包括使用 SQL 所有功能和更改生成的 SQL CRUD 语句的能力。

与现有的持久性机制相比，我们选择的持久性机制必须执行良好。

可以顺利地迁移已有代码。

客户机可以用更多的实体和属性扩展我们的产品，并且该机制与客户机已有代码是向后兼容的。

该技术必须匹配下一版本产品的交付进度，并且采用它的风险必须降到最小。

该技术需要具有强大的技术路线图，并且与我们的方向保持一致，可以为我们提供优势。此外，该技术必须至少 5 年内可用。

受管持久性与 pureQuery 的比较

清楚了新持久性机制的所有期望之后，我们调查了 3 种持久性机制，并对它们作了比较：1）现有的持久性机制 —— EJB2 CMP，2）EJB3/JPA，3）pureQuery。EJB2/CMP 和 EJB3/JPA 是受管的持久性解决方案，而 pureQuery 不是。表 1 根据我们的需求对这些技术作了评价。

表 1. 持久性机制比较

	EJB 2/CMP（没有改变）	EJB3/JPA	pureQuery
简单的 O/R 映射	半支持	完全支持 POJO 风格	完全支持 POJO 风格
易于开发/在不同的应用服务器上运行	复杂 在不同的应用服务器上，对于不同的 CMP 实现有不同的生成代码	简单 在不同的应用服务器上，对于不同的 JPA 实现有不同的生成代码	简单 Java 编辑器中集成的 SQL 辅助功能。对于不同的应用服务器使用单一的代码生成
灵活性和可扩展性	生成的 CRUD SQL 不能更改	生成的 INSERT SQL 不能更改	生成的 CRUD SQL 可以更改
性能	基准 使用 CMP 的查询不能很好地执行 对于实体更新场景需要执行读和更新操作 需要额外的成本管理实体	较好 可以使用 JPA 查询 API 执行查询 对于实体更新场景需要执行读和更新操作 需要额外的成本管理实体	最好 查询 API 或方法风格的查询执行得较好 对于实体更新场景只需执行更新 没有实体管理，可以减少成本
迁移和向后兼容性	没有迁移，这是我们的起点	需要迁移。应该基于 JEE 规范向后兼容	需要迁移。应该基于设计向后兼容
技术可用性	可用	可用	可用（但我们使用的是预发布代码）
技术路线	不推荐使用	由 JCP 掌控路线图和方向 新特性的采用速度可能较慢	具有与 IBM 持久性战略一致的清晰的路线图 可快速添加或采用新特性
风险	如果应用服务器停止支持，则在未来会产生很高的成本。实体管理会导致潜在的性能问题	实体管理会导致潜在的性能问题	风险最小

做出决定并开发一个执行计划

显然，对于我们的编程模型，受管持久性解决方案不是必需的，我们希望释放出 SQL 的威力，而不是对开发人员隐藏它。对于我们来说，实体管理增加了一层不必要的开销，并且对性能有负面的影响。

鉴于 Data Studio Developer 工具提供的对 SQL 开发的帮助，以及对以数据为中心的开发的关注，pureQuery 成为我们最自然的选择。为了支持我们的持久性机制决策，我们制定了一个计划，以便在以下方面证明该技术：

确定 pureQuery 开发和交付环境

调查编程模型

调查用于产品交付的软件平台

调查用于产品开发的软件平台

调查用于对象到关系映射的开发工具

调查乐观控制实现

估计将 CMP 和直接 JDBC 调用迁移至 pureQuery 的工作量

调查如何迁移已有的 WebSphere Customer Center EJB CMP bean

调查如何迁移已有的直接 JDBC 调用

执行功能测试，消除对向后兼容性的担心

调查 pureQuery 与 EJB2/CMP 和直接 JDBC 调用的共存性

调查 Global Transaction（XA）的支持

执行基准测试，消除对性能的担忧，并确保新机制的性能好于现有的机制

致谢

我们要感谢 pureQuery 开发小组，他们对我们的初始调查和本文的审校工作提供了帮助。

结束语

本文对 InfoSphere Master Data Management Server 和 Data Studio Developer/pureQuery 作了概述，然后深入研究了 WebSphere Customer Center 在之前使用的持久性机制。本文还列出了与持久性机制有关的一些问题，以便实现改进。根据我们对持久性机制的期望，我们对 EJB2/CMP、EJB3/JPA 和 pureQuery 作了一个比较。最后，pureQuery 脱颖而出成了我们的选择，我们还开发了一个执行计划，以便进一步验证我们的决定。

在本文的第 2 部分，我们将详细讨论技术验证的结果，包括将实体 bean 迁移至 pureQuery 时开发人员的生产率、查询和 CRUD 操作的性能结果以及事务一致性。我们还将提供一些经验教训，如果您决定着手一个类似的项目，这些经验教训可能会提供帮助。