面向服务体系结构中的信息管理.docx
《面向服务体系结构中的信息管理.docx》由会员分享，可在线阅读，更多相关《面向服务体系结构中的信息管理.docx（17页珍藏版）》请在冰豆网上搜索。
面向服务体系结构中的信息管理
面向服务体系结构中的信息管理
2005年4月
学习信息管理、它对面向服务的体系结构（Service-OrientedArchitecture，SOA）的重要性以及信息管理和SOA之间的关系。
然后我们研究将这些具有挑战性的问题和重新设计应用到SOA中的信息管理的优点。
本文中（本系列文章包含两部分，本文是第一部分），作者将信息管理分为几个不同的服务，并且提供了对于这些服务的高级概述。
本文的目标读者是架构师、数据建模者、数据库管理员以及那些想要利用信息管理功能的开发者，他们将该功能用于基于SOA的建模、架构、设计以及实现。
引言
信息管理，既包括了数据管理，还包括了内容管理，它是面向服务的体系结构（SOA）的基本构建模块。
信息管理提供了一种可以在不同种类信息源（请见参考资料部分中的随需应变的操作环境的体系结构概述）之间表示、访问、维护、管理、分析以及集成数据和内容的方法。
在信息管理中存在多种不同的功能，包括：
∙ExtractTransformationLoad（ETL）
∙联盟（Federation）
∙数据放置功能（例如替换和隐藏）
∙数据建模功能
∙搜索功能
∙分析功能
可以将这些功能组合成复合组件，并且它们作为可复用的及可调用的Web服务来提供。
检查这些功能是如何帮助构建SOA以及它们在SOA上下文中是如何交互的，这点非常重要。
如果您对它们的意图和数值表述不清楚，那么很容易丢失大的图片，并且会错误地选择信息管理和体系结构。
一个将信息管理合并成更大的、整个SOA图片的预见性计划可以帮助您解决一些常见的不足，例如数据solos（独立的数据源）、数据的不一致性以及未使用的信息资产。
SOA多于Web服务
信息管理服务处理SOA的信息组件。
但是，当人们想到SOA的概念时，他们通常会首先想到Web服务。
很少人会越过Web服务编程模型而想到信息管理的潜在方面。
然而，信息管理支持SOA，因为它解决了其中一个最重要的公司资产——结构化格式和非结构化格式的信息。
信息的体系结构是信息管理的关键部分，它使得SOA更加智能且可管理（请见参考资料部分中的SOA中的EII角色）。
最后，如果没有坚固和强大的信息管理环境，SOA将受到局限，并且几乎没有端到端的业务集成和转换的可能性。
SOA中的信息管理重在企业信息集成（EnterpriseInformationIntegration，EII）——该技术集成了结构化和非结构化的信息源使它们可以如同单一的信息源一样被处理。
通常，结构化信息包括了相关的、XML、或者表格数据，例如电子制表。
传统上说，在数据管理的标签下，管理结构化的信息要落后些。
相反，非结构化信息包括了免费的文本报告、文档、Web页面、生命科学数据、音频、视频等等。
对于非结构化信息的管理一般被分类为内容管理。
EII可以提供对数据和内容的统一观点，这样就简化了对潜在的信息服务的表现和访问。
SOA中的信息管理也扩展了EII使其包括ETL、数据放置、数据恢复以及类似功能。
创建声音信息的体系结构和设计的部分流程是要权衡不同方法之间的利弊，以便您可以将合适的技术应用到解决客户问题上。
信息管理如何启用SOA
SOA中的信息管理，尤其是EII，强调将服务层与数据的物理实现之间的关系分离。
这种分离技术通常由中间件提供，例如IBM®WebSphere®信息集成器（以前为DB2®信息集成器）。
这样的中间件可以大大减少用户所有权的总花费和信息集成的复杂度。
合理使用EII可以生成潜在的不同类数据的集成化视图，服务很容易与这些数据协调工作，这样有助于从物理数据的更改中将服务层隔离出来。
这种隔离层对于SOA来说非常重要，这是因为它使得数据库厂商的产品、OS平台、信息位置、数据格式以及物理数据模型透明化。
为了从应用程序中得到信息源的松耦合视图，SOA中的信息管理访问并且聚合了不同类的数据和内容源（这种性能称为联盟），因此当它们显示给用户时，它们就好像是单独的数据库或者内容源。
因为SOA中的信息管理担当应用程序和数据源之间的中间设备层，所以集中了用于数据连通性、数据转换规则和数据映射的编程逻辑，并且许多应用程序（服务用户）可以复用它们。
此外，SOA中的信息管理提供了强大的扩展性，它允许应用程序和用户不仅可以在企业内部访问信息，而且还可以穿过企业和业界边界来访问信息。
这种完全端对端级的业务和信息集成赋予业务很大到灵活性和适应性，这为成为随需应变的业务铺平了道路。
最后，SOA中的信息管理是基于信息标准的，这些标准的范围从数据、内容和元数据到元模型以及元-元模型（我们将在本文的后面详细讨论），例如Unicode、XML以及MetadataObjectFacility（MOF）。
作为Web服务的提供者，IBMDB2UDB创建了一个对SOA开发和部署非常友好的环境。
例如，Web服务对象运行时框架（WebServicesObjectRuntimeFramework，WORF）装载了用于Linux、UNIX、Windows®和z/OS的DB2UDB，它提供了环境，在其中可以很容易创建访问DB2数据库的简单Web服务。
用简单的术语来说，就是可以使用包含一系列操作的XML文件来定义对DB2数据的访问。
这些操作可以是SQL操作（选择、插入、更新、删除操作，或者对存储过程的调用），也可以是XML集操作（生成或者存储XML文件）。
作为Web服务的用户，IBMDB2Web服务客户的用户定义的功能（UDF）启用数据库应用程序来使用SQL声明直接调用Web服务。
您可以使用WebSphereStudioApplicationDeveloper来轻松地将现有的WSDL接口转换成DB2表格或者分级的UDF（请见参考资料部分中的用于DB2信息集成的XML）。
将信息管理重新构建到SOA中
我们已经描述了信息管理是如何启用SOA的。
现在我们来看一看信息管理如何能同时从SOA的原理中获益。
面临的挑战
尽管出现了很多信息标准，例如XML、Unicode以及UML，但是许多数据源仍然使用私有的数据格式、元数据以及元模型，这是由我们一直以来的习惯形成的。
将不同数据源集成在一起需要大量的工作，并且通常是通过构建端对端的数据和应用程序集成来实现的。
为了说明该问题在行业中的严重性，目前行业中有超过250个厂商在输入端提供了用于不同种数据源的ETL工具，并在输出端提供了分析工具（请见参考资料部分中的“Java元数据接口（JMI）规范”）。
ETL常用于从源系统中提取数据，将数据转换为与目标系统相兼容的格式，然后将其装载到目标系统中，例如数据仓库或者数据市场。
考虑到ETL仅仅是EII的一小部分，所以您可以想象端对端集成问题的范围和严重性。
在内容方面，这些具有挑战性的问题令人生畏。
内容管理的解决方案来自不同的历史体系，而且大部分是纵向分析并且是基于部门角度分析的。
例如，用于法律部门的文件管理、用于IT部门的知识管理，或者是用于营销部门的Web内容管理。
在目前的内容管理市场中，经常使用来自不同厂商的产品来提供这些解决方案。
即使是单独的厂商，产品之间的功能也是经常重叠的。
随着时间的推移，分离不同种类解决方案的界限已经越来越模糊。
例如，当前的业务智能需要实时性数据来获得对市场定位的完全理解，市场定位促使ETL厂商扩展实时性数据性能。
另一方面，数据联盟越来越需要数据的转换性能来提高数据的质量和灵活性。
在很多方面我们正在看到一种聚合趋势——一些实例是数据和内容集成的聚合（特别是在XML的上下文中）、ETL和联盟的聚合、知识管理和Web内容管理的聚合。
当企业要做出一些改动时，需要面对巨大的挑战。
以下是企业必须要考虑的一些项目：
∙放弃从纵向和部门的角度来考虑问题
∙将现有的信息管理功能转换为可复用的服务
∙集成大量的不同类信息源
∙减少开发费用
∙扩展功能
这些挑战并不是很容易解决的，因为厂商想保护他们当前的IT资产和用户基础。
企业内部的提倡者同时也必须在内部出售SOA构想，然后向基于标准规范的方向前进。
从用户的角度来看，将逐步渗透IT资产的复用作为组织文化的一部分，这是非常艰巨的任务。
优点
对于那些采用SOA作为信息管理的用户来说，优点非常多。
在其他部分之中，基于SOA的信息管理有以下功能：
∙允许系统的IT资产复用。
数据建模、映射以及转换功能是最复杂并且是集中劳力的流程。
当前的点对点信息集成不容易导致IT资产的复用。
∙加快开发速度，并且减少了开发和维护的费用。
∙使用更大的成本效益来提高数据和内容连接性和互用性。
∙创建了附加的基于完全集成化信息的业务视野。
例如，Gartner预言了分析非结构化内容的能力将会导致产生新的业务机会。
∙保护用户在很不稳定的信息管理市场里的投资，在那里经常会出现合并和收购。
∙简化了企业计算模型的总体复杂度。
信息管理提供的服务
前面不仅陈述了使用SOA来重新设计信息管理的挑战和益处，而且也陈述了信息管理如何启用SOA，让我们先来检查信息管理所提供的服务，例如ExtractTransformationLoad（ETL）、联盟、建模、搜索和分析。
以下的清单阐述了一个信息管理堆栈，它是对信息管理所提供的服务进行分类的逻辑视图或者框架，该信息管理基于它们的价值提议：
安全性、协作性、可利用性、可管理性和信息消费：
∙安全性（Security）：
这是应用程序访问基于who-can-see-what策略的不同种类数据源的入口点。
∙协作性（Collaboration）：
这是在开发小组环境中必不可少的部分，因此您需要工作流和版本控制。
∙服务质量（QualitiesofService，QoS）：
它包括了实现信息的可用性、性能、数据吞吐量以及数据的一致性或者正确性。
联盟、ETL、缓存、复制和事件的发布功能的目的都是为了与QoS的目标相匹配。
∙可管理性（Manageability）：
因为信息是存储组织的智能和复杂度的方式，所以要使用（结构化和语义的）建模、（数据）概要分析和（数据和内容）质量disciples以使信息更加便于管理。
∙消费（Consumption）：
此外，前面工作的全部意图是需要有操作者（包括机器）来使用它；因此信息消费位于该堆栈的顶部。
没有单独的产品提供所有这些服务。
本文最后列出了实例工具。
总体上来说，这些服务在SOA下创建了一个完整的信息管理框架。
理想的情况是每个服务都专门写一页来进行描述其权利，但是我们这里只提供了概述。
图1：
SOA中的信息管理
SOA中的信息管理全面地观察了企业组织内部以及贯穿整个组织的信息资产。
尽管多种技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分；也没有将解决方案划分为部门的视图。
SOA中的信息管理与早期更严格的数据和内容管理方法相比，最关键的区分标志是它可以为在合适的时间、合适的地点并且有正当理由而需要它的任何用户提供服务。
正如我们前面所述，通常由中间件提供在信息管理堆栈中所列出的服务。
尽管需要抑制成本花费和部署时间，但是企业可以选择从初始状态将这些服务构建到他们的应用程序中。
最好的实践就是理解业务的需求，选择一个可以提供完好的信息集成和最完备的信息管理解决方案的厂商，然后构建几个选择性的服务来弥补丢失的部分，甚至将某些的复杂服务外包给第三方信息服务提供者，如我们将在本系列文章的下一部分中的实例研究所述。
结束语
您已经看到了信息管理是如何在SOA的上下文中工作的，并且阐明了它们之间的关系。
您同时也检查了将信息管理重新构建到SOA中的益处和随之而来的挑战。
2005年7月
利用信息管理的强大功能来用于基于面向服务体系结构（Service-OrientedArchitecture，SOA）的建模、构架、设计和实现。
在本文的栈视图中，展示了信息管理提供的各种服务，并有每种服务的详细描述。
作者从元数据管理和元数据集成的重要性说起，再转到信息管理所提供服务的检验，然后是SOA案例学习。
最后，作者将列出一些与所讨论服务相关的工具。
引言
在本文的后半部分中，我们将对每种特定服务进行更深入的讨论，例如：
∙元数据管理
∙提取、转换和加载（ExtractTransformationLoad，ETL）
∙联合
∙数据安置（如复制和缓存）
∙数据建模
∙搜索
∙分析
之后，我们将学习使用SOA来验证数据质量的案例，并在最后列出用于各种服务的工具清单。
在阅读完本文之后，您将能更有效的利用信息管理的功能，来构建健全且均衡的SOA，并进行信息和业务集成，避免常见错误，比如孤立的数据筒仓（silo）、数据不一致和未使用的信息资产等。
SOA不仅仅是Web服务
图1展示了信息管理提供的服务分类逻辑视图，这些服务是基于以下方面进行分类的：
∙安全性
∙协作
∙可用性
∙可管理性
∙信息消耗
虽然没有哪种单独的产品能提供以上所有的服务，但将这些服务合在一起就可以创建SOA的完整信息管理框架。
特别值得注意的是，某些文章将元数据管理置于信息管理栈的底部，在本文中我们认为，元数据管理是渗入其他服务并与其他服务紧密联系的。
事实上，SOA是元数据驱动的构架（参见参考资料部分的文章“MetadataEvolutionManagementinYourSOA"）。
因此，我们将在本文的后半部分从元数据管理开始说起。
图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与相关的契约文档或是图象相结合。
∙查询需要实时数据，例如股票报价、现有存货目录
数据复制和事件发布
数据复制使数据的副本从一个位置移到另一个位置。
目标位置可以是集中的位置，例如数据仓库，也可以是网络上另一个分布式位置。
在网格环境中，复
升级会员 