利用信息管理的强大功能来用于基于面向服务体系结构（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”）

1.jpg