研究 SOA 中信息管理的不同方法.docx

研究 SOA 中信息管理的不同方法.docx

《研究 SOA 中信息管理的不同方法.docx》由会员分享，可在线阅读，更多相关《研究 SOA 中信息管理的不同方法.docx（14页珍藏版）》请在冰豆网上搜索。

研究SOA中信息管理的不同方法

利用信息管理的强大功能来用于基于面向服务体系结构（Service-OrientedArchitecture，SOA）的建模、构架、设计和实现。

在本文的栈视图中，展示了信息管理提供的各种服务，并有每种服务的详细描述。

作者从元数据管理和元数据集成的重要性说起，再转到信息管理所提供服务的检验，然后是SOA案例学习。

最后，作者将列出一些与所讨论服务相关的工具。

　　SOA不仅仅是Web服务

　　图1展示了信息管理提供的服务分类逻辑视图，这些服务是基于以下方面进行分类的:

　　安全性

　　协作

　　可用性

　　可管理性

　　信息消耗

　　虽然没有哪种单独的产品能提供以上所有的服务，但将这些服务合在一起就可以创建SOA的完整信息管理框架。

特别值得注意的是，某些文章将元数据管理置于信息管理栈的底部，在本文中我们认为，元数据管理是渗入其他服务并与其他服务紧密联系的。

事实上，SOA是元数据驱动的构架。

　　图1:

SOA中的信息管理

　　元数据管理

　　元数据、元模型以及元-元模型

　　最常见的元数据定义是关于数据的数据——其实并不然。

根据规范的不同，元数据所指的含义也将不同。

基本上，元数据是关于数据的结构（语法）和含义（语义）的信息。

元数据结构化方法的例子有关系数据库管理系统（RDBMS）目录、Java库目录和XMLDTD和schema。

这些每个都定义了数据是如何表示和使用的。

从语义的角度来说，元数据提供了数据的含义。

例子包括用数据字典、注释或本体论（ontology）来描述。

　　此外，还有用于内容管理的实例和类的元数据。

实例元数据只是储存在内容管理元数据储存库中的数据，并引用存储在别处的对象，例如文档、Web页面、音频和视频文件。

分类和索引中的条目也同样被认为是实例元数据。

类元数据，从某种角度来说，和RDBMS目录和XMLschema意义相同，用来描述实例元数据的结构。

元模型（也称元-元数据）定义了元数据的结构和语义。

标准元模型的例子包括UnifiedModelingLanguage（UML）和CommonWarehouseMeta-model（CWM）。

元-元模型层由元-元数据的结构和语义描述组成。

目前正试图提供一种可以描述所有其他信息模型的通用语言。

MetaObjectFacility（MOF）是元-元模型的一个标准。

　　图2:

MOF元数据构架

　　对元数据的生产者来说，遵循元模型、元数据接口、元-元模型和查询语言方面的标准是非常重要的。

通过这些标准，才能实现最大限度的互操作性，并可以服务于更多的元数据消费者，例如数据仓库、分析和建模工具。

SOA正是依靠这些标准来实现生产者和消费者之间的动态匹配、监控BPEL流，以及增强对IT资源和业务流程的跟踪能力。

　　元数据管理注意事项

　　当我们重新设计元数据管理时，由于XML的普及，它显然是元数据的缺省数据格式。

对于单个供应商或是组织来说，通常首选是集中方式，用来实现元数据资产的重用，并减少开发的工作量，避免出现混乱。

同样，标准就是这个首选的方法。

例如，IBM®使用开放源代码的EclipseModelingFramework（EMF）作为通用的元数据集成技术。

EMF为工具和运行时提供了元数据集成。

因此，在EMF基础上开发的所有软件都可以共享其它应用程序的通用方法。

在理想的环境中（在短期内实现可能比较困难），元数据储存库可以储存所有的元数据构件。

服务由信息管理体构，例如在需要时，可以调用信息管理提供的服务（比如SSO、ETL、联合、质量、搜索、版本控制和工作流）以获取数据、内容和元数据管理。

