odi数据服务中文

《odi数据服务中文》由会员分享，可在线阅读，更多相关《odi数据服务中文（31页珍藏版）》请在金锄头文库上搜索。

1、 在 SOA 中使用 ODI 套件实 现企业数据服务 Oracle 白皮书 2008 年 1 月 在 SOA 中实现企业数据服务的案例 第第 2 页页在面向服务体系结构中使用 Oracle 数据集 成套件实现企业数据服务 概述概述 随着业界对面向服务体系结构 (SOA) 构想的关注，人们有时会忘记 SOA 在很大程度上类似于管道工程，其大部分业务价值直接源自其输送的数 据。 今天，由业务智能、数据仓库和主数据管理构成的数据体系在很大程度上 仍然游离于新兴的 SOA 构想之外。但是，企业层面的数据服务可以将这 些数据和 SOA 体系有效整合到一起。 如果设计合理且执行得当，数据服务可以提供连接传

2、统数据系统与新兴 SOA 范例的纽带，而这正是现在所缺少的。通过提供分离的数据外观和易 于虚拟化的 API，数据服务可以让 SOA 能够建立系统控制 无需总是 强制企业数据通过低效的 XML 层。 本白皮书将通过介绍企业如何依赖宝贵、复杂的业务数据说明为什么数据 服务是企业 SOA 部署的基本要求。此外，还将介绍一个使用 Oracle 数 据集成套件的企业级数据服务解决方案。该套件是市面上唯一基于 SOA 的数据服务平台，它充分整合了 SOA 和单项最佳的传统数据管理工具的 优势。 第第 1 部分：数据的首要地位部分：数据的首要地位 一直以来，数据都很重要。几十年来，有关 EAI、ETL、MD

3、M 和 SOA 的争论都得出了相同的结论 数据至关重要。如果说内容是用户 Web 的王者，那么数据就是企业软件的至尊。 而有时企业软件部门却看不到这个简单的事实。.在过去的十五年间，随着 Java 的兴起、围绕 EII、EAI 和 SOA 的大肆宣传、XML 的迅速走红以 及默默地在 ETL 项目上投入数十亿 一切都是这么简单，以至于我们 忘了为什么要构建和购买这些基础架构。我们这么做是为了数据。 如果没有数据，也就不需要过程编排了。所有的 SOAP 信封将没有任何用 处，所有的服务总线将没有任何东西可以发布，应用服务器将没有任何东 西可以提供。因此说，数据至上。 但是，数据也带来了很多不容回

4、避的重要问题。首先，企业已经知道如何 收集更多的数据，但却无法有效地理解所有数据。第二，随着数据的增 多，基础架构和工具为有效地管理数据而变得拥挤不堪。第三，在小型基 础架构中用于定义数据的方法无法扩展以解决大型业务问题。最后，企业 架构师往往沉迷于新技术而忘记了三十年艰苦斗争获得的数据管理经验仍 然适用。 自 2000 年以来产生的数据比在此之前人类有史以来产生数据的总量还要 多。 图 1：信息爆炸（自适应信息，Wiley & Sons，2004 年） 对企业和政府来说，传感器的出现意味着我们可以实时监视任何事物：从 发运点到工厂温度或您自己的心率。所有这些数据都会汇集于某个地方。 它们被无

5、限期地存储下来，用于实时信息板、历史分析或存在某个地方备 用。但是，现在我们的数据收集速度要快于数据解析速度。数据收集的速 度、对诸如 RFID 传感器和其他监视器的使用呈指数级增长。换言之，数 据问题越发严峻。 但令人惊奇的是，自上世纪 90 年代以来，企业的基础架构一直没有改 变。那时，消息队列 (MQ)、事务处理系统 (TPS) 和 ETL 工具是企业软 件的主干。您猜怎么着？现在它们依然是。虽然 BPM、SOA、ESB 和 EII 的采用率有所增加，但是 MQ、TPS 和 ETL 主干依然存在。 所有新增数据的压力和对成熟工具的需求荒谬地使现存成熟的软件基础架 构看起来颇具吸引力。许多

