绿豆.Net

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

走向未来的企业应用集成:从信息、过程到服务

By AMT 夏敬华 编译

企业应用集成在企业信息化应用中始终是一个复杂而又不得不面对的问题。虽然人们在企业应用集成中取得了一些成功的案例,但大多数的集成努力都是有限而又局限的。 比如,我们尚还未能看到数千个应用的紧密耦合。企业应用集成相对于IT领域的大多数技术而言,发展和变化非常迅速。随着集成的要求从单个部门到整个企业,以及更广阔的虚拟企业,应用集成问题也变得越来越复杂。如果说这种集成广度的复杂已经使人头痛,更头痛的是那种集成深度上的拓展。如从数据集成到应用系统集成以及到业务流程的集成,涉及面越来越多,集成重点也愈来愈从技术走向业务。 应该说,很少有企业能够跟上应用集成曲线的延展速度。为了使人们对企业应用集成有个比较全面和深入的认识,透视应用集成曲线变化的本质,本文将介绍目前市场上主流的几种的集成模式,当然这几种集成模式主要是从集成深度的意义上来讲的。

面向信息的集成

此种集成模式聚焦于接口层次的应用和系统间的数据转化和传输,它给了大多数组织一种风险较低的切入企业应用集成的方式,其主要优势是较低的成本(因为在大多数情况下不需要修改应用程序)。

倡导信息集成模式的人将集成视为一种数据流系统,数据可以在文件、数据库以及其它信息库存间流动,可以在应用间通过API(如SAP的R/3 BAPI)流动,也可以在通信中介间流动。因此,实现对数据库、应用程序以及相关服务的接口就成为面向信息集成模式的关键问题。具体来讲,面向信息的集成方法又可以划分为三种类别——数据复制、数据聚合以及接口集成。

数据复制

数据复制方式的目的是为了保持数据在不同数据库间的一致性,而数据库可以是同一厂商也可以是不同厂商的,甚至可以是采用了不同模型和管理模式的数据库。对于数据复制的基本要求是其必须能够提供一种数据转化和传输的基础结构,以屏蔽不同数据库间数据模型的差异。目前市场上有大量此类产品,许多面向数据库中间件的解决方案也同样提供数据复制服务。数据复制服务的基本原理是这样的:在两个或多个数据库之间设置一个软件中介层,在一边,数据从源数据库中被抽取,而在另一边,数据被导入目标数据库。

数据复制方式的优点是其简单性和低成本。但是,当有业务逻辑集成的要求时,这种优势就不能带给它更多的竞争力。如果这种业务逻辑集成需求确实存在,就必须考虑其它的集成方式,即使数据复制方式很简单易行,而且价格低廉。

数据聚合

数据聚合是将多个数据库和数据库模型集成为一种统一的数据库视图的方法。也可以认为,数据聚合体是一种虚拟的企业数据库,它包括了多个实体的物理数据库。虽然这种思想已经出现了一段时间,但其实际应用却还是近期的事。

数据聚合方法在分布的数据库和应用之间放置一个中间件层,该层与每一个后台的数据库用其自带的接口相连,并将分布的数据库映射为一种统一的虚拟数据库模型,而这种虚拟模型只在中间件中存在。应用就可以应用该虚拟数据库去访问需要的信息。同时,该数据聚合软件也可以通过将相关数据映射和导入实体数据库,进行数据库更新。数据聚合方法的优点是其将多种数据类型表示为统一的数据模型,支持信息交换,它能够通过一个良好定义的接口访问企业中任何相连接的数据库,也提供了一种利用统一接口解决面向数据的应用集成问题的良好方法。

接口集成

接口集成方法利用良好定义的应用接口实现对应用包和客户化应用的集成。这种方法以在ERP套件(如SAP, PeopleSoft, and Oracle)的集成中得到广泛应用而闻名,可以说,它是目前得到最广泛应用的集成方法。在面向接口的集成中,集成代理是一个时髦的概念,它通过提供用以连接应用包和客户自开发应用的适配器来实现集成,适配器通过其开放或私有接口将信息从应用中提取出来。另外一些类型的适配器可以和应用通过面向消息的中间件(MOM)、DBMS、文件系统或其它系统和应用间接相连。 有些解决方案通过接口抽象以屏蔽适配器的自然属性,来促进信息交互,从而实现和应用的交互,甚至也可以屏蔽和应用间的信息传输。这种通过接口抽象的方法提供了集成不同类型应用的高效率,它也是面向接口集成方法的主要优势来源。

但是,面向接口的应用集成方法由于缺乏明晰的过程模型,也缺少面向服务的框架结构,使其应用受到了局限。因此,对那种需要复杂的过程自动化或动态服务集成的问题,纯面向接口的应用集成方法一般情况下并不适合,但是,当与面向过程的集成以及面向服务的集成相结合时,面向接口的集成技术将能显示出独特的效率和可维护性,而这一点,恰是其他模型所缺乏的。

图1 给出了面向信息集成方法的三种形式的图示模型。

图1 面向信息的集成方法


面向过程的集成

简单来说,面向过程的集成方法将一个抽象和集中的管理过程置于多个子过程之上,而这些子过程是由应用程序或人工来执行的。面向过程的集成方法按造一定的顺序实现过程间的协调并实现数据在过程间的传输,其目标是通过实现企业相关业务过程的协调和协作实现业务活动的价值最大化。除此以外,面向过程的集成方法还可以减少错误,并且可以通过自动化以往由手工完成的业务过程来加速业务结果在过程中的传递。