　　对于XML储存库而言，有两种常用的用来储存XML元数据的储存机制。

分别为RDBM和固有的XML储存库。

每种储存机制都有优缺点。

起决定作用的因素包括性能、灵活性、带宽、互操作性、用户定义数据类型的支持以及数据质量的保证等。

　　无论对于供应商、企业或是行业级别而言，在进行元数据管理时，联合的方法都是更加实用的。

虚拟的元数据储存库允许应用程序通过单个API访问并聚集不同种类的元数据源。

物理元数据构件可以被储存在其初始的位置，也可以通过ETL/replication/cache方法来改进性能和元数据安置。

在不同元数据源之间进行自动发现、映射和转换对改进元数据的可管理性都是非常重要。

数据、内容和元数据管理之间的关系

　　一方面，元数据使程序间可以互相对话（实际上，供应商可调用它的元数据储存库SuperGlue）。

另一方面，元数据管理的需求与数据和内容管理是十分类似的。

元数据管理需要提供关于安全性、协作、QoS和可管理性的相同的服务类型。

元数据管理还要将SSO、ETL、联合、质量、搜索、版本控制、工作流和储存持久性结合在一起。

元数据管理在自动操作和编制（orchestration）方面的需求比数据和内容管理更多，因为元数据所服务的对象主要是计算机程序。

　　不管怎样，资产重用和服务编制可以通过在基于SOA且架构完善的信息管理基础上构建元数据管理来实现。

这就证明了将信息管理重新设计为基于SOA的可重用构件的重要性。

　　元数据集成的难题

　　前面已经说过，集成元数据比集成数据和内容更加复杂。

许多因素都增加了元数据集成的难度。

这些因素包括:

　　元数据无处不在，且在许多情况下对用户是不可见的。

　　许多产品中的元数据和元模型都有其专有格式，特别是内容管理。

　　在内容管理中，向内容中添加元数据。

许多内容都缺乏元数据来进行集成和搜索。

　　元数据集成相对数据和内容集成来说，需要更高级别的自动化和编制。

这就依次需要更高级别的自动发现、转换、映射和语义理解。

　　为了避免失去当前客户，供应商还可以选择保持客户的专有元数据格式。

　　转换到元数据标准（例如MOF）需要时间和工作量。

　　元数据集成的业务价值

　　SOA在很大程度上是元数据驱动的构架。

要理解元数据集成的高级别业务价值，让我们先进行全方位的概览。

图3阐明了随需应变业务上下文中元数据集成的重要性。

基于信息标准，元数据可以实现无缝信息交换。

给出良好集成的元数据后，信息可以在由操作系统、编程语言、位置和数据格式组成的边界之间自由流动。

因此元数据可以被认为是信息集成的“大脑”。

此外，信息集成使得可以进行业务集成，业务集成既可以是跨企业中各部门的，也可以是跨企业边界的。

它提供以下内容:

　　通过数据仓库或联合的方式，提供单一且完整的客户、伙伴、产品和业务视图。

　　通过使用分析服务，使业务性能管理更加便利。

　　通过广泛的信息访问来增强业务应用程序。

　　通过持续的信息服务实现业务流程转换。

　　最后，业务集成是随需应变业务的基础之一。

通过使用IT技术服务于业务目标（而不是相反），使业务集成与之前的EnterpriseApplicationIntegration（EAI）区别开来。

因此，说元数据集成是随需应变业务的“大脑”一点都不夸张。

　　图3:

元数据集成是随需应变业务集成的大脑

高级元数据集成价值的例子包括:

　　有助于来自不同源的数据/内容集成。

　　缩短新应用程序的上市时间，并允许更快速的应用程序集成

　　改善企业内部或企业之间的业务集成流程

　　通过完整的集成信息分析，提供了全新的认识

　　通过变更管理和预测分析，进行结果分析

　　数据和内容联合:

分散式方法

　　联合的概念是指将资源集看作单个资源来进行查看和操作，且保持其自治（对当前的应用程序或系统影响极少或没有影响）和完整性（不会破坏当前应用程序或系统中的数据或内容）。

