odi数据服务中文

在 SOA 中使用 ODI 套件实 现企业数据服务
Oracle 白皮书 2008 年 1 月

在面向服务体系结构中使用 Oracle 数据集 成套件实现企业数据服务
概述
随着业界对面向服务体系结构 (SOA) 构想的关注，人们有时会忘记 SOA 在很大程度上类似于管道工程，其大部分业务价值直接源自其输送的数 据。 今天，由业务智能、数据仓库和主数据管理构成的数据体系在很大程度上 仍然游离于新兴的 SOA 构想之外。但是，企业层面的数据服务可以将这 些数据和 SOA 体系有效整合到一起。 如果设计合理且执行得当，数据服务可以提供连接传统数据系统与新兴 SOA 范例的纽带，而这正是现在所缺少的。通过提供分离的数据外观和易 于虚拟化的 API，数据服务可以让 SOA 能够建立系统控制 — 无需总是 强制企业数据通过低效的 XML 层。 本白皮书将通过介绍企业如何依赖宝贵、复杂的业务数据说明为什么数据 服务是企业 SOA 部署的基本要求。此外，还将介绍一个使用 Oracle 数 据集成套件的企业级数据服务解决方案。该套件是市面上唯一基于 SOA 的数据服务平台，它充分整合了 SOA 和单项最佳的传统数据管理工具的 优势。
第 1 部分：数据的首要地位
一直以来，数据都很重要。几十年来，有关 EAI、ETL、MDM 和 SOA 的争论都得出了相同的结论 — 数据至关重要。如果说内容是用户 Web 的王者，那么数据就是企业软件的至尊。 而有时企业软件部门却看不到这个简单的事实。.在过去的十五年间，随着 Java 的兴起、围绕 EII、EAI 和 SOA 的大肆宣传、XML 的迅速走红以 及默默地在 ETL 项目上投入数十亿 — 一切都是这么简单，以至于我们 忘了为什么要构建和购买这些基础架构。我们这么做是为了数据。 如果没有数据，也就不需要过程编排了。所有的 SOAP 信封将没有任何用 处，所有的服务总线将没有任何东西可以发布，应用服务器将没有任何东 西可以提供。因此说，数据至上。
在 SOA 中实现企业数据服务的案例
第 2 页

但是，数据也带来了很多不容回避的重要问题。首先，企业已经知道如何 收集更多的数据，但却无法有效地理解所有数据。第二，随着数据的增 多，基础架构和工具为有效地管理数据而变得拥挤不堪。第三，在小型基 础架构中用于定义数据的方法无法扩展以解决大型业务问题。最后，企业 架构师往往沉迷于新技术而忘记了三十年艰苦斗争获得的数据管理经验仍 然适用。 自 2000 年以来产生的数据比在此之前人类有史以来产生数据的总量还要 多。
图 1：信息爆炸（自适应信息，Wiley & Sons，2004 年）
对企业和政府来说，传感器的出现意味着我们可以实时监视任何事物：从 发运点到工厂温度或您自己的心率。所有这些数据都会汇集于某个地方。 它们被无限期地存储下来，用于实时信息板、历史分析或存在某个地方备 用。但是，现在我们的数据收集速度要快于数据解析速度。数据收集的速 度、对诸如 RFID 传感器和其他监视器的使用呈指数级增长。换言之，数 据问题越发严峻。 但令人惊奇的是，自上世纪 90 年代以来，企业的基础架构一直没有改 变。那时，消息队列 (MQ)、事务处理系统 (TPS) 和 ETL 工具是企业软 件的主干。您猜怎么着？现在它们依然是。虽然 BPM、SOA、ESB 和 EII 的采用率有所增加，但是 MQ、TPS 和 ETL 主干依然存在。 所有新增数据的压力和对成熟工具的需求荒谬地使现存成熟的软件基础架 构看起来颇具吸引力。许多新系统都试图将所有的数据转换为 XML 或使 用 Java Entity Bean 作为数据管理层。这两种方法对小型应用程序或特定 情形是可取的，但它们的扩展能力还不足以解决全球 2000 强企业经常遇 到的数 TB 大小的问题。因此，有经验的架构师会重新使用成熟的 RDBMS 模式作为以 MQ、TPS 和 ETL 接口为输送所有数据的管道的数 据体系结构的主干。 但是 SOA 热潮正在减弱。为什么不使用 SOA 作为以数据为中心的体系 结构呢？
在 SOA 中实现企业数据服务的案例
第 3 页