总的说来,面向过程的集成逻辑是一种过程流集成的思想,它不需要处理用户界面开发、数据库逻辑、事务逻辑等。事实上,过程逻辑和核心业务逻辑相分离,正是面向过程集成方法的最重要优势的体现,它可以通过改变应用程序和个人之间的信息流,而不改变应用程序本身,使应用更优化地为业务服务。可以说,面向过程的集成方法是一种技术,更是一种策略,它可以提升组织整合独立应用为更高层次的业务过程服务的能力,而这种整合可以是组织内的,也可以是组织间的。图2给出了面向过程集成方法的示意。

图2 面向过程的集成

在实施面向过程的集成时,由于其实施对象会采用不同的元数据、平台以及业务应用类型,因此面向过程的集成技术必须具有足够的柔性,能够和不同的相关技术实现集成,如面向消息的中间件、面向事务的中间件、面向接口的集成代理等。在结构上,面向过程的集成方法在面向接口的集成方案之上,定义了另外过程逻辑层;而在该结构的底层,应用服务器、消息中间件提供了支持数据传输和跨过程协调的基础服务。可以说,面向过程的集成在某种程度上是一种对业务层次上的各种服务的抽象,因此,很多提供集成代理、消息中间件以及应用服务器的厂商也开始提供用于业务过程集成的产品。

面向过程的集成和面向接口的集成之间有很多不同,以下是一些主要的不同点:
(1)一个过程集成的实例通常会跨越多个接口集成的实例应用;
(2) 面向接口的集成通常聚焦于多个系统间信息的交换,而不涉及其内部过程的可见性;
(3)面向过程的集成由过程模型作为引擎,驱动信息在应用间的流动;
(4)面向接口的集成更多地用于那些战术性问题或者短持续时间的事务集成问题;
(5)业务过程集成更多地用于战略性问题,通过一个抽象的业务模型,利用业务规则以决定系统如何交互以及如何实现业务价值。


面向服务的集成

面向服务的集成在最近受到人们越来越多的重视,但它并不是一种新方法。我们已经知道了几种将应用在应用服务层次绑定的方法,如框架模型、分布对象以及其它一些机制,这些方法在今天仍然在应用。但是,Web服务的概念促使人们重新观察面向服务的集成方法,也使很多IT组织重新考虑其应用集成策略。

面向Web服务的集成模型可以实现动态的应用集成和大范围的业务逻辑共享,这种目标是通过整合业务层服务来实现的,具体体现为一种对共享对象上“方法”的调用。这种“方法”通过一些基础设施服务为多个系统所共享,而且这种“方法”可以位于集中服务器、分布服务器、Internet上,并以标准的“Web服务”机制来提供。

图3 面向服务的集成

对于“Web服务”来讲,有几个重要的标准,如UDDI(Universal Description, Discovery and Integration)、WSD(Web Services Description Language)、SOAP(Standard Object Access Protocol),如图3所示。Web服务模型简明易懂,比如有一个应用需要用到一个Web服务—关税计算,只需定位这个服务,创建服务请求,并向服务发出请求,接下来就去处理回应和等待服务了。

在定位关税计算服务时,需要用到UDDI标准,它定义了定义发布和定位有关Web服务信息的机制。UDDI可以通过名称或目录来定位服务,一旦定位了所需服务,UDDI就返回服务的地址以及如何使用它的描述(由WSDL描述)。

在创建一个有效的关税计算服务申请时,需要有关接口语法、语意以及唤醒机制的信息。WSDL标准定义了一种描述上述特征的通用性方法。基于被UDDI服务返回的有关WSDL的描述, 应用就能够格式化其请求,这样就使关税计算服务能够理解和处理该请求。

发送请求需要用到SOAP标准,SOAP定义了消息的标准结构,包括Web服务的请求和响应,并能够对收发双方的通信过程(以HTTP形式)进行管理。除此以外,SOAP还提供了一种使服务安全通过公司防火墙的标准方法。

总的来说,Web服务模型和标准提供了一种在Internet环境下使用远程应用服务的通用方法,为一种新的集成方法铺平了道路,这种方法可以称为“合成应用”, 它通过聚集多个简单的应用和服务而实现复杂的功能。在具体方法上,开发者可以通过将过程逻辑和对各种分离应用和服务的接口相结合,从而实现一种新的合成接口,最终创建出所谓的合成应用。

虽然这种面向服务的集成方法很引人注目,但它相比于面向信息和过程的集成,比较昂贵。因为面向信息和过程的集成方法一般并不需要对目标应用进行修改,而面向服务的集成方法则不,除了要修改应用逻辑以外,还要对修改的应用进行测试、集成和重配置,工作成本很大。而这种工作对面向应用的集成方法难以避免,无论是对传统的集成技术如CORBA,还是对Web服务方法。事实上这也是许多公司仍选择在信息层次进行集成的原因之一。

目前有些厂商提出了面向服务集成的新思路,他们力图使应用修改和更新的工作最小化,并提供一种Web服务的抽象视图,以使面向服务的集成方式在成本上能够使人接受。这其中的关键是要将面向服务、接口以及过程的集成模型加以整合利用,比如,面向接口的集成提供对于现有应用的集成方法而不修改它,同时利用标准的Web服务接口对现存应用进行封装,而面向过程的集成则使这种具体的服务定位、申请创建、服务唤醒细节能够被高层的抽象过程模型所屏蔽。所以,通过将三种集成模型有机整合,将能够达到更好的集成效率,同时降低集成成本。

当然,当一个公司已经具有了良好的面向信息和过程的集成基础时,面向服务的集成项目将更可控,也更有效;相反,当还没有现存的信息和过程集成基础时,投资Web服务集成将很难成功。所以,对于企业而言,“i before e”,即“integration before e-business”将是一个重要的法则。任何一个想真正成功迈向E业务的企业,集成的基础结构将是一个非常重要的前提条件。

posted on 2008-01-23 15:06  杜军  阅读(1041)  评论(0编辑  收藏  举报