不用说，自治和完整性是联合的两个重要前提。

　　自20世纪90年代后期，数据联合已经作为与集中方法截然不同的一种方法而出现了。

在分散方法中，使用了数据市场（mart）和仓库。

数据联合力图将数据放在其原始位置上，并创建虚拟数据库。

类似地，最近出现的内容联合可以用来访问并聚集不同的内容源。

这些分散的方法相比集中化方法而言，减少了数据和内容冗余、带宽、储存、实时同步以及额外的管理费用。

对分布式信息源的实时访问同样为业务智能带来了新的性能，这应该遵循法定和管理需求。

对于开发人员来说，数据联合减少了为不同的数据源编写和维护自定义API的需求，以及对高度专门技能的需求。

　　对于数据联合而言，最需要关注的就是其性能。

要改进性能，联合需要经常使用缓存、物理查询表（MQT）以及分布式查询优化和执行。

高速缓存和MQT在联合的服务器上创建并管理表，这些服务器可以是目标联合数据源的全部或是其中的一部分。

作为一种cutting-edge工具，IBMWebSphere®InformationIntegrator考虑了以下方面:

　　源数据（例如基数或是索引）的标准统计

　　数据服务器性能（例如连接特性和内置功能）

　　数据服务器容量

　　I/O容量

　　网速（请参阅参考资料部分的IBMRedbook，“DB2II:

PerformanceMonitoring,TuningandCapacityPlanningGuide”）

　　ETL:

集中方法

　　提取-转换-加载（Extract-transform-load，ETL）是用于数据集成的最古老的技术之一，且和数据储存和业务智能紧密结合。

该方法可以用于数据合并、迁移和传播。

ETL工具从一个或是多个数据源中提取、转换和加载数据至其它目标。

ETL曾经一段时间是信息集成的主要方法且至今仍旧运用十分广泛。

与直接的提取和加载操作不同，转换是最复杂的部分。

因为在此过程中需要对数据进行理解、转换、聚集和计算。

由于高费用、较慢的周转周期以及数据源中不完整的信息集而使ETL和数据仓库的优势大打折扣。

　　集中式和分散式方法互补，将两者结合在一起会产生很多的优势。

　　集中式方法包含了以下一些方面:

　　访问性能或可用性需求需要集中数据。

　　当前需求要求时间点一致性，例如业务关闭。

　　需要进行复杂转换，以实现数据的语义一致性。

　　集中化方法通常用于生产应用程序、数据仓库和操作数据存储库。

　　集中化方法通常由ETL或是复制技术来管理。

　　分散式方法包含了以下需要考虑的事项:

　　源系统的访问性能和负载的提高可以降低整体实现的费用。

　　当前需求需要数据的最新副本。

　　数据安全性、许可限制或行业规则限制了数据传输。

　　分散化方法可以结合复合格式数据，例如客户ODS与相关的契约文档或是图象相结合。

　　查询需要实时数据，例如股票报价、现有存货目录

数据复制和事件发布

　　数据复制使数据的副本从一个位置移到另一个位置。

目标位置可以是集中的位置，例如数据仓库，也可以是网络上另一个分布式位置。

在网格环境中，复制和缓存服务用来创建PlacementManagementService以满足服务质量（QoS）目标。

根据访问模式和消费应用程序位置的不同，PlacementManagementService通过创建缓存或是副本来提高相应时间以及信息可用性。

在Web应用程序环境中，当数据或是内容已经准备好被发布用于公共消费时，数据和内容复制通常用来将数据或内容从分段服务器（通常只是管理员使用的服务器）转移到生产服务器。

分段数据管理使组织能够更好的控制信息流和信息的生命周期。

例如，一个Web站点支持多国语言。

当一段数据或内容元素需要在网站上发布之前被翻译，则首先需要将其传给分段服务器。

只有在被翻译完并被管理员许可以后，才可以复制给生产服务器并进行发布。

　　复制可以与集中式或分散式方法共同使用。

ETL和数据复制间主要的区别是，ETL通常在应用了数据过滤和转换规则后，将数据移动到集中位置，这要花费更长的时间，并移动更多的数据。

