利用信息管理的强大功能来用于基于面向服务体系结构（Service-Oriented Architecture，SOA）的建模、构架、设计和实现。在本文的栈视图中，展示了信息管理提供的各种服务，并有每种服务的详细描述。作者从元数据管理和元数据集成的重要性说起，再转到信息管理所提供服务的检验，然后是SOA案例学习。最后，作者将列出一些与所讨论服务相关的工具。
引言
在本文的后半部分中，我们将对每种特定服务进行更深入的讨论，例如：
·元数据管理
·提取、转换和加载（Extract Transformation Load，ETL）
·联合
·数据安置（如复制和缓存）
·数据建模
·搜索
·分析
之后，我们将学习使用SOA来验证数据质量的案例，并在最后列出用于各种服务的工具清单。在阅读完本文之后，您将能更有效的利用信息管理的功能，来构建健全且均衡的SOA，并进行信息和业务集成，避免常见错误，比如孤立的数据筒仓（silo）、数据不一致和未使用的信息资产等。
SOA不仅仅是Web服务
图1展示了信息管理提供的服务分类逻辑视图，这些服务是基于以下方面进行分类的：
·安全性
·协作
·可用性
·可管理性
·信息消耗
虽然没有哪种单独的产品能提供以上所有的服务，但将这些服务合在一起就可以创建SOA的完整信息管理框架。特别值得注意的是，某些文章将元数据管理置于信息管理栈的底部，在本文中我们认为，元数据管理是渗入其他服务并与其他服务紧密联系的。事实上，SOA是元数据驱动的构架（参见参考资料部分的文章“Metadata Evolution Management in Your SOA"）。因此，我们将在本文的后半部分从元数据管理开始说起。
图1：SOA中的信息管理
元数据管理
元数据、元模型以及元－元模型
最常见的元数据定义是关于数据的数据——其实并不然。根据规范的不同，元数据所指的含义也将不同。基本上，元数据是关于数据的结构（语法）和含义（语义）的信息。元数据结构化方法的例子有关系数据库管理系统（RDBMS）目录、Java库目录和XML DTD和schema。这些每个都定义了数据是如何表示和使用的。从语义的角度来说，元数据提供了数据的含义。例子包括用数据字典、注释或本体论（ontology）来描述。
此外，还有用于内容管理的实例和类的元数据。实例元数据只是储存在内容管理元数据储存库中的数据，并引用存储在别处的对象，例如文档、Web页面、音频和视频文件。分类和索引中的条目也同样被认为是实例元数据。类元数据，从某种角度来说，和RDBMS目录和XML schema意义相同，用来描述实例元数据的结构。
元模型（也称元－元数据）定义了元数据的结构和语义。标准元模型的例子包括Unified Modeling Language（UML）和Common Warehouse Meta-model（CWM）。元－元模型层由元－元数据的结构和语义描述组成。目前正试图提供一种可以描述所有其他信息模型的通用语言。Meta Object Facility（MOF）是元－元模型的一个标准（参见参考资料部分）。
图2：MOF元数据构架
对元数据的生产者来说，遵循元模型、元数据接口、元－元模型和查询语言方面的标准是非常重要的。通过这些标准，才能实现最大限度的互操作性，并可以服务于更多的元数据消费者，例如数据仓库、分析和建模工具。SOA正是依靠这些标准来实现生产者和消费者之间的动态匹配、监控BPEL流，以及增强对IT资源和业务流程的跟踪能力。
元数据管理注意事项
当我们重新设计元数据管理时，由于XML的普及，它显然是元数据的缺省数据格式。对于单个供应商或是组织来说，通常首选是集中方式，用来实现元数据资产的重用，并减少开发的工作量，避免出现混乱。同样，标准就是这个首选的方法。例如，IBM?使用开放源代码的Eclipse Modeling Framework（EMF）作为通用的元数据集成技术。EMF为工具和运行时提供了元数据集成。因此，在EMF基础上开发的所有软件都可以共享其它应用程序的通用方法。在理想的环境中（在短期内实现可能比较困难），元数据储存库可以储存所有的元数据构件。服务由信息管理体构，例如在需要时，可以调用信息管理提供的服务（比如SSO、ETL、联合、质量、搜索、版本控制和工作流）以获取数据、内容和元数据管理。
对于XML储存库而言，有两种常用的用来储存XML元数据的储存机制。分别为RDBM和固有的XML储存库。每种储存机制都有优缺点。起决定作用的因素包括性能、灵活性、带宽、互操作性、用户定义数据类型的支持以及数据质量的保证等。
无论对于供应商、企业或是行业级别而言，在进行元数据管理时，联合的方法都是更加实用的。虚拟的元数据储存库允许应用程序通过单个API访问并聚集不同种类的元数据源。物理元数据构件可以被储存在其初始的位置，也可以通过ETL/replication/cache方法来改进性能和元数据安置。在不同元数据源之间进行自动发现、映射和转换对改进元数据的可管理性都是非常重要。
数据、内容和元数据管理之间的关系
一方面，元数据使程序间可以互相对话（实际上，供应商可调用它的元数据储存库SuperGlue）。另一方面，元数据管理的需求与数据和内容管理是十分类似的。元数据管理需要提供关于安全性、协作、QoS和可管理性的相同的服务类型。元数据管理还要将SSO、ETL、联合、质量、搜索、版本控制、工作流和储存持久性结合在一起。元数据管理在自动操作和编制（orchestration）方面的需求比数据和内容管理更多，因为元数据所服务的对象主要是计算机程序。
不管怎样，资产重用和服务编制可以通过在基于SOA且架构完善的信息管理基础上构建元数据管理来实现。这就证明了将信息管理重新设计为基于SOA的可重用构件的重要性。
元数据集成的难题
前面已经说过，集成元数据比集成数据和内容更加复杂。许多因素都增加了元数据集成的难度。这些因素包括：
·元数据无处不在，且在许多情况下对用户是不可见的。
·许多产品中的元数据和元模型都有其专有格式，特别是内容管理。
·在内容管理中，向内容中添加元数据。许多内容都缺乏元数据来进行集成和搜索。
·元数据集成相对数据和内容集成来说，需要更高级别的自动化和编制。这就依次需要更高级别的自动发现、转换、映射和语义理解。
·为了避免失去当前客户，供应商还可以选择保持客户的专有元数据格式。
·转换到元数据标准（例如MOF）需要时间和工作量。
元数据集成的业务价值
SOA在很大程度上是元数据驱动的构架。要理解元数据集成的高级别业务价值，让我们先进行全方位的概览。图3阐明了随需应变业务上下文中元数据集成的重要性。基于信息标准，元数据可以实现无缝信息交换。给出良好集成的元数据后，信息可以在由操作系统、编程语言、位置和数据格式组成的边界之间自由流动。因此元数据可以被认为是信息集成的“大脑”。此外，信息集成使得可以进行业务集成，业务集成既可以是跨企业中各部门的，也可以是跨企业边界的。它提供以下内容：
·通过数据仓库或联合的方式，提供单一且完整的客户、伙伴、产品和业务视图。
·通过使用分析服务，使业务性能管理更加便利。
·通过广泛的信息访问来增强业务应用程序。
·通过持续的信息服务实现业务流程转换。
最后，业务集成是随需应变业务的基础之一。通过使用IT技术服务于业务目标（而不是相反），使业务集成与之前的Enterprise Application Integration（EAI）区别开来。因此，说元数据集成是随需应变业务的“大脑”一点都不夸张。
图3：元数据集成是随需应变业务集成的大脑
高级元数据集成价值的例子包括：
·有助于来自不同源的数据/内容集成。
·缩短新应用程序的上市时间，并允许更快速的应用程序集成
·改善企业内部或企业之间的业务集成流程
·通过完整的集成信息分析，提供了全新的认识
·通过变更管理和预测分析，进行结果分析
数据和内容联合：分散式方法
联合的概念是指将资源集看作单个资源来进行查看和操作，且保持其自治（对当前的应用程序或系统影响极少或没有影响）和完整性（不会破坏当前应用程序或系统中的数据或内容）。不用说，自治和完整性是联合的两个重要前提。
自20世纪90年代后期，数据联合已经作为与集中方法截然不同的一种方法而出现了。在分散方法中，使用了数据市场（mart）和仓库。数据联合力图将数据放在其原始位置上，并创建虚拟数据库。类似地，最近出现的内容联合可以用来访问并聚集不同的内容源。这些分散的方法相比集中化方法而言，减少了数据和内容冗余、带宽、储存、实时同步以及额外的管理费用。对分布式信息源的实时访问同样为业务智能带来了新的性能，这应该遵循法定和管理需求。对于开发人员来说，数据联合减少了为不同的数据源编写和维护自定义API的需求，以及对高度专门技能的需求。
对于数据联合而言，最需要关注的就是其性能。要改进性能，联合需要经常使用缓存、物理查询表（MQT）以及分布式查询优化和执行。高速缓存和MQT在联合的服务器上创建并管理表，这些服务器可以是目标联合数据源的全部或是其中的一部分。作为一种cutting-edge工具，IBM WebSphere? Information Integrator考虑了以下方面：
·源数据（例如基数或是索引）的标准统计
·数据服务器性能（例如连接特性和内置功能）
·数据服务器容量
·I/O容量
·网速（请参阅参考资料部分的IBM Redbook，“DB2II: Performance Monitoring, Tuning and Capacity Planning Guide”）
ETL：集中方法
提取－转换－加载（Extract-transform-load，ETL）是用于数据集成的最古老的技术之一，且和数据储存和业务智能紧密结合。该方法可以用于数据合并、迁移和传播。ETL工具从一个或是多个数据源中提取、转换和加载数据至其它目标。ETL曾经一段时间是信息集成的主要方法且至今仍旧运用十分广泛。与直接的提取和加载操作不同，转换是最复杂的部分。因为在此过程中需要对数据进行理解、转换、聚集和计算。由于高费用、较慢的周转周期以及数据源中不完整的信息集而使ETL和数据仓库的优势大打折扣。
集中式和分散式方法互补，将两者结合在一起会产生很多的优势。
集中式方法包含了以下一些方面：
·访问性能或可用性需求需要集中数据。
·当前需求要求时间点一致性，例如业务关闭。
·需要进行复杂转换，以实现数据的语义一致性。
·集中化方法通常用于生产应用程序、数据仓库和操作数据存储库。
·集中化方法通常由ETL或是复制技术来管理。
分散式方法包含了以下需要考虑的事项：
·源系统的访问性能和负载的提高可以降低整体实现的费用。
·当前需求需要数据的最新副本。
·数据安全性、许可限制或行业规则限制了数据传输。
·分散化方法可以结合复合格式数据，例如客户ODS与相关的契约文档或是图象相结合。
·查询需要实时数据，例如股票报价、现有存货目录
数据复制和事件发布
数据复制使数据的副本从一个位置移到另一个位置。目标位置可以是集中的位置，例如数据仓库，也可以是网络上另一个分布式位置。在网格环境中，复制和缓存服务用来创建Placement Management Service以满足服务质量(QoS)目标。根据访问模式和消费应用程序位置的不同，Placement Management Service 通过创建缓存或是副本（参见参考资料部分中的“Towards an information infrastructure for the grid”一文）来提高相应时间以及信息可用性。在Web应用程序环境中，当数据或是内容已经准备好被发布用于公共消费时，数据和内容复制通常用来将数据或内容从分段服务器（通常只是管理员使用的服务器）转移到生产服务器。分段数据管理使组织能够更好的控制信息流和信息的生命周期。例如，一个Web站点支持多国语言。当一段数据或内容元素需要在网站上发布之前被翻译，则首先需要将其传给分段服务器。只有在被翻译完并被管理员许可以后，才可以复制给生产服务器并进行发布。
复制可以与集中式或分散式方法共同使用。ETL和数据复制间主要的区别是，ETL通常在应用了数据过滤和转换规则后，将数据移动到集中位置，这要花费更长的时间，并移动更多的数据。数据复制移动的数据集就小很多，可以更自动化的方式移动到集中的或是分散的位置。数据复制可以对数据进行实时或是近实时访问。ETL的主要目的是分析并监控数据，并生成业务智能。但数据复制的目标更多的与性能、数据管理和数据可用性相关。最后，ETL和数据复制可以互补，换句话说，可以使用数据复制功能更快地将数据移动到数据市场或是存储库，ETL中的数据转换功能可以提供数据复制领域更大的灵活性和更高的数据质量。为了重用不同工具的逻辑，需要有易于调用且松耦合的信息服务。
和ETL以及数据复制不同，事件发布并不清楚数据的去向以及如何使用数据。源表的变更将以XML格式或是其它数据格式发布到消息队列。应用程序负责检索已发布的事件并采取适当的操作，例如触发业务流程或在将数据应用到目标数据源之前对数据进行转换。松耦合架构将服务提供者和消费者分离，并允许数据事件独立于应用程序。
逻辑数据和语义信息建模
逻辑数据建模是软件开发的最佳实践之一，也是当开发组织在时间和预算压力之下很容易被忽视的地方。虽然在内部开发过程中经常忽略逻辑数据建模，但组织经常购买获得企业资源规划（Enterprise Resource Planning，ERP）、客户关系管理（Customer Relationship Management，CRM）或是其他类型的包。结果是，许多版本的数据模型引用了组织内的同一个事物，且每个数据源都有自己的数据模型和元模型。例如，引用了客户的不同的项，CRM称其为customer，记账系统中称其为client，而销售系统中称之为buyer，这种情况并不少见。教科书和理论家力图从逻辑企业数据模型开始，再转至物理数据模型（例如实体关系图）、代码生成和开发，但是在实际中顺序却经常颠倒过来。
在实践中，组织常分阶段构建、购买或是获取数据库，且数据保持被隔离的状态。有时这些组织认识到需要对数据进行集成。那么接下来要怎样实现呢？通常会钻研大堆的文档、成千上万的代码行以及海量的数据，来发现其生产和消费的信息类型，更不用说这些组织要发现和记录各种数据模型和业务流程之间的相互关系了。在这种情况下，自动数据发现和概要工具可以加快这些流程，并减轻执行这些任务的复杂性。许多组织在最后将得到逻辑企业数据模型，这样单独的系统就可以被映射到公共逻辑模型上。转换在一些案例中需要用到，例如货币间的转换。最终，物理数据模型被映射到企业数据模型——即企业共享的公共逻辑数据模型。如果企业数据模型在一开始就被设计为模型驱动架构（Model Driven Architecture）的一部分，那么该模型就可以最大限度的发挥其优势。不过，逆向的工程步骤也是非常有价值的。企业数据模型的主要优势在于：
·提供企业信息资产的概览。
·增强使用IT技术来支持业务流程的实践。
·减少企业信息集成（Enterprise Information Integration，EII）、企业应用程序集成（Enterprise Application Integration，EAI）以及数据存储的费用和风险。
·提供对数据、元数据和元模型的基于资产的重用。
·提高数据和元数据质量。
·便于业务分析员、数据建模者、开发人员和数据库管理员之间的通信。