6、新系统都试图将所有的数据转换为 XML 或使 用 Java Entity Bean 作为数据管理层。这两种方法对小型应用程序或特定 情形是可取的，但它们的扩展能力还不足以解决全球 2000 强企业经常遇 到的数 TB 大小的问题。因此，有经验的架构师会重新使用成熟的 RDBMS 模式作为以 MQ、TPS 和 ETL 接口为输送所有数据的管道的数 据体系结构的主干。 但是 SOA 热潮正在减弱。为什么不使用 SOA 作为以数据为中心的体系 结构呢？ 在 SOA 中实现企业数据服务的案例 第第 3 页页在 SOA 中实现企业数据服务的案例 第第 4 页页第第 1 部分：部分：SOA 在以数据为中心

7、的体系结构中的角色？在以数据为中心的体系结构中的角色？ 回到 2001 年，当面向服务体系结构的狂潮开始蔓延的时候，我们觉得它 很神奇。还记得动态发现的承诺吗？人类可读的信息？简单的 XML 数据 对象？但是问题很快就出现了：不同的供应商规范、安全漏洞、性能问题 等等。 2008 年有了好消息 SOA 终于发展为企业级基础架构。与最初解决所 有集成问题的期望相去甚远的是，SOA 的主要工具（企业服务总线和业 务流程引擎）还差那么一点才能真正取代 MQ 和 TPS 系统的长期统治 地位。基础 SOA 的可靠性和性能均已足够强大，几乎可以解决所有问 题。但 SOA 仍不是 ETL 和数据集成的最佳

8、选择。 数据集成的情况有时很简单，有时却是不可能的。对于简单的情况，如转 换少量数据并将其存放到某处，基于 XSLT 的转换服务运行于服务总线之 上的普通 SOA 通常就可以应付。这种方式在数据格式为 XML 时很有帮 助，这是因为只是为了将数据转换为某种其他非 XML 格式而将数据转换 为 XML 并不是最佳选择，因此对这些简单的以 XML 为中心的数据集成 情形，SOA 很适合。 但数据集成的一般使用情形都超出了 SOA 的核心能力所能应付的范围。 一般使用情形可能需要将几 GB 的数据从一个数据库载入另一个数据库， 将数据形状从第三范式 (3NF) 转换为多维（星型）模型。此一般使用情

9、形用来支持业务线的需求，如：报表生成、业务智能、性能管理、财务规 划以及其他分析功能。因为批量数据转换性能和效率较低，所以 SOA 极 不适用于该一般使用情形。 几乎所有的 SOA 框架都运行在 Java 容器中，当需要将数 GB 的数据 输入 Java 虚拟机时这就成了极大的劣势。同样，SOA 处理数据的范例 是 XML 几乎所有的 SOA 框架都要求将数据转换成 XML 以进行编 排和转换。但是，1 TB 的数据仅因为增加的标签、模式和尖括号就会增 大为 5 或 10 TB 的 XML 数据。（见图 2） 即便如此，XML 仍然是最好的文档和消息格式。SOA 的热潮曾经使人误 以为 XML

10、 是一种数据语言，其实它不是。作为 SGML 的简化形式， XML 只是为了提供一个结构良好的标记文档和消息标准方法。实际上， XML 和 XSD 的核心模型称为 Infoset，它是一个用来定义可用 XML 项 目类型的树形结构。但是，XML Infoset 与关系数据模型和图数据模型不 同，它不是数据模型。这就是为什么纯 XML 数据库非常少且几乎在技术 上不宜用作一般数据管理的原因。 图 2：使用 XML 标记批量添加数据 事实上，SOA 数据服务的任何早期定义都无法真正扩展到解决企业级问 题。主要从 JDO、SDO、DAS、DTO 等众多标准演化而来的 Java 定 义实际上是 (a)

11、 试图定义 Java 与关系数据交互的模式和 (b) 将在应用 程序和 Java 容器间移动这些对象或组件的 API 标准化。但是，很少有 企业解决方案将联合使用容器的 Java 对象作为企业数据集成或联合的主 要方法。 其他早期的 SOA 数据服务定义是面向 XML 的数据服务视图，由基于 XSD 的数据交换规范模型决定。此方法提倡对规范消息格式使用基于 XSLT 的映射，而在某些情况下使用 XQuery 和 Xpath（或 SQL），以 在不同的数据源间联合查询。但是，如前所述，XML 是较差的数据模 型，而且效率又低，因此联合查询方法仅适用于高度优化的缓存。 图 3：数据服务的常规 Ja