数据复制移动的数据集就小很多，可以更自动化的方式移动到集中的或是分散的位置。

数据复制可以对数据进行实时或是近实时访问。

ETL的主要目的是分析并监控数据，并生成业务智能。

但数据复制的目标更多的与性能、数据管理和数据可用性相关。

最后，ETL和数据复制可以互补，换句话说，可以使用数据复制功能更快地将数据移动到数据市场或是存储库，ETL中的数据转换功能可以提供数据复制领域更大的灵活性和更高的数据质量。

为了重用不同工具的逻辑，需要有易于调用且松耦合的信息服务。

　　和ETL以及数据复制不同，事件发布并不清楚数据的去向以及如何使用数据。

源表的变更将以XML格式或是其它数据格式发布到消息队列。

应用程序负责检索已发布的事件并采取适当的操作，例如触发业务流程或在将数据应用到目标数据源之前对数据进行转换。

松耦合架构将服务提供者和消费者分离，并允许数据事件独立于应用程序。

　　逻辑数据和语义信息建模

　　逻辑数据建模是软件开发的最佳实践之一，也是当开发组织在时间和预算压力之下很容易被忽视的地方。

虽然在内部开发过程中经常忽略逻辑数据建模，但组织经常购买获得企业资源规划（EnterpriseResourcePlanning，ERP）、客户关系管理（CustomerRelationshipManagement，CRM）或是其他类型的包。

结果是，许多版本的数据模型引用了组织内的同一个事物，且每个数据源都有自己的数据模型和元模型。

例如，引用了客户的不同的项，CRM称其为customer，记账系统中称其为client，而销售系统中称之为buyer，这种情况并不少见。

教科书和理论家力图从逻辑企业数据模型开始，再转至物理数据模型（例如实体关系图）、代码生成和开发，但是在实际中顺序却经常颠倒过来。

　　在实践中，组织常分阶段构建、购买或是获取数据库，且数据保持被隔离的状态。

有时这些组织认识到需要对数据进行集成。

那么接下来要怎样实现呢?

通常会钻研大堆的文档、成千上万的代码行以及海量的数据，来发现其生产和消费的信息类型，更不用说这些组织要发现和记录各种数据模型和业务流程之间的相互关系了。

在这种情况下，自动数据发现和概要工具可以加快这些流程，并减轻执行这些任务的复杂性。

许多组织在最后将得到逻辑企业数据模型，这样单独的系统就可以被映射到公共逻辑模型上。

转换在一些案例中需要用到，例如货币间的转换。

最终，物理数据模型被映射到企业数据模型——即企业共享的公共逻辑数据模型。

如果企业数据模型在一开始就被设计为模型驱动架构（ModelDrivenArchitecture）的一部分，那么该模型就可以最大限度的发挥其优势。

不过，逆向的工程步骤也是非常有价值的。

企业数据模型的主要优势在于:

　　提供企业信息资产的概览。

　　增强使用IT技术来支持业务流程的实践。

　　减少企业信息集成（EnterpriseInformationIntegration，EII）、企业应用程序集成（EnterpriseApplicationIntegration，EAI）以及数据存储的费用和风险。

　　提供对数据、元数据和元模型的基于资产的重用。

　　提高数据和元数据质量。

　　便于业务分析员、数据建模者、开发人员和数据库管理员之间的通信。

　　语义信息建模（本体）不属于逻辑数据建模，它对数据的语义（含义）和关系建模。

它合并了多个知识领域的词汇（术语和概念）。

语义信息建模可以出色地解决许多难题，例如以下问题：

　　信息集成

　　模型转换

　　解释

　　数据净化

　　搜索

　　导航

　　文本理解

　　文档准备

　　语音理解

　　问答

　　数据概要（Dataprofiling）

　　数据概要是发现以下方面的流程:

　　数据格式

　　模式

　　特性

　　规则

　　隐含关系

　　数据概要同样提供了很多的优点，包括:

　　改善组织对数据的理解。

　　有助于电子数据管理（ElectronicDataManagement，EDM）。