第 1 部分：SOA 在以数据为中心的体系结构中的角色？
回到 2001 年，当面向服务体系结构的狂潮开始蔓延的时候，我们觉得它 很神奇。还记得动态发现的承诺吗？人类可读的信息？简单的 XML 数据 对象？但是问题很快就出现了：不同的供应商规范、安全漏洞、性能问题 等等。 2008 年有了好消息 — SOA 终于发展为企业级基础架构。与最初解决所 有集成问题的期望相去甚远的是，SOA 的主要工具（企业服务总线和业 务流程引擎）还差那么一点才能真正取代 MQ 和 TPS 系统的长期统治 地位。基础 SOA 的可靠性和性能均已足够强大，几乎可以解决所有问 题。但 SOA 仍不是 ETL 和数据集成的最佳选择。 数据集成的情况有时很简单，有时却是不可能的。对于简单的情况，如转 换少量数据并将其存放到某处，基于 XSLT 的转换服务运行于服务总线之 上的普通 SOA 通常就可以应付。这种方式在数据格式为 XML 时很有帮 助，这是因为只是为了将数据转换为某种其他非 XML 格式而将数据转换 为 XML 并不是最佳选择，因此对这些简单的以 XML 为中心的数据集成 情形，SOA 很适合。 但数据集成的一般使用情形都超出了 SOA 的核心能力所能应付的范围。 一般使用情形可能需要将几 GB 的数据从一个数据库载入另一个数据库， 将数据形状从第三范式 (3NF) 转换为多维（星型）模型。此一般使用情 形用来支持业务线的需求，如：报表生成、业务智能、性能管理、财务规 划以及其他分析功能。因为批量数据转换性能和效率较低，所以 SOA 极 不适用于该一般使用情形。 几乎所有的 SOA 框架都运行在 Java 容器中，当需要将数 GB 的数据 输入 Java 虚拟机时这就成了极大的劣势。同样，SOA 处理数据的范例 是 XML － 几乎所有的 SOA 框架都要求将数据转换成 XML 以进行编 排和转换。但是，1 TB 的数据仅因为增加的标签、模式和尖括号就会增 大为 5 或 10 TB 的 XML 数据。（见图 2） 即便如此，XML 仍然是最好的文档和消息格式。SOA 的热潮曾经使人误 以为 XML 是一种数据语言，其实它不是。作为 SGML 的简化形式， XML 只是为了提供一个结构良好的标记文档和消息标准方法。实际上， XML 和 XSD 的核心模型称为 Infoset，它是一个用来定义可用 XML 项 目类型的树形结构。但是，XML Infoset 与关系数据模型和图数据模型不 同，它不是数据模型。这就是为什么纯 XML 数据库非常少且几乎在技术 上不宜用作一般数据管理的原因。
在 SOA 中实现企业数据服务的案例
第 4 页

图 2：使用 XML 标记批量添加数据
事实上，SOA 数据服务的任何早期定义都无法真正扩展到解决企业级问 题。主要从 JDO、SDO、DAS、DTO 等众多标准演化而来的 Java 定 义实际上是 (a) 试图定义 Java 与关系数据交互的模式和 (b) 将在应用 程序和 Java 容器间移动这些对象或组件的 API 标准化。但是，很少有 企业解决方案将联合使用容器的 Java 对象作为企业数据集成或联合的主 要方法。 其他早期的 SOA 数据服务定义是面向 XML 的数据服务视图，由基于 XSD 的数据交换规范模型决定。此方法提倡对规范消息格式使用基于 XSLT 的映射，而在某些情况下使用 XQuery 和 Xpath（或 SQL），以 在不同的数据源间联合查询。但是，如前所述，XML 是较差的数据模 型，而且效率又低，因此联合查询方法仅适用于高度优化的缓存。
图 3：数据服务的常规 Java/XML 视图
简单而残酷的现实是企业数据要求苛刻，将只有 SOA 的解决方案用 于所有企业数据可能只是梦想而已。 企业数据要求过于复杂，又受到业务智能系统的高容量、多维度特性的过 度驱动，因此无法单从信息层提供整套服务。另外，企业数据服务的宝贵 模式和教训实际上在 SOA 出现之前已经存在，并可以与 SOA 基础架构 本身和谐共存或与之完全独立。
在 SOA 中实现企业数据服务的案例
第 5 页

