技术前沿与趋势
信息集成：新一代信息技术
摘要：
企业软件行业正在进行变革，企业应用程序开发处于变革的十字路口。单独在后台无尘室（Clean room）部署单片大型机的日子已经一去不复返了。今天企业应用程序面临的挑战是实现跨企业不同信息平台和跨互联网、并尽可能地快地将大量可用的数据集成和转换成信息资产-----------这些信息资产可以让企业更有针对性地回应市场及客户的需求、从而保持领先的市场竞争力并不断开辟新的商机。在这里我们基于对部分行业信息集成应用的典型需求分析，介绍了信息集成技术的历史发展及IBM利用其数十年来企业数据管理基础设施中的优势，在提供强大和统一的信息集成解决方案方面的技术理念。
撰稿
M. A. Roth
D. C. Wolfson
J. C. Kleewein
C. J. Nelin
近几年来互联网和电子商务的极速发展引发了企业应用程序可用信息数量和类型的爆炸性增长。分析家们预测，在接下来的三年内，企业将生成大量的数据。互联网业务的发展步伐远远领先于应对这一信息爆炸的工具和技术的开发，许多企业发现它们的系统在面对所管理的数据的数量和多样性方面很难更上一层楼。当前企业面临的挑战是信息集成。企业应用程序必须能够与数据库、应用程序服务器、内容管理系统、数据仓库、工作流管理系统、搜索引擎、信息队列、Web crawlers、挖掘和分析包以及其它企业集成应用程序交互。它们必须使用广泛的编程界面，了解多种语言和格式；它们还必须提取和结合多种交付机制生成的多种格式的数据。很明显，传统上存在于数据库管理系统、内容管理系统、中级缓存、数据仓库和其它数据管理系统之间的界限越来越模糊，企业迫切需要一个能够为所有这些服务及它们提供的数据提供统一视图的平台。
如果市场保持这一发展势头，那么在接下来的三年内企业将生成比以往任何时候都更多的数据，互联网的大范围普及使得所有这一切变得轻而易举，通过一个URL（统一资源定位器）就能访问到它们。这种信息爆炸带来了激动人心的交叉行业商机。那些可以从数据的海洋中迅速提取关键信息并把它们转换成重要资产的企业将成为市场上的强者。
事情远不止您想象的那么简单。今天的企业系统扩展远超出了企业数据中心的范畴，包括客户、供应商、业务伙伴和电子市场。这些系统与数据库、应用程序服务器、内容管理系统、数据仓库、工作流系统、搜索引擎、信息队列、Web crawlers、挖掘和分析包以及其它企业应用程序交互，它们需要大量的编程界面(ODBC [开放数据库连接]、JDBC** [Java**数据库连接]、Web业务、Java对象、J2EE** [Java 2平台、企业版本])，以及与大量的数据模式和语言协作(SQL [结构化查询语言]、XML [可扩展标记语言]、XPath [XML路径语言]、WSDL [Web业务描述语言]、SOAP [简单对象接入协议])。这些系统可以提供不同时间属性的数据，如实时(stock tickers、news wires)、现有（数据库）、稍微过期(中级缓存、数据库复制)和历史(数据仓库)数据。数据通过各种交付机制来生成，如(应用程序、数据库、文件、CD-ROM、连续的数据反馈、电子邮件、Web下载)，并且格式多样(关系表、XML文档、图像、视频文件、音频文件)。
目前企业软件应用程序的挑战是信息集成。信息集成是将数据管理系统、内容管理系统、数据仓库和其它企业应用程序中的核心功能集成到一个通用平台中的一项技术。本文将详细阐述信息集成挑战的特性，介绍提供端到端解决文案来透明管理数据的数量和多样性的体系结构组件，以及目前市场上的数据管理系统。
这一平台的基础是强大的数据管理系统，它提供关系和XML数据存储，以及一组丰富内容服务器的接入。这一基础层利用数十年数据库技术的演进，藉此应对强大的数据管理相关的存储、检索、可扩展性、可靠性和可用性挑战。与这一基础层紧密结合的是综合业务层，它利用商务智能、内容管理和商务流程集成中的同步技术演进，这些技术可以减轻开发和管理复杂的企业应用程序工作。统一的界面层为基础层和综合业务层提供的大量业务和数据提供标准编程模式和查询语言。
下面我们将简要回顾数据管理基础设施和企业软件基础设施的发展史。我们将通过不同行业提供的案例来阐述信息集成挑战的范畴并拟定解决方案的需求。接下来的两个小节介绍满足这些需求的下一代企业软件技术平台的组件，显示这一平台如何满足上述需求以提供端到端的信息集成解决方案。最后进行总结。
企业软件技术发展历程
在过去30年中，数据管理系统一直是企业软件基础设施的核心，图1显示了它们的演进历程。20世纪70年代初关系数据模式和数据独立性概念的推出，使数据管理行业焕然一新并迅速赶超提供大规模数据管理的网络和分级系统。在接下来的二十年内，在IBM研发小组的杰出领导下，借助于存储和检索技术、并行控制和恢复以及查询处理技术，如基于成本的优化，等领域的关键创新，关系数据库发展成一种高性能、高容量的查询处理引擎。分布式系统和并行处理技术使全球企业能够管理大量的分布式数据。随着新业务需求的出现，可扩展的数据库架构允许用户轻松地引入数据类型、接入战略和索引方案。联邦的数据库技术提供强大且灵活的方法来透明接入全异的分布式数据源。
在数据库管理系统(DBMS)技术演进到管理商业数据的同时，其它重要的技术也同步发展，从而使用户可以更轻松地管理商务逻辑和商务流程。数据仓库、数据挖掘和OLAP(在线分析处理)技术增加了商务智能， 它提供对商务数据基于发现和基于假设的分析方法，以确定发展态势和模板，执行“假设”分析。数字图书馆和内容管理系统演进到管理大量数字媒体仓库， 从而提供登录和退出业务、权限管理和分级存储移植。信息处理系统和信息代理（message brokers）为企业应用程序集成提供基础设施，允许自主应用程序以可扩展的异步方式相互通信。工作流系统13有助于实现商务流程自动化，提供基础设施来管理订单的逐步履行、向适当的人选分配任务以及在适当的时间调用自动化步骤等流程。
商务应用程序与数据管理和企业管理系统一同发展，从而可以利用这两个系统的最佳特性来创建先进的软件程序，这些软件程序奠定了目前所有企业的基础。过去集成这些系统成为了企业应用程序开发人员的重负。但是企业不再能够容忍这种情况的出现。传统定制构建的集成系统不能够满足互联网的大范围普及带来的可扩展性和可靠性需求。重要的开发和计算资源都用于在系统之间传输数据，以及数据格式的相互转换。为了能够参与如今“全天候”全球市场的竞争，企业应用程序需要新的信息集成平台，它将过去三十年中企业数据管理方面的优势集成到单个、统一的界面中。
请点击看图1 向信息集成演进
许多商业系统和学院项目解决了综合的信息集成平台多个方面的问题。通常，其中许多方法从新构建优化用于满足特定目的的专用系统。例如，Tamino和Ipedo等产品致力于提供可以优化用于管理XML文件的数据仓库。同样，数据联邦提供稳定的研究基础和多种商业实施方案。TSIMMIS 、DISCO、HERMES和Information Manifold等项目构建专用的查询处理系统来探究联邦数据库技术的多种特性，如调整、补充和可扩展性。Nimble、Callixa和InfoShark等产品联邦数据库引擎外部的数据。Garlic和DB2 Relational Connect扩展了传统的关系数据库引擎，使之具有联邦的功能，DiscoveryLink 是使用这一技术构建的商业应用程序，主要面向生命科学领域。
实际上，DiscoveryLink的成功验证了信息集成的商业价值和强大性，它以商业数据库系统开始。正如图1所示，由于各方面的原因，目前全球正在对DBMS技术进行广泛的投资。数据库可以非常自然且强大地满足传统企业数据的存储、检索和可靠性需求，它可以轻松地支持大量的数据和接入模式。我们相信一个能够全方位拓展和增强DBMS体系结构的平台是提供强大的端到端信息集成的最佳方案。
请点击看图2 金融服务案例
当前的发展趋势显示信息集成是一种跨行业的挑战。从金融服务到制造业，这些行业都受到数据数量和多样性，以及互联网业务模式引发的业务连续性需求的冲击。在这一小节，我们介绍三个不同行业提供的案例来阐述集成挑战，以及根据这三个案例拟订解决方案的一般需求。
金融服务。我们的第一个案例是一家金融服务公司，它订阅了多种商业研究出版物。这些出版物提供格式为RIXML (研究信息标记语言)的数据， XML词汇表结合投资研究信息和标准格式来描述报告的元数据。报告可能来自企业内部和外部多个数据源，它可以通过多种机制来传递，如实时信息反馈、电子邮件分发表、Web下载和CD-ROM。图2显示了这类研究信息在公司内的传输流程。
当收到一份报告时，系统将按报告自身的XML格式进行归档，将音像剪辑发送到适当的媒体服务器。接下来，系统从报告中提取重要的元数据，如公司名称、股价和盈利评估，并将它存储到关系表中。 该公司在全球都设立了办事处，因此这类信息立即在多个位置进行复制。这类信息用于检测买/卖/持有价位发生的变化并向股票和债券经纪人和重要客户提出建议。挖掘应用程序更全面地分析原始文件及其提取的元数据，查询“合并”、“并购”或“破产”等关键字来对内容进行分类和汇总。汇总后的信息将与历史信息一同向企业的市场研究和投资银行部门提供。这些部门结合汇总后的信息以及存储在电子表格和其它文件中的财务信息来进行趋势预测和确定并购良机。
电信。在完成了与多家企业合并之后，一家电信企业依赖于度身定制的客户服务系统来为客户提供支持。这一系统包括多家通过并购获得的呼叫中心，如图3所示。当收到客户呼叫时，系统将它传送到适当的呼叫中心、记录并将它保存到音频服务器中，该音频数据也可以被转换成文本文件并保存到文本仓库中。为了响应呼叫，业务代表启动将用于跟踪故障处理的“故障票”。
请点击看图3 电信案例
首先，业务代表调用与客户相关的所有信息，它可以采用多种不同的格式，在多个站点之间进行分发或复制。例如，计费和账户信息可能来自于应收账款部门，而工程规范可能来自于产品开发部门，这两个部门都位于呼叫中心以外其它位置。XML用于在企业内部不同站点之间传输信息。接下来，业务代表开始排障，使用高级搜索引擎来帮助诊断故障。这种搜索依赖于先前的故障票提供的关键短语和故障类别，它们可能通过电话呼叫生成，或者从现场技术人员的信函或笔记中提取。
在初步诊断之后，业务代表将业务请求添加到将分配给现场技术人员的队列中并向客户返回确认码。现场工程应用程序从队列中删除该请求并将它分配给适当的技术人员，技术人员在移动设备上接收请求，开始修复。在企业的另一面，产品管理部门使用搜索引擎来查找常见的故障领域，客户使用模板来确定质量保证问题，发现需要的功能并确定新产品需求。
请点击看图4 货运代理案例（Freight brokerage）
货运代理。货运代理公司为客户提供服务，旨在在众多的商业航空公司中找到最低的运输费用。图4阐述了这一流程。客户和客户应用程序通过向代理公司发送一条XML信息（也许使用SOAP）来请求运输预订，在收到请求后代理公司系统将启动一个工作流程来进行处理。该工作流程对最初的请求归档，然后使用该请求信息来更新客户历史记录。承运人信息系统使用一组符合要求的承运人来匹配客户请求，联系外部的货运路线调度系统来确定可能的货运路线。接下来，承运人信息系统调用每家承运人的Web业务请求，联系每家相关的承运人来获得一份报价。系统将在答复中计算最终胜出的报价并通知客户，同时记录报价和答复以便进一步分析，它用于监视承运人伙伴、获得更合算的合同运费以及确定运输趋势和新机会。
信息集成需求。处理介绍的案例的系统必须依赖自己的API（应用编程界面）和工具提供的多种数据管理系统和企业应用程序，并且企业必需开发复杂的内部集成和管理软件来管理它们。虽然这三个案例出自不同的行业，但它们表达了这样一个信息，即传统存在于DBMS、数据仓库、内容管理系统和其它数据转换和集成业务之间的界限越来越模糊。这些案例之间的相似之处阐述了强大的信息集成平台一组常见的需求。
企业应用程序必需支持XML作为第一类数据模式。虽然在过去三十年内关系数据模式推动了企业应用程序的发展，但XML成为了便携式数据的混合语言。企业极其依靠它来实现企业集成。XML更适合于表示半结构化（semistructured）和（未结构化 ）数据，并且与关系模式不同，它还提供元数据的标准表示法来描述这些数据。这种灵活性允许金融服务公司接收不同厂商发布的报告；为货运代理人提供一种通用语言来与多家承运人协商报价；使电信企业能够整合通过并购获得的多个客户支持系统。
企业依靠它们企业应用程序中多个、不同的数据源。金融服务公司依靠实时数据反馈、数据库电子表格和媒体服务器。货运代理人依靠外部货运路线调度系统和承运人的实时接入。电信企业应用程序需要接入多个自主的垂直应用程序。这些案例使用了信息整合，从多个数据源收集数据并整合到中心仓库，然后联邦，其中多个自主源的数据作为查询的一部分来接入，但不离开它们的原始源。某些数据源遵循一种模式，而其它数据源，如信息门户，并非如此。由于企业收到如此多的数据源发来的信息，因而用于描述数据源发送的数据的元数据与该数据一样重要。
通过统一界面来接入所有数据和业务的单个系统可以精简开发流程，提升性能。
今天的企业系统需要混合查询和数据转换业务并提出了越来越苛刻的性能要求。前面介绍的案例需要对存储在不同系统并使用不同格式的数据进行参数化查询、纯文本查询、挖掘和数字化资产管理业务。虽然目前市场上提供了具有不同API的专业化系统来处理各类查询，通过统一界面来接入所有数据和业务的单个系统可以精简开发流程，提升性能。
这些案例还表明，企业流程天生就是不同步的。报告故障的客户可以使用确认码，无需在排除故障的同时一直拿着电话不放。繁忙的股票交易员不希望被大量的信息淹没，实际上，他们更喜欢在需要的时候获得正确的信息。而且，连续可用性需求意味着在故障时应用程序必需能够继续运行。数据源和应用程序有规律的启动和休眠（come up and go down），数据馈入可能被硬件或网络故障中断。如果电信客户服务系统处于休眠状态，现场技术人员将继续进行分配给他们的修复工作。如果特定的承运人不可用，货运代理人应协商可用的承运人提供的报价。这些例子显示信息处理和工作流系统像数据管理一样，是企业应用程序的一个完整部分。
最后，这些案例中应用程序的复杂性阐述了开放标准的基本需求。这类应用程序联邦大量的数据源、管理系统和应用程序。如果未制订管理它们界面和统一编程模式的标准，那么整合和管理这类动态环境中的新数据源的工作将非常庞大，而且招聘和留住具有开发集成软件所需技能的员工的成本将很快超过系统自身创造的价值。
请点击看图5 三层信息集成体系结构
在本小节，我们介绍可以应对信息集成挑战的强大技术平台的三层体系结构。图5显示了这一体系结构。基础层支持不同数据源的不同格式数据的存储、检索和转换。在基础层之上构建的集成层利用企业集成应用程序，提供将数据接入业务透明嵌入到企业应用程序和商务流程中的基础设施。顶层提供基于标准的编程模式和灵活的查询语言支持，以接入基础层和集成层提供的一套丰富的业务和数据。
请点击看图6 基础层体系结构
基础层。如图所示，基础层位于信息集成平台的核心，提供一套核心业务来存储和检索全异的数据。基础层基于可以在所有层扩展具有数据集成功能的高性能DBMS引擎。这些扩展包括支持XML作为本身的数据存储、Xquery作为本身的数据集成语言以及提供外部数据接入的联邦数据接入组件，好像这类数据本身由DBMS引擎来管理一样。
图6显示了这类引擎的组件。最低级别为数据接入组件，它提供API来有效存储和检索永久性存储设备的数据。两个数据接入组件提供用于本机数据。通过关系数据接入组件来存储、索引和检索结构化数据，提供子程序来有效存储、索引和导航分级XML结构的新数据接入组件可以接入本机的XML数据存储。
除了用于本机数据存储的数据接入组件之外，集成引擎还提供用于外部数据的联邦数据接入组件。用户可以通过这一组件来透明接入大量的数据源和丰富的内容供应源，包括外部数据库、文件系统、文件存储、基因数据库和多媒体对象服务器。外部数据源可通过wrapper来接入， 它提供一个界面，集成引擎可以通过这一界面来制订存储和检索数据、管理事务处理和对外部数据执行功能的执行计划。除了集成的查询支持以外，信息集成客户机通过联邦的数据组件接入还可以接入面向内容的功能，如图像查找、多媒体流和生物信息建模。
查询编译器位于数据接入组件的上方，提供可以用来有效存储和检索数据的Xquery和SQL查询语言。与使用何种语言无关，请求被传送到查询编译器来解释该请求并生成执行计划来处理该请求。查询编译器使用基于语言的语汇分析器和解析器来解释请求和广泛使用XQGM (eXtended查询图表模式)结构。XQGM是Starburst Query Graph Model (QGM)的增强版本，它提供比QCM更丰富的语义表示法，包括原始的XML数据模式表示和外部数据源的联邦接入。查询编译器分析XQGM、研究执行该请求的多种战略以及从其最小成本的备选方案中选择一项计划。作为分析的一部分，查询编译器考虑XML数据存储的索引和导航算法、确认外部数据接入以及调用适当的绕接器（wrapper）查询规划子程序来生成有效的外部接入计划。运行时间执行引擎执行选定的计划，与关系数据存储、XML数据存储和联邦接入层交互，以结合适当的数据来履行最初的请求。运行时间引擎包括XML数据接入的Xpath处理运算符（Operator），以及联邦接入的运算符。
与查询处理和数据接入组件一起，信息引擎提供所有数据管理系统需要的一组系统业务，包括鉴权、代码页面管理、登录、恢复、事务管理和事务监视界面，如那些WebSphere提供的界面。
集成业务层。存储和检索级别的数据集成不够支持今天的企业应用程序。比接入不同数据源且采用多种格式的数据更为重要的是知道什么信息可用以及如何使用。集成层提供在可用的信息海洋中进行导航的基础设施并把它部署在用于企业应用程序的环境中。下面介绍集成层提供的关键业务。
元数据。对于全面使用可以通过基础层接入的大量数据源的企业应用程序来说，描述什么内容和业务可用的元数据至关重要。这类元数据由基础层来管理，集成层打包并汇总这类信息以便客户机应用程序导航。这种方法允许客户机应用程序使用相同的API和查询语言来查询元数据和基础数据。
元数据分为两类：系统元数据和应用程序元数据，系统元数据描述资源以及可以在这些资源上运行的业务，应用程序元数据提供关于数据对象以及它如何与其它对象关联的基于域的知识。例如，系统元数据包括关于数据源信息、功能签名、数据格式和索引信息。系统使用这些信息来管理基础数据，处理请求，它们还可以做为客户机应用程序动态发现什么内容和业务可用的重要信息源。本体（Ontologies）、模式（Schema）集成技术和工具可以用于把关联域中不同应用程序的数据映射到通用模式中。应用程序元数据经常包括关于该数据的基于域的注释，它可以帮助用户更深入地理解数据以及它们是如何与其它数据相关联，它们还可以用于把数据从一种表示法转换成另一种表示法，或者提升关注用户查询感兴趣的对象的能力。在金融服务案例中，研究报告中提到的行业、企业和分析家列表等数据都是应用程序元数据的例子。管理元数据的关键是模式映射和模式集成。
内容管理业务。当企业应用程序构建、存储和管理复杂的商业对象时，将创建应用程序元数据，这些商业对象组成多个数字资产。例如，金融服务研究报告包括一份XML文件、多份PDF(便携式文件格式)文件和一份音频或视频剪辑。电信故障票包括客户账户信息、音频剪辑和多份文本文件。集成层提供一套核心业务来管理这些对象及它们的组件，包括登录/退出业务、版本、接入控制和数字权限管理以及分级存储移植业务33。
集成层为数字资产提供URL寻址性，这些数字资产很大并具有与它们相关的基于内容的操作，如媒体流、文件渲染（document rendering）和图像查找。客户机应用程序可以通过查询元数据来查找感兴趣的对象，集成引擎将返回与该查询相匹配的对象的URL。然后客户机可以通过URL直接接入和管理对象。
文本查找和数据挖掘。必须对未结构化的信息进行分析和分类以便企业应用程序使用，对于实时决策来说，答案的及时性是确保质量的关键要素。集成业务层通过向与基础层基础设施紧密结合的综合查询提供多种功能来运行这一分析。
请点击看图7 综合查询业务
综合查询功能如图7所示。基础层中的Astate-of-the-art文本索引引擎提供对集成数据进行原文本查找的基础设施，包括结构化数据、XML文件和用户定义的结构。第二类综合查询提供查询语言结构，以在单个查询中透明结合文本查询和参数查询。除了一种语言的编程优势之外，这种方法允许查询编译器拓展这些语言结构并优化联邦查询。最后，基础层中本来的挖掘算法提供特性提取、汇总和分类业务，并且可以通过该查询语言来调用这些挖掘业务。而且，将挖掘算法嵌入到基础层中允许查询编译器优化这些查询，它可以实现卓越的性能。
通过通用界面和查询语言来进行综合查询和挖掘的关键优势是数据的可操作性（actionability）。例如，通过结构文本查询和特性提取以及数据库触发器，可以对未知内容的数据进行分析并迅速传送到感兴趣的用户。
工作流、信息处理和商业流程集成。
在连续可用的环境中运行的全球企业需要异步通信和信息处理来开发可扩展和容错的商业应用程序。集成业务层使用工作流引擎来透明调度和管理长时间运行的数据密集型应用程序和自身的功能，它们在数据操作内部集成保证的信息传递。
应用程序界面。应用程序界面层提供允许应用程序接入和管理基础层和集成业务层提供的数据和业务的界面。它支持多种API、查询语言和编程模式以实现最大的灵活性。根据应用程序要求和编程人员的偏好，数据可以根据结构化数据模式来检索，如XML文件，或XML文件分段。关于这些方法的详细信息将在下面介绍。
编程界面。应用程序界面层通过嵌入式SQL、ODBC34和JDBC35，结合使用广泛的编程语言来全面支持传统的数据库编程。这些API包括支持XML数据以及关系数据的扩展36。ODBC和JDBC和其它流行的数据库API本身是同步的，不能很好地适用于处理不持续可用、数据接入中的长延迟或多个信息传送源和目标的数据的应用程序。对于这些类型的应用程序来说，应用程序层提供信息处理和Web业务编程模式，以及一套构建面向异步环境的应用程序的工具。
查询语言。 实践证明，SQL是一种极其强大的检索结构化数据的语言，XQuery作为查询半结构化和未结构化数据的语言。应用程序层支持这两种语言，任何一种语言都可以用于接入基础层视为SQL或XML数据支持的联邦内容。查询可以透明地结合关系表、XML存储的数据以及从外部服务器检索到的数据。对于那些使用SQL来检索XML数据的应用程序来说，该文件或文件分段作为某特定行数据的列值被返回。对于那些选择Xquery来接入关系数据的应用程序来说，应用程序层提供单表或多表的XML视图，查询结果作为XML文件返回，它附带该视图定义的标记。
解决方案
现在我们回到金融服务案例，阐述刚才描述的体系结构如何应对信息集成挑战。图8显示了使用这类平台为投资银行部门构建的门户应用程序。这一门户方便用户接入从外部厂商购买或公司内其它部门制订的市场研究报告，如交易室提供的“晨会（morning meeting）”总结。
图8描绘了纽约交易室生成的XML文件流程，它汇总了晨间报告（morning call）。该文件包括RIXML部分，它提供关于集会的元数据，如提到了那些分析家、企业和行业。 它还包括一个音频剪辑和包含该集会多种语言版本的多份PDF文件。
图8左侧显示收到了晨间报告文件。信息集成平台通过嵌入到编程界面中的异步侦听来接收报告，在收到报告后将立即启动一个工作流程。工作流的第一步是存储最初的XML文件到本身的XML存储中，将关于源、格式和接入权限的信息存储到系统元数据存储中的文件中。工作流的第二步是调用索引和挖掘业务来索引、分类和汇总晨间报告的内容。第三步是提取PDF文件，将它们转发到文件服务器并将这类文件的语言信息记录到系统元数据存储中。最后一步是提取音频剪辑并将它转发到流式媒体服务器以便存储。
图8的右侧阐述接入晨间报告以及多份其它文件，包括其它晨间报告、行业评述和公司报告的门户应用程序。该应用程序发布最近收到的文件的Xquery请求并在Web页面上显示文件汇总。系统元数据的接入控制作为处理该Xquery请求的一部分来进行，因此，只检索应用程序有接入权限的文件。返回到原XML文件的内容由基础层不同的存储和接入组件提供。例如，系统元数据提供关于文件源和结构的信息，文件类型和汇总可以通过工作流程某一步骤提取的挖掘信息来了解。集成引擎起源于与系统元数据和代码页面提供的文件相关的PDF文件修订版本，为其计算URL，门户应用程序使用该URL，通过联邦接入组件来检索文件服务器上的文件。同样，集成引擎为晨间报告的音频剪辑生成一个URL，以便门户应用程序用来精简媒体服务器发送的音频。
请点击看图8金融服务案例的信息集成
Mary A. Roth IBM 软件部，硅谷实验室，555 Bailey Avenue, San Jose, California 95141 (电子邮件：
torkroth@us.ibm.com)。 Roth女士是IBM硅谷实验室电子商务数据库技术部的高级工程师兼经理。她在数据库研发方面拥有12年的工作经验。作为IBM Almaden 研究中心的研究人员和Garlic项目成员，她在全异的数据集成技术及联邦查询优化方面作出了重大的贡献，致力于把Garlic支持转向DB2。Roth女士领导开发人员小组来为Xperanto－IBM面向分布式数据接入和集成的信息集成计划提供一组关键组件。
Daniel C. Wolfson IBM软件部，11501 Burnett Road,Austin, Texas 78758(电子邮件：
dwolfson@us.ibm.com)。Wolfson先生是电子商务数据库技术部的高级技术员工成员兼经理，在分布式计算方面拥有15年以上的工作经验，他的兴趣非常广泛，涵盖数据库、信息处理和事务处理系统。Wolfson先生是信息集成领域的主要设计师，专攻DB2与WebSphere、MQSeries®、工作流、Web业务和异步客户机协议的集成。
James C. Kleewein IBM 软件部，硅谷实验室，555 Bailey Avenue, San Jose, California 95141 (电子邮件：
kleewein@us.ibm.com)。 Kleewein先生是IBM硅谷实验室数据库体系结构、战略和技术领域的著名工程师，他为IBM工作15年了。Kleewein先生的专业技术涵盖广泛的IBM数据管理产品，包括IMS™、DB2/MVS、DB2/390、DB2 Sysplex数据共享、DB2 Spatial Extender、DataJoiner®和DiscoveryLink。Kleewein先生是Xperanto的主要设计师，关注通过向DB2引擎添加XML功能，将DB2的职责从结构化数据存储扩展到结构化和半结构化数据存储。
Constance J. Nelin IBM 软件部， 11501 Burnett Road,Austin, Texas 78758 (电子邮件：
nelin@us.ibm.com)。Nelin女士是IBM数据库先进技术领域的高级技术员工成员。她从1987年开始为IBM工作，专攻数据库应用程序开发支持和工具。Nelin女士负责应用程序开发工具战略、体系结构和数据管理开发，这包括整个DB2系列的应用程序开发支持，涵盖核心关系数据库、联邦数据库、XML、Web业务和信息处理特性领域。