　　便于数据映射和转换。

　　提高数据质量。

　　构建性能调整的基线。

　　协助语义建模。

　　数据概要旨在更好的理解信息并创建关于对象的更多元数据。

　　数据、内容和元数据质量

　　数据质量将影响企业信息管理策略的成功与否，企业信息管理策略决定了其业务集成策略的成败。

数据质量问题被认为是数据储存项目失效的主要原因之一。

低质量的数据会导致误传的决策、无效的操作和错失机遇，并且有时还会受到来自组织或市场的惩罚。

数据质量并非华而不实，它已经成为业务的关键操作要素。

　　数据质量问题的例子如下:

　　丢失所需域的数据

　　不一致的数据条目

　　不正确或不准确的数据条目

　　由于数据质量工作固有的复杂性，一些组织选择将这些工作外包给第三方服务提供商。

我们将在本文后面部分的案例学习中看到。

　　内容质量经常被部分忽视，这是因为评估内容质量比评估数据质量更困难。

毕竟内容是非结构化的，且质量标准更加主观和随意。

内容质量通常不包含在技术项目范围之内。

从组织的角度来说内容质量并未得到重视。

但是，在SOA环境中，因为SOA不固定的特性而使内容质量变得更加重要。

如果错误数据或是质量次的内容没有及时发现，就会到处传播。

内容质量标准由于内容类型的不同而有所区别，但是评估内容质量还是有一些共同的标准，如以下所示:

　　关联

　　及时

　　截止时间

　　内容确认

　　等级

　　副本

　　链接检查

　　由于对元数据管理能力需求的增长，元数据质量最近受到更多的关注。

改进数据质量的技术，例如标准化、概要、审查、净化、转换和确认，都可用来改进元数据质量。

　　强数据类型是跨不同的编程语言和硬件确保XML数据值一致性的关键。

但是，当前XML技术只允许单个文档的schema确认，却没有一种有效的方法来跨不同的schema和数据源（比如在关系数据库和OO数据类型工具之间）验证数据类型（包括用户定义的数据类型）并实施语义强类型。

仅仅XML文档类型定义（DTD）或schema的标准化（许多行业试图用这种标准化来作为该问题的解决方案）是不够的，因为当需要在多个行业之间集成数据时（这是随需应变业务的一个基本需求。

），XMLDTD或schema验证、语义一致性和兼容性方面的问题仍旧存在。

　　搜索和查询

　　在企业搜索中，搜索分许多类型:

关键字、布尔值、范围、多层面元数据（facetedmetadata）、语义、自然语言和参数化。

不论用哪种搜索，目的都是为了提供统一、相关并排序的结果集，从而可以快速且方便的访问信息。

为便于搜索，可以使用索引（indexing，请不要与关系数据库中的索引混淆）来索引非结构化内容（例如Web页面、电子邮件数据库或是文件系统）的关键字、概念和实例元数据，使这些内容可以被搜索和检索。

关系数据库也可以被编入索引，以进行更快和更灵活的搜索。

　　虽然许多组织认识到集成结构化和非结构化信息的重要性，但目前的搜索结果仍旧互不相干。

用户想要的是指向潜在相关信息的一系列链接。

用户不得不对搜索结果慢慢的浏览检验，以找到所需的信息并与其最初的查询目的联系在一起。

这基本上是手动的流程。

我们认为迫切需要研究使用搜索和查询在数据和内容之间实现一项查询，一组结果集。

　　数据库通常都自带搜索功能。

最常见的搜索功能是使用SQL和XQuery之类的查询语言。

用数据库搜索来检索结构化且严格匹配的数据十分管用，但这需要对查询结构和数据模型十分熟悉和了解才行。

数据库搜索的用户大都是开发人员或是数据库管理员。

另外，数据库搜索不适合于相关排序、模糊搜索和多关键字。

因此，数据库搜索的使用受到了很多限制。

为实现高性能、灵活性以及相关排序等，一些搜索引擎与数据库直接相连，从数据库提取数据并生成索引。

一个例子就是IBMWebSphereOmniFind。

分析