那么，假设从 SOA 分离数据服务，那 SOA 将如何处理它们呢？
第 2 部分：什么是 SOA 数据服务？
虽然 SOA 无法进入数据管理的基础，但是越来越多的证据表明，使用新 部署的 SOA 基础架构来协调企业数据服务可能会带来很多新好处。这些 好处并非来自对传统数据管理系统的替换，而是来自将 SOA 用作传统数 据管理系统的一个控制点。因此，SOA 数据服务不仅可以处理 XML，也 是为处理各种类型的数据提供高度优化的引擎的企业数据管理端点。 数据服务本身并不需要使用 SOA 就可以称为服务。事实上，所有关键数 据服务属性，包括基于合约的开发、数据封装和声明式 API 的使用均早于 SOA 相当长时间。 数据服务的定义因人而异，但可以肯定的是，在上世纪 60 年代，随着 EDI（电子数据交换）服务在金融机构间的使用，数据服务已经成为软件基 础架构不可或缺的一部分。随后，在上世纪 80 年代，面向对象的设计原 则使得关键数据服务模式得到广泛应用。最近，用 Java 编写的数据服务 实际上要比 SOA 数据服务理念早几年。 从技术上说，数据服务应该具有以下属性中的几种：
z
基于合约的绑定 — 用于按合约设计，例如 WSDL/SCA 数据封装 — 仅通过 API 间接访问数据 声明式 API — 除常规绑定之外的某种可查询 API 分离的绑定元数据 — API 描述符本身就是模型的一部分 分离的数据模式元数据 — 数据模式从 API 分离出来
z
z
z
z
但是，数据服务的理念更像是一种理想。数据服务追求这样一种理想状 态：一个共享的控制点来控制所有重要的业务数据。数据服务应该为数据 提供便于访问、发布和发现的控制点。因此，从根本上说，数据服务可以 只是一个老套的东西 — 一个标签或标记 — 用于标记特定软件组件的存 在意义。 遗憾的是，市场推广的力量已经让人们普遍认为数据服务对于真正的企业 工作来说过于浅显和狭隘。首先，有人认为短视地认为数据服务只是提供 企业信息集成 (EII) 式的联合查询。一些小的供应商认定 EII 本身可以提 供数据服务作为联合查询和基于 XQuery 或 SQL 的数据视图。但是，这 些基于缓存的传输机制实际上相当于一个数据平台，而集中星型 (hub-andspoke) 数据平台是一种很老式的平台。事实上，在实践中很少会要求用真 正的（非基于缓存的）查询联合，只是要求使用实际数据服务的一个很小 方面。
在 SOA 中实现企业数据服务的案例
第 6 页

另一个有时与 EII 构想一同推销的流行理念是数据服务的规范 XML 模 式。如前所述，我们知道，虽然基于 XML 的数据模型有一定的价值，但却 无法替代真正的数据模型，只能在某些类型的事务处理中作临时的数据表示 方法。 从整体上考虑并着眼于企业的规模问题，数据服务可以有几种不同的数据传 输方式。太多的 SOA 权威人士认为 XML 是唯一可取的数据交付格式， 但是一个数据解决方案要想真正地应用于企业，就必须支持多种不同的传输 方式。数据传输只是软件客户端为数据提供服务的方式。
图 4：数据传输模式、功能性服务和拓扑
以下是一些处理数据的典型的数据传输模式：
z
RPC 方式传输（远程调用）— 大多数传输方式的基础。基本传输模式 只建议对远程过程的调用应该返回一些数据。某些情况下调用本身可以 包含声明式查询，如 SQL。 基于事件的传输（发布/订阅）— 这可以是传统 SOA 企业服务总线类 型的传输，也可能是低级更改数据捕获类型的发布和订阅模式。 基于流程的传输（通过 BPEL 的事务处理）— 这种传输方式可能涉及 到长期存在且步骤繁多的事务处理，其逻辑相对复杂，如事务处理报 酬、回拨和连接到普通业务规则库的钩子。 对象传输（通过封装的对象）— 这是软件应用程序处理数据对象的常 见方法，如内存中封装的 Java、C++ 或 C 对象。现代的 JVM、 J2EE 和 .NET 缓存允许 100 台机器和数 TB 的 RAM 共享对象 池。 批量方式传输（低级） — 通常通过常规 API 进行访问和命令执行， 实际的数据处理在低级别完成，有时通过批量加载程序、内部协议和/或 JDBC 直接推送到 DBMS，还可以从 DBMS 事务处理日志查看事务 处理。
z
z
z
z
在 SOA 中实现企业数据服务的案例
第 7 页

