技术开发 频道

数据服务:连接SOA与元数据管理的桥梁

【IT168 专稿】

    最近的经济危机使投资收益最大化成为基本的战略准则。IT资产的投资也不例外。面向服务架构(SOA)由于其敏捷与重用性,能够从当前的IT资产中快速开发出具有高商业价值的应用,因此在其中扮演着极其重要的角色。

    然而,在任何SOA应用发挥这些IT资产的商业价值之前,企业必须首先能够了解并自由支配这些资产,而这正是元数据管理的基本原则。

    企业必须在管理元数据所消耗的资源及在SOA中利用元数据所消耗的资源之间找到一个平衡点。要达到这一目的,企业就必须解决以下问题:

    * 重点应该放在哪里?

    * 企业如何实现最快地获得最大商业价值?

    * 能否找到一个非常好的点,使元数据管理与SOA能一致地提高IT与业务的收益?

    管理元数据——比以往任何时候更为重要

    元数据的重要性不必多说。并且,随着元数据从被动式信息仓储发展到成为自动化开发的关键内容,其重要性正与日俱增。商业智能(BI)和数据仓储(DW)就是利用面向数据的元数据的成功应用;业务流程管理(BPM)利用的是面向过程的元数据;IT管理利用的是面向IT资产的元数据。最近,基于SOA的新开发和遗留资产合并也产生了新的元数据需求。由于元数据的这种爆炸式增长,企业也要花费越来越多的资源了解、分类并管理元数据。

    今天的各种元数据管理应用和技术已经发生了相当大的变化。这主要是由三个因素造成的。第一个因素是上面提到的各种元数据类型。比如,数据仓库中用于定义数据提取、转换和加载(ETL)脚本的元数据,和用于定义、管理复杂订单-收款业务流程中越区切换的元数据有着很大的不同。各种不同的用途不仅影响着数据的类型和所管理的属性,还影响着变更的频率和变更所造成的影响。

    第二个因素是IT企业固有的分工制度。不同的团队分别进行不同种类的工作,比如B2B、后台应用、BI等。另外,不同的团队也工作在不同的应用套件层上:比如数据库、工作流、报表等。结果就是,各个团队主只了解其工作相关的元数据,而对其他用户的元数据却了解甚少。

    第三个因素是软件开发商式的元数据管理。由于最近几年来元数据重要性的提升,应用与工具供应商也在其核心产品中添加了元数据扩展,并且随之诞生了许多元数据管理的专业厂家。这些厂家各自以独特的角度解决元数据管理问题,产生许多截然不同的元数据管理工具,最终造成一系列新的元数据集成问题。

    数据服务——管理与利用元数据的非常好的点

    由于元数据类型繁多,用户和工具也多种多样,很容易造成元数据管理上的困难。不过,重要的一点是不能走上歧路。企业要有选择地进行管理,把重点放在具有最高收益的IT资产上,使用能够最快实现回报的元数据管理方法。对于SOA来说,把重点放在数据资料上通常意味着能够获得非常好的、最迅速的回报。

    为什么是数据?首先,数据通常是SOA开发项目的最大瓶颈。大多数新应用是以当前系统的数据为基础。这种数据复杂、多样化并且涉及整个企业。比如,一个新的SOA客户服务应用可能包括来自打包应用(比如SAP)的账务数据、数据仓储的历史交易数据、XML格式和HTTP文件形式的门户服务数据等等。各种来源都有自己的访问机制、语法、安全等——所有这些都会拖慢开发的进度。

    根据许多分析师的经验,那些与虚拟化、提取、组合和传输数据有关的服务(通常称为数据服务)是SOA开发中最耗费精力的一部分。要保证在企业SOA中实现这些服务的互通性和重用性,唯一途径就是良好的元数据管理。

    元数据管理就是管理与数据有关的数据。现在,面向模式的建模工具不但简单易用,还能有效开发的初步构建和后续升级。另外,20年前的那些简单的图表生成工具也已经发展成为先进的开发环境。现在,强大的连接器可以解决相当一部分跨系统的语法和转换问题,这在以前通常需要更细粒度的元数据和建模才能解决。

    通过现代的数据服务中间件,可以轻松地创建能够生成可用数据服务的数据模式,并被开发人员应用到SOA应用的开发项目中。通过从既有的元数据管理和建模工具中引入这些模式,并通过当前数据源生成新的模式,开发人员可以迅速地进入工作状态。他们还可以使用拖拽工具整合各种资源以增加数据的价值。此外,他们可以把复杂性抽象化,从而为消费者简化模式。性能通常是一个让人担忧的问题,而更好的数据服务中间件则可以优化队列,并提供一系列缓存技术。一旦模式完成,开发人员可以自动生成SQL视图和符合SOA标准的数据服务,这些都可以在多个开发项目中重用。如果将来底层资源发生变化,这种方式的松耦合特性也使得模型和受影响的数据服务的升级变得简单易行。

    数据服务层——如何将元数据管理转化为业务敏捷

    由于合并、新产品、新市场、顺应性规则等情况的存在,业务必然是持续变化的,这使SOA成为一种受偏爱的开发方式。然而,由于既有数据的复杂性和大量的项目积压,IT部门仍要拼尽全力才能赶上节奏。企业要怎么做才能让业务应用赶上业务变化呢?可以通过当前元数据生成数据服务,实现所需的新的应用数据,从而帮助IT实现更快的响应速度。

    从架构的角度来看,这里的关键是一种三层的松耦合方式。如图1所示,数据服务联合形成可重用的服务中间层,或称为数据服务层。这一层将业务应用层从底层的源数据层分开。这样,开发人员便可以实现所需的灵活性,以最有效的方式处理各层问题,并在应用、模式或底层数据源发生变化时具有快速处理的敏捷性。

    