12、va/XML 视图 简单而残酷的现实是企业数据要求苛刻，将只有 SOA 的解决方案用 于所有企业数据可能只是梦想而已。 企业数据要求过于复杂，又受到业务智能系统的高容量、多维度特性的过 度驱动，因此无法单从信息层提供整套服务。另外，企业数据服务的宝贵 模式和教训实际上在 SOA 出现之前已经存在，并可以与 SOA 基础架构 本身和谐共存或与之完全独立。 在 SOA 中实现企业数据服务的案例 第第 5 页页在 SOA 中实现企业数据服务的案例 第第 6 页页那么，假设从 SOA 分离数据服务，那 SOA 将如何处理它们呢？ 第第 2 部分：什么是部分：什么是 SOA 数据服务？数据服务？ 虽然

13、SOA 无法进入数据管理的基础，但是越来越多的证据表明，使用新 部署的 SOA 基础架构来协调企业数据服务可能会带来很多新好处。这些 好处并非来自对传统数据管理系统的替换，而是来自将 SOA 用作传统数 据管理系统的一个控制点。因此，SOA 数据服务不仅可以处理 XML，也 是为处理各种类型的数据提供高度优化的引擎的企业数据管理端点。 数据服务本身并不需要使用 SOA 就可以称为服务。事实上，所有关键数 据服务属性，包括基于合约的开发、数据封装和声明式 API 的使用均早于 SOA 相当长时间。 数据服务的定义因人而异，但可以肯定的是，在上世纪 60 年代，随着 EDI（电子数据交换）服务在金

14、融机构间的使用，数据服务已经成为软件基 础架构不可或缺的一部分。随后，在上世纪 80 年代，面向对象的设计原 则使得关键数据服务模式得到广泛应用。最近，用 Java 编写的数据服务 实际上要比 SOA 数据服务理念早几年。 从技术上说，数据服务应该具有以下属性中的几种： ? 基于合约的绑定基于合约的绑定 用于按合约设计，例如 WSDL/SCA ? 数据封装数据封装 仅通过 API 间接访问数据 ? 声明式声明式 API 除常规绑定之外的某种可查询 API ? 分离的绑定元数据分离的绑定元数据 API 描述符本身就是模型的一部分 ? 分离的数据模式元数据分离的数据模式元数据 数据模式从 API

15、分离出来 但是，数据服务的理念更像是一种理想。数据服务追求这样一种理想状 态：一个共享的控制点来控制所有重要的业务数据。数据服务应该为数据 提供便于访问、发布和发现的控制点。因此，从根本上说，数据服务可以 只是一个老套的东西 一个标签或标记 用于标记特定软件组件的存 在意义。 遗憾的是，市场推广的力量已经让人们普遍认为数据服务对于真正的企业 工作来说过于浅显和狭隘。首先，有人认为短视地认为数据服务只是提供 企业信息集成 (EII) 式的联合查询。一些小的供应商认定 EII 本身可以提 供数据服务作为联合查询和基于 XQuery 或 SQL 的数据视图。但是，这 些基于缓存的传输机制实际上相当于

16、一个数据平台，而集中星型 (hub-and- spoke) 数据平台是一种很老式的平台。事实上，在实践中很少会要求用真 正的（非基于缓存的）查询联合，只是要求使用实际数据服务的一个很小 方面。 另一个有时与 EII 构想一同推销的流行理念是数据服务的规范 XML 模 式。如前所述，我们知道，虽然基于 XML 的数据模型有一定的价值，但却 无法替代真正的数据模型，只能在某些类型的事务处理中作临时的数据表示 方法。 从整体上考虑并着眼于企业的规模问题，数据服务可以有几种不同的数据传 输方式。太多的 SOA 权威人士认为 XML 是唯一可取的数据交付格式， 但是一个数据解决方案要想真正地应用于企业，就必须支持多种不同的传输 方式。数据传输只是软件客户端为数据提供服务的方式。 图 4：数据传输模式、功能服务和拓扑 以下是一些处理数据的典型的数据传输模式： ? RPC 方式传输方式传输（远程调用） 大多数传输方式的基础。基本传输模式 只建议对远程过程的调用应该返回一些数据。某些情况下调用本身可以 包含声明式查询，如