总的说来，这些基本的模式代表了软件应用程序通常与数据服务进行交互的 不同方式。有时，它们很简单，只是通过 JDBC 等某种协议上的 RPC 方 式的调用来将 SQL 查询发送到监听器服务。而有时，它们相当复杂，如触 发一个从多源卸载数据的低级过程，以组为单位合并数据，最后装载业务智 能 OLAP 多维数据集。无论哪种情形，数据服务的作用始终是简化应用程 序处理数据的操作。 需要数据的客户端软件应用程序可以使用上面提到的任何一种数据传输方 式，但是具体使用它们做什么呢？ 从功能上来讲，有几种企业数据服务的特性已逐渐成为中型及大型面向服 务体系结构的基础数据服务。
第 3 部分：企业 SOA 的功能性数据服务
一方面，数据服务只是一个程式化的东西，特定的服务应该是特定数据项 的公共参考点。另一方面，数据服务应该符合某些模式和传输方式才能真 正在数据分发和传输上实现企业级的服务级别协议 (SLA)。 通常，可以根据功能类型和服务目标来制定这些 SLA 。这些功能可以归 为几个类别来代表数据服务的一些典型功能点。但在实践中，实际的数据 服务的粒度可能比类别更细。例如，企业可能不会使用企业服务进行主数 据管理，而是部署一个带有受控 SLA 的客户 MDM 数据服务作为公共 参考点来分发和传输客户数据。同样，企业可能不会使用数据访问服务， 而是创建一个粒度细得多的税码数据访问服务作为企业 SOA 首次展示的 一部分。 一些典型的功能性数据服务模式可能包含以下几种： 主数据服务 — 这些数据服务关注对企业内高价值业务数据的完整生命周 期的管理。主数据管理 (MDM) 可能涉及数据记录和数据实例的管理或模 型属性和数据分类的管理。典型的 MDM 解决方案对变更数据值和数据 结构的管理具有很强的监管控制，经常执行多个级别的工作流并审批对可 信业务数据的修改。
z
动机：企业数据环境的复杂性使得难以找到或收集可信的、高质量的业 务数据、层级结构和数据策略。 用途：可以在实时 SOA 事务处理或批量数据移动过程中用作参考服 务，通常与转换一起应用。 变体：主数据平台、主数据缓存、主数据应用程序（客户数据集成、产 品信息管理、财务数据平台等） 参考：Oracle MDM、IBM、SAP、Kalido、Siperian 等 说明：常规的 MDM 提供商仍在向 SOA 体系结构过渡，只有极少数 跳过基础步骤通过 SOAP 和 WSDL API 来提供 MDM 服务。
z
z
z
z
在 SOA 中实现企业数据服务的案例
第 8 页

图 5：SOA 模式中的主数据
批量数据服务 — 这些数据服务提供批量数据移动和转换服务。通常，批量 数据服务通过向基于 SOA 的应用程序提供 Web 服务 API 来从 SOA 层 调用这些批量数据/ETL 方式的作业。一些已知的实施将这些批量数据服务 合并在一起作为 BPEL 或 ESB 事务处理过程的子过程，这样 ETL 作业 的控制点就在 SOA 层，但对有效批量数据处理的授权却在最适合的体系 结构层发生。
z
动机：ERP、数据仓库、业务智能和绩效管理应用程序需要批量数据移 动。 用途：可以用于复制、批量刷新、数据迁移、大文件转换和更改数据捕 获 变体：ETL（要求专用硬件）、E-LT（低成本、高性能，运行在 SOA 层）、等待时间短的 Logminer CDC 参考：参见 Oracle Data Integrator、DataStage 和 Informatica 说明：从 SOA 使用 ETL 时请小心，因为这会产生冗余硬件基础架构 和重复的 SOA 逻辑 — 查找可以真正运行在 SOA 层的内部 E-LT 实施。
z
z
z
z
在 SOA 中实现企业数据服务的案例
第 9 页