图1 数据服务层

    数据服务层为数据读取、相关数据整合、数据抽象化,以及以数据到应用的传送提供了统一的方式。通过应用非常好的实践技术和自动化关键数据服务功能,比如虚拟化、抽象和联合,可以极大地提高开发人员的效率和速度。

    数据虚拟是一种很重要的功能。在SOA中,数据服务中间件把许多不同的数据类型绑到一个统一的、企业范围的数据模型(包括模式和内容)中。这种虚拟数据层是由从元数据中生成的松耦合数据服务构成的。数据服务层是重要的SOA组成部分,因为它使当前系统的构建更容易,并且无需考虑地理位置、评估方法、语法等问题。因此,SOA可以从源系统中读取并使用设计和标准不规范的数据,而排除这种多数据类型的障碍正是实现SOA敏捷性的关键。

    数据抽象是另一个可以由数据服务中间件实现的重要功能。在数据服务层,开发人员可以模拟并生成各种实体“简单易用”的版本,包括客户、订单、发货、出货单和收据等。对于这些重要的实体部分,开发人员还可以额外提供一些必要的、更详细的功能。比如,在“订单”类中,可以包含开始下订单、已完成订单、有纠纷的订单等。由于数据服务层使应用与数据的物理实现分离,开发人员也不会再被数据复杂性所困扰,因此他们可以集中精力做自己份内的工作——考虑应用程序如何使用数据。这不仅可以实现更优秀的应用,还能提高实现所需应用的速度。

    最后,对于应用来说,最困难的工作之一就是把各种类型的数据组合起来以实现全方位的视图。以一个客户服务应用中的数据组合为例,即组合从订单输入应用得到的客户销售数据、金融系统的客户发票数据,以及运输公司的客户退货数据,以得到一个单独的视图。数据服务中间件的数据组合功能可以对多个运行中的数据及历史数据提供安全访问,将其组合成更完整、更有意义的信息,为一系列的应用用户提供方便。查询优化和缓存技术可以满足对高性能的需求,而无需硬件合并。

    所有数据的元数据——一步一个脚印

    在统一标准的数据服务层实例化整个企业的数据模式是一项需要太多前期投资、太长回报期,从而难以下手的巨大工程吗?就像SOA一样,元数据管理也不是一项全有或全无的绝对性投资。在决策过程中要考虑的问题主要有:

    * 应该从什么应用开发项目着手?

    * 如何最大程度地重用数据服务?

    * 如何寻找资金将项目逐渐扩大到整个企业?

    虽然各个企业的情况不尽相同,但是研究那些成功的数据服务革新案例可以让我们学到一些有用的经验。首先,在这些项目中,数据都是最大的问题。换句话说,如果能包括复杂的模式、读取方式等,抽象的服务可能会带来最大的价值。其次,能够处理多系统应用数据的SOA项目比单系统方案要好,因为通常单系统方案的数据建模、访问和传输能力过剩,几乎没有整合的余地。第三,只要是可能经历变更的项目,不管是源层或消费层,都更有必要使用分层结构。最后,对于那些需要即时获取数据的应用,数据服务所固有的按需提供数据(DOD)的特性相对需要额外数据存储中间件的物理数据合并方式来说具有更大的优势。

    随着时间的推移、项目的发展、模式的变化和数据服务的更新,数据服务层就会慢慢扩大到企业范围。一些企业已经证明,单是重视并以新的方式重用现有数据资产、重用数据服务就可以获得足够多的数据服务中间件的投资资金。

    使元数据投资的收益最大化

    许多企业在以各种方式向SOA转型,这些SOA实现方式都涉及数据。多数企业也已经在数据仓库或企业集成团队中启动面向数据的元数据管理。根据SOA方案进行元数据管理能给企业带来显著的业务与IT效益。

    数据服务是连接SOA与元数据管理的桥梁。通过数据服务中间件,企业可以在短短几个星期内从被动式的元数据建模转向主动式的可重用数据服务开发。这不仅可以加速SOA开发、提高业务敏捷性,而且每一种新模式、新服务的实现都能为其带来更高的投资回报率。

0
相关文章