　　在先前ETL部分我们已经阐明，数据仓库将数据合并到中央位置以确保更好的进行决策、跨部门报告和数据挖掘。

传统的分析包括报告、数据挖掘、仪表板（dashboard）、记分卡和业务性能管理。

随着竞争日趋激烈，操作变得越来越复杂，规则也随着更加严格。

组织需要实时访问不同的数据源来做以下改进:

　　使用集成信息预测市场趋势。

　　更好的了解客户。

　　提高操作效率。

　　确保遵循规则。

　　获取新知识。

　　所有这些趋势使得对信息管理分析能力的需求不断增加。

分析变得越来越重要。

例如，如果销售商知道现有客户的合同、服务经验和其行业趋势、其竞争者和客户，他（或她）就可以更好地为客户定制专门的销售建议。

最近，分析经常需要在不同的信息源间进行信息集成。

例如，要评估质量，汽车制造商需要将事故报告（存在文档管理系统内）、经销商的修理记录（存在关系数据库内）、司机的风险因素以及环境因素（存在知识管理系统内）相关联。

在未来，通过分析将能够更加智能化的访问并关联不同的信息源的信息，从而提供新的市场洞察和业务决策。

　　相关服务

　　以下服务被称为“相关”服务，并不是因为它们对于信息管理而言不重要，而是因为他们对于业务流程和应用集成来说十分常见。

　　SSO、访问控制和审查

　　单点登录（SSO）到不同信息源、访问控制、审查对信息的查看和修改，这些共同构建了信息管理安全环境的基础。

SSO对用户提出您是谁的问题，访问控制则提出您可以做什么，审查随时跟踪您已完成的操作。

SSO的优点很多:

减少用户受挫的可能、降低开发工作量并提高效率。

访问控制确保只有拥有正确权限的用户才能访问数据和内容。

一些业务需要非常复杂的访问权限管理，例如DigitalRightsManagement。

审查服务为数据和内容提供了额外的保障。

查看、插入、修改和删除信息操作都能被审查并被报告。

随着对安全性和规则灵活性的需求不断增长，SSO、访问控制和审查服务的结合为企业信息管理打下坚实的基础。

　　工作流和版本控制

　　工作流和版本控制都设计为促进团队环境中的协作。

在通过版本控制建立一致点时，数据、内容和元数据管理、应用程序代码开发和流程都需要工作流，从而允许人们进行协作，以便之后将这些一致点返回给版本控制。

工作流将用户、流程和信息链接在一个系统中。

系统的每个部分——人、流程和信息——都是高度交互的，且它们之间的交互甚至更加动态。

例如，一家公司编写了一个程序使每个雇员都可以提交自己对任何主题的建议。

根据建议类别的不同（信息），这些建议将被不同的人发送、评审和处理（流程，人）。

因此，需要一个高度健全且合适的工作流来处理不能预料的情况。

一旦开发了这样的工作流服务，不用的应用程序可以对其进行调用，这些应用程序包括文档管理、HR系统或者知识管理。

　　门户

　　业界分析家预测，结合了Web服务的企业门户将未来的十二个月内实现。

门户集成了应用程序和信息，并通过统一的视图将其呈现给最终用户。

由于EII提供了抽象层，开发人员可以访问并汇集不同的信息源、维护代码并实现性能和安全性需求，而无需编写自定义适配器。

因此，应用程序开发可以节省大量的时间、花费和技能需求，且门户用户可以轻松访问各种广泛的信息。

最重要的是，可以对端到端业务流程进行轻松且快速的集成。

　　案例学习:

数据质量服务实例

　　信息管理栈中的企业搜索、数据质量与验证，以及分析等服务通常是外购的不错选择。

SOA下的信息管理框架确立了一个新的业务模型，该业务模型越来越受到使用者的欢迎。

让我们看一个案例学习，该案例通过SOA提供了数据验证服务，这种服务也是一种数据质量服务。

　　为了防止出错和欺诈行为，或是为了遵循相关法律和规定（比如Sarbanes-Oxley），许多电子商务公司需要实时检验地址、电话号码以及社