图 6：SOA 模式中的 ETL/批量数据
数据访问服务 — 利用这些数据服务可以通过受管理的（综合的或物理的） 视图直接查看数据的位置。数据访问服务可以简单得像从数据库获取数据的 Web 服务一样。数据访问服务也可以很复杂，如对综合数据视图发出查 询，并使服务通过聚合的数据结果集实时联合数据源查询。
z
动机：为消费型应用程序提供一个简化的查询接口。通常通过将共享的 抽象（规范模型）与实例虚拟化（数据混搭）组合在一起来实现。 用途：通常作为 J2EE/.NET 服务器层的一部分；在 SOAP 环境下， 在过程中添加了转换到 XML（通常是规范的）的额外步骤。 变体：查询联合、数据平台和 Spoke（对象|SQL|XQuery）、对象关 系映射（ORM via J2EE/Toplink 等） 参考：参见 Oracle 应用服务器、Oracle Data Integrator、BEA AquaLogic、Ipedo、Composite Software、Meta Matrix 和 IBM DB2ii 说明：此类别有很多技术变体，需要在成本/性能上仔细权衡。
z
z
z
z
图 7：通过 SOA 模式进行数据访问
数据网格服务 — 这些是由应用层直接使用的数据服务。数据网格服务通常 作为应用程序的类路径的一部分导入，对于该应用程序来说似乎是内部对象 池。在 Java 中，数据网格可能看起来像 POJO（普通旧式 Java 对 象），但每个对象来自不同计算机的 RAM 中的不同 JVM。数据网格服务 提供了超快的数据访问缓存。
在 SOA 中实现企业数据服务的案例
第 10 页

z
动机：由于地理因素，或为了克服单一主机的 RAM 容量限制，极为快 速的内存中数据需要频繁地用于多个应用程序。 用途：通常部署用于业务对象层上联合的有状态持久性，以在保持超快 性能的同时以可预计方式“向外扩展”应用程序 变体：Java、.Net、C++ 变体。对等集群和层级式集群、 UDP/TCP…… 参考：参见 Oracle Coherence、Gigaspaces、Gemstone 说明：数据网格服务不可替代持久性 (persistence)，它们通常结合关系 数据库使用来存储数据或保持对数据生命周期的准确控制。
z
z
z
z
图 8：临近缓存数据网格模式（带 SOA 端点）
数据质量服务 — 这些数据服务使用算法和预先定义的业务规则进行 清理、重新格式化和删除污染的重复业务数据。通常，这些服务以内 联方式结合其他数据服务使用（如：以内联方式结合批量数据/ETL 服务使用数据质量服务）或以静态方式在数据源上使用（如：清理原 有数据库）。但最近的更多应用表明，在 SOA 中管理数据质量服务 可以为 SOA 消息和数据提供迫切需要的清理和标准化服务。
z
动机：自动改善坏数据的质量，提升原有数据资源的价值和可用性。 用途：过去，批量使用来清理数据仓库和 BI 信息库；现在，用途正转 向实时和保护性措施，在数据变坏前清理数据。 变体：声明式/规则驱动、可能的或基于统计学习、域特定和面向内容 的数据质量 参考：参见 Oracle Data Integrator、Oracle Warehouse Builder、 Informatica 等。 说明：数据质量服务不是灵丹妙药，一般说来，种瓜得瓜、种豆得豆。 换句话说，需要在这些服务上花费时间来优化和调整业务规则。
z
z
z
z
在 SOA 中实现企业数据服务的案例
第 11 页

图 9：通过 SOA 模式确保数据质量
数据转换服务 — 这些是经典的数据服务，通常是导入一种格式，输出另 一种格式。以往在仅有 SOA 的环境中，将把这些服务部署为 XSLT 库。在这些库中消费型应用服务将送入一些数据，选择相应的 XSLT，再 以新格式接收数据。在更为成熟的 SOA 中，转换服务还可包括类似 ETL 的服务，这些服务专门用于有效转换批量数据 (10-100 MB) 负载。
z
动机：为 WSDL 驱动的数据转换提供可重用的服务，通常支持多种类 型的转换（如：RDB 至 RDB, XML 至 RDB、XML 至 XML、Flat 至 XML、Flat 至 RDB……） 用途：具有集中维护的服务的企业系统的最佳实践。 变体：XSLT Factory、ETL引擎、规范化中介服务（XSLT 或 ETL 驱 动） 参考：参见 Oracle 应用服务器、Oracle Data Integrator、Contivo Builder、Tibco Data Exchange、BEA Aqua Logic 等 说明：很少有全能型的转换服务 — 成熟的 SOA 可能有几个专门针对 不同格式的转换数据服务提供更为优化的 SLA。
z
z
z
z
图 10：转换数据服务模式 数据事件服务 — 这些数据服务监视、关联和传播在业务数据上发生 的事件。数据事件可能发生在中间件消息传递中、数据集成和基础架 构的数据层中。在一个成熟的 SOA 实施中，可以订阅数据事件，不 管该事件是发生在数据库、中间件或其他地方。
在 SOA 中实现企业数据服务的案例
第 12 页

z
动机：数据环境的每一部分必须能够捕获操作、检查策略并基于那些策 略采取措施。 用途：通常部署于给定的技术层上（如：在 Java 中，或在总线中，或 在数据库中），能够调用其他事件系统（如Java 事件触发器、SOA 触 发器、DB) 变体：EDA（事件驱动的体系结构）、CDC（更改数据捕获）、CEP （复杂事件处理器）、Java 事件监听器…… 参考：参见 Oracle 应用服务器、Oracle Data Integrator、Oracle 事件 驱动的体系结构套件、Tibco CEP。BEA 事件服务器 说明：数据事件服务是一个强大但是新推出的技术功能。到目前为止， 尚没有公共的策略定义标准或在任何给定软件层检测事件的标准框架。
z
z
z
z
图 11：数据事件服务模式 这些绝不是数据服务仅有的功能类别，实际的数据服务实例将比这里所述 的更有针对性。前述数据服务配置文件旨在对规划多层 SOA 部署策略的 架构师给予指导，这些策略可能包括一系列用于不同使用情况的不同数据 服务。 但由于众多的数据服务类型和部署它们的复杂度，典型的 SOA 要从哪里 开始呢？
第 4 部分：关于简单数据服务的实用建议
在前面的部分中，我们主要介绍了远景构想。.SOA 中的数据服务的理想状 态是一个很好的构想，但这使得许多人对数据服务的实际实施期待太多。 下面提供了数据服务的一些入门技巧：
z
找到您项目容易实现的目标 不要假设所有数据都必须是 XML 数据 意识到 J2EE 和基于 SOA 的数据服务的折中 永远记住，混合体系结构是生活的一部分（即，不要害怕双层体系结 构！）
z
z
z
在 SOA 中实现企业数据服务的案例
第 13 页

首先，找到你项目中易于实现的目标。最简单的可能是“无趣但重要”的 目标。比如，找到组合应用程序中重复使用最多的数据，将它们作为统一 数据服务的一部分进行管理。这些重复使用的数据功能可能是业务方面 的，也可能是技术方面的，但它们应当具有明显的普遍性。比如：
z
业务数据服务示例 o o o GetCustomer.wsdl（上下文、过滤器……） UpdateBusinessEntity.wsdl（entityName、newEntity） CalculateSalesTax.wsdl（项、位置、促销……）
z
技术数据服务示例 o o o GetChangedData.wsdl（entityName、过滤器……） AddAttribute.wsdl（canonicalFormat、newAttribute） InvokeETLJob.wsdl（packageName）
这些普通的服务类型可能无趣，但却定会成为企业 SOA 中使用最广泛和 最频繁的服务。数据服务挑战中较难的是提供一个受控但灵活的基础架 构，它允许不同的组织在共享的框架中构建、修改和发布其自己的服务。 在寻找可优化数据服务的地方时也可找到易于达到的目标。在其源格式中 处理数据，而不是武断地认为任何数据在某一点上都需要转换为 XML（这 可能会使您的有效负载翻两倍同时降低性能）。 比如：
z
如果技术要求是针对传入数据库中的大型 (>20MB) 数据包的，而现 有的数据包都是平面文本，则可以不转换为 XML，使用优化的数据 服务将其直接导入数据库中。 如果技术要求是转换大型的 (>20MB) XML 文档，将它置于 JMS 队列中，ETL 引擎（替代 XSLT 脚本）可以加快转换并改进业务服 务水平协议。 如果技术要求是作为 BPEL 流程的一部分来复制数据库的一部分， 将这一工作委托给复制服务，但将控制点、监视和 SLA 承诺保留 在 SOA 层。 如果技术要求是作为 SCA 业务服务的一部分加载业务智能多维数 据集，使用经过预先配置可有效结合多维模型工作的从属流程（其 中 SOA 为主流程）。
z
z
z
在 SOA 中实现企业数据服务的案例
第 14 页

听起来陈腐，但对于数据服务的简单建议是总使用适合于工作的正确工 具。许多 SOA 的粉丝喜欢将 XML 用来解决所有问题，而实际上有许 多专门针对典型大型企业中普遍的非 XML 数据格式进行了重大优化的 工具。最好将面向服务体系结构视为公用控制点和重配置的框架而非通 用数据层。 因此，数据服务易于达到的目标可能因简单的数据操作或用于包装常规数 据技术的瘦 SOA 外观而显得了无生趣。但是这些起点可能是启动一个真 正服务于企业多年的多层数据服务规划最为有用的和常识性的方法。
图 12：ETL 委托给 SOA，基本模式 为企业数据服务建立一个合理计划可能会令听多了 J2EE 框架和新 XQuery 工具的普通技术人员感到困惑。确实，虽然 SDO（服务数据对 象，一个当前很流行的用于数据服务的 J2EE 框架）和 XQuery 引擎 （一些供应商经常将其宣传为数据服务）对于某些新建 SOA 应用非常有 用，但它们也可以在要求访问大量旧有数据的 SOA 中成为巨大的瓶颈。 根据定义，SDO 和 XQuery 引擎模式在元数据或数据值本身中复制了一 部分的核心旧有数据。这在新发现的抽象（如 SDO 组件或 XML 文档） 的优势对于消费型应用程序非常重要的情形下是令人满意的。但是不可避 免（新老数据形状间）的阻抗失配和数据复制（根据供应商使用不同的缓 存模式）可能会显著地降低您的数据性能。在性能的重要性低于虚拟层所 提供优势的情况下，这一损害并不要紧。 数据服务架构师必须对应用程序性能要求和 SDO 和 XQuery 方法在数据 服务层中所导致的延迟保持警觉。这里要说的是，实际部署数据服务时既 不需要 SDO 也不需要 Xquery。事实上，在给定的 SOA 中，非 SDO 和非 XQuery 数据服务的性能可能是最好的。
在 SOA 中实现企业数据服务的案例
第 15 页

归根结底，数据服务基础架构需要显示一系列的体系结构、功能服务和交付 方式。总结如下： 数据服务的体系结构模式 — 服务运行之处 o 基本的 WSDL/XML 外观 — 数据源的简单 WSDL 外观 o Java SDO 代理 — 各类数据源的 Java 抽象 o XQuery/XML 代理 — 各类数据源的 XML 层抽象 o 数据服务外观 — 用于常规数据服务（复制、迁移、集成、转换和 主数据……）的引用传递 API 高级功能数据服务 — 服务做什么 o 主数据服务 — 黄金记录的生命周期维护 o 批量数据服务 — 优化的批量移动和转换 o 数据访问服务 — 获取和更改日常业务数据 o 数据网格服务 — 优化的数据对象缓存和集群 o 数据质量服务 — 自动化的清理、匹配和重复数据删除 o 数据转换服务 — 集中化的转换组件 o 数据事件服务 — 监视数据状态、更改和规则 数据服务的数据分发方式 — 如何获取数据 o RPC 方式传输 — 使用常规的请求-响应方式进行远程调用 o 基于事件的传输 — 通过队列类型系统发布/订阅 o 基于流程的传输 — 通过 BPEL 或其他长久的 XA 完成事务 o 对象传输 — 通过应用程序语言中的封装对象 o 批量方式传输 — 低级的，直接到达/来自源持久层
图 13：企业数据服务逻辑视图 没有一个方法对于所有可能的企业数据服务都是最好的。而且，没有一 个功能可以满足所有的企业数据需求。在 SOA 化体系结构的未来中， 以混合方法实施数据服务将占统治地位。
在 SOA 中实现企业数据服务的案例
第 16 页

业务需求和数据服务架构师将需要各种各样的服务级别协议，这些协议有 时偏向于灵活性，有时可在没有旧有数据的新系统中分离出来，有时需要 极好的性能和扩展性。让软件架构师能够选择最好的体系结构、功能模式 和传输格式对于一个合理的长期数据服务战略是不可或缺的。 尽管可允许不同于这里介绍的选择，我们仍可以肯定，数据服务将是任何 企业级 SOA 的关键组件，没有任何一种实施数据服务的技术方法可以解 决企业的所有问题。采用数据服务的最好方法是从可以较快成功的项目、 技术上较易达到的目标开始并坚持 SOA 语境中使用的成熟数据管理模 式。
第 5 部分：用于数据服务的 Oracle 数据集成套件
Oracle 数据集成套件由 Oracle 一系列同类最佳产品组成，在企业数据 集成和 SOA 数据服务情形中特别有用。这一产品套件旨在通过降低整个 企业的数据集成成本和复杂度来改善业务运营。企业第一次可以使用松散 耦合的基于组件的现代体系结构来统一其常规数据基础架构。
图 14：Oracle 数据集成套件技术平台 ODI 套件为数据分发、设计工具、数据集成基础和广泛的数据连接 性提供了综合的技术平台功能。这些技术功能用于：
z
数据分发 — 为所有数据集成和数据服务提供高级访问点。数据服 务可作为 SOA 就绪的 Web 服务端点、Java API、BPEL 流程模 型、缓存的 Java 对象进行发布，或通过批量传输协议和格式发 布。这一层提供一个公共的数据分发框架，不管理具体客户端应用 程序的要求是什么。
在 SOA 中实现企业数据服务的案例
第 17 页

z
设计工具 — 为用户管理数据集成和数据服务运营提供的工具。对 于企业级运营，将支持多个角色，包括数据管家、企业架构师、流 程建模师和数据架构师。这一层是框架的管理和开发控制台。 数据集成基础 — 为数据集成提供核心技术功能。常用功能包括使 用 ETL 方式的数据转换、用于所有数据类型的数据质量功能以及用 于管理数据记录生命周期的主数据服务。该层是在任何企业语境中 提供高度优化的数据集成的基础。 数据连接性 — 提供通过任何协议对任何位置、任何格式数据的访 问。有时使用 API 是实现数据集成的最好方法，而通常直接通过数 据库层是最好的方法，这一层提供对源/目标软件应用程序/系统中任 何点的访问。
z
z
图 15：ODI 套件的主要用户 从功能上说，Oracle 数据集成套件的主要用户包括 集成和数据架构 师以及新近出现的管家。这些架构师、管家和具有管理职能的角色类型是 整个集成策略极其重要的部分。下面我们将对参与 ODI 套件数据交互的一 些典型的工作角色进行一些了解。 业务用户/ 主题专家 (SME)/分析师 他们是谁？ z 非技术功能专家和最终用户
z
通常在规定范围内与计算机进行交互 主要的应用程序将是 ERP 系统和办公应用程序 有时会包括流水线工人和/或其他蓝领角色 他们有时会使用业务智能信息板，但仅限于查看
z
z
z
在 SOA 中实现企业数据服务的案例
第 18 页

他们如何与 ODI 套件进行交互？ z 他们可能永远不知道 ODI 套件系统的存在
z
他们将只知道他们的应用程序数据是好还是坏 例如，他们将使用客户记录、供应商记录、资产跟踪系统、产品档 案等。他们对数据集成的了解将仅限于处理劣质记录（他们必须要 手动校核这些记录）的频率
z
流程架构师 他们是谁？ z 这是一个纯粹的面向业务的流程建模师和负责服务总线的 SOA 企 业架构师之间的代理角色
z
了解业务流程要求，并可将它们转化为在 BPEL 中通过编码实现的 技术规范 主要的应用程序将是 BPEL 流程管理器
z
他们如何与 ODI 套件进行交互？ z 作为 ODI 套件的核心用户，流程架构师将使用 BPEL 流程管理器 来管理流程的整个生命周期
z
他们将是从其他工具（如 Aris/BPA 套件）导入内部业务流程模型 的专家，还是优化业务流程以打造高性能 SOA 环境的专家 他们将把数据服务作为各种流程的端点与其进行交互
z
图 16：BPEL 流程管理器流程模型 数据管家 他们是谁？ z 这是看护人/管家/维护人员角色：管理数据
在 SOA 中实现企业数据服务的案例
第 19 页

z
了解业务要求和 IT 目标 — 制定和执行低级别计划以修复由数据 本身 主要的应用程序包括 Oracle | Hyperion Data Relationship Manager (DRM) 和 MDM Hub Applications（管家功能的核心位于 MDM 框 架中），但还使用 ERP 系统和 MDM 基础接口
z
他们如何与 ODI 套件进行交互？ z 作为 Oracle | Hyperion DRM 的核心用户管理参考数据
z
他们将是查看和浏览 DRM 和其他 MDM 应用程序中数据的专家， 他们将知道能由谁通过什么方法来更改哪些数据 他们将作为管理团队与工作流系统交互，以响应由 SME 和业务分 析师设定的任务 他们将确保优质的数据
z
z
图 17：用于主数据管理的 Oracle | Hyperion DRM 数据分类师 他们是谁？ z 这是一个定义角色：定义类别、实体和组
z
了解公司信息的业务要求、IT 目标和上游的使用 对层级结构、本体、标记集和一些数据模型进行建模 主要的应用程序包括 MDM 应用程序和基础接口
z
z
他们如何与 ODI 套件进行交互？ z 作为 DRM 和其他 MDM 应用程序（如层级管理、分类、有效日期 设定等）的用户
在 SOA 中实现企业数据服务的案例
第 20 页