一种基于SOA架构的EAI研究与设计
发布时间:2015-07-07 09:29
摘 要 本文针对企业分布式、异构应用系统的集成问题,探讨了基于soa架构的设计思想和相关技术,通过对soa中几个关键技术问题的深入分析,提出了一种基于soa架构的企业eai解决方案,并以一个简单的应用案例说明了该解决方案的设计与实现过程。最后,概括总结了基于soa架构进行企业eai的关键和优势所在。
关键词 soa;eai;web服务;工作流;企业服务总线
图3 订单处理流程图
在订单处理流程中,首先要根据库存状况由系统生成订单;订单生成后将被发送到审批部门进行审批;审批通过的订单交由财务部门做财务处理;最后交给采购部门,采购处将和生产厂家进行对话,建立一个事务性质的采购流程并完成采购业务。 整个流程的基本组成单元是一些基于xml作为消息传输载体的web服务。这些中立的、松耦合等特点的web服务,遵循国际统一标准,打破了分布式系统的异构屏蔽性,将它们所在的遗留系统的信息释放出来,提供良好契约的接口并按照一定的逻辑规则参与到企业的业务流程当中去;同时,这些web服务具备良好的可复用性,可以灵活的被其它业务流程所调用。 这样,原本分布式、异构、僵化的it底层系统,就被分解为一组组透明、中立、灵活的web服务;这些服务将作为“原材料”提供给上层的流程层或表现层。以下是上述流程中部分web服务示例: ●order service - 用来生成订单的服务。 ●approval service - 对订单进行审批,记录审批意见和结果。 ●finance service - 用来对订单进行财务计算、处理,并生成票据、报表的服务。 ●purchase service - 采购物品;包含三个事务单元服务:reserve goods、pre deal和report build,分别用来进行资源预占、预交易和报表或票据生成等。 整个订单流程大部分工作由计算机自动处理,并由人参与其中进行监督管理。这种业务流程处理方式,打破了各部门系统之间的异构屏蔽,实现了库存处、财务部门、采购部门甚至企业外部生产厂家之间的信息传递自动化。在订单处理过程中,如果其中一个环节出现问题,流程将会中断回到初始状态并发送中断日志给管理人员。同时,在业务发生变动时,该流程模型会灵活、迅速的做出新的调整,保持业务流程与it基础架构步调一致,解决了以往企业有心开发新业务却无力改变it现状的难题。 可以说,基于soa实现企业的eai,就是在一定程度上实现了流程的集成、信息的集成和人的集成。
1 引言
eai(enterprise application integration,企业应用集成)是指将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。 现代企业经常要面对内部重组、收购和兼并、与上下流合作伙伴建立新的产业链等经营方式的变革。经营方式的变革必然驱动着业务上的改变,而现代企业的业务模型又与it有着密切的关联。因此,企业的it系统就要面对异构应用的整合、重复/零碎的数据合并、新的业务流程的建立等诸多挑战。 eai通过建立底层结构,使异构、分布式的系统、应用和数据源之间的信息交互成为可能,完成企业内部或企业与企业之间(b2b)的诸如 erp、crm、scm、数据库、数据仓库以及其它重要的系统之间无缝地数据共享和应用沟通的需要。wWW.lw881.com2 问题的提出
传统的企业应用集成是建立在一个由中间件组成的底层基础平台上,各种“应用孤岛”、“信息孤岛”通过各种适配器连接到一个总线上,然后再通过message queuing实现各个应用之间的交流。这种集成存有很大的客户化程度,不具备统一的行业协议标准,消耗大量的咨询和服务费用,而且后期的管理和维护复杂混乱。在业务上有失灵活性和可扩展性,难于快速适应现代企业业务敏捷性的需求;在技术上容易受制于传统分布式对象中间件技术存在的局限性(如corba,dcom,java rmi之间的互操作性差)。因此,本质上这是一种点对点、紧耦合的集成。 随着xml技术的推广应用,web service技术、中间件技术的日趋发展完善和面向服务架构(soa)的兴起,一种新的基于soa架构的eai方法相应而出。该方法可以很好的解决以上传统eai集成面临的诸多问题,对现有的分布式、异构系统进行更有效地集成。3 soa相关关键技术
soa(service-oriented architecture,面向服务的架构)是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)的模型,它将应用程序的不同功能单元(称为服务)通过定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。3.1 web服务
如上所定义,soa围绕的核心内容即:“服务”;web服务(web service),就是一种实践soa的具体方法之一。web服务将软件模块看成一种internet/intranet上的实体单元,借助xml实现分布式和异构平台的信息集成;其目标是实现不同系统间跨平台、跨编程语言的互操作性。 通俗的来说,web服务就是将已有的应用、数据、内容文档等通过打包,合理包装成符合国际统一标准的程序模块。web服务的接口和执行明确分离,开发者可在任何软件系统上调用该服务,而不必再为了与服务交互去了解其内部执行的具体细节,即:与服务内部执行的平台、编程语言等无关。 3.1.1 web服务的体系结构 web服务的体系结构如图1所示。 图1 web服务的体系结构 (1)服务提供者创建服务的实体,通过向注册库发布服务接口信息以供服务请求者发现和访问服务。 (2)服务注册库对已注册的服务进行分类,并展示给服务请求者;服务注册库也提供服务的搜索功能。 (3)服务请求者通过查询存储有服务信息的注册库,发现所需服务的接口信息;并根据接口说明信息使用特定的传输协议与服务绑定来执行服务功能。 基本的web服务体系结构包含了soap、wsdl、uddi等协议支持服务请求者和服务提供者进行交互,以及用于服务发布和发现的规范。服务提供者通常用wsdl来描述它所提供的服务,然后将该wsdl描述发布。服务请求者可以通过uddi来获取wsdl描述,并通过向服务提供者发送一个soap消息来请求执行服务。 3.1.2 web服务特征 一个标准的web服务,在设计、实现和服务管理中应当具备以下关键特征: 1)松耦合性 松耦合性包括接口耦合、技术耦合和流程耦合等[2]。 接口耦合,指服务请求者和服务提供者之间的依赖性最小化;服务应该封装所有的内部实现细节,服务请求者只需根据已发布的服务契约和服务水平协议来使用一个服务即可。 技术耦合,指服务的请求者和提供者不存在对特定技术、产品或开发平台的依赖性。 流程耦合,指服务不应与具体的业务流程相关,以便被重用于多种不同的流程和应用。 2)良好的服务契约 服务契约是进行服务共享与重用的基础,是降低接口耦合的主要机制。一个良好的服务应该明确定义服务的功能,以及如何用一种可互操作的方式调用它。 3)对服务请求者有意义 服务和服务契约必须在一个对服务请求者有意义的抽象层次上进行定义,以确保不会限制将来的服务使用或服务实现,确保与上层的业务领域紧密结合,确保对服务请求者屏蔽服务的内部技术细节。 4)开放、基于标准的 web服务技术与传统的分布式集成技术本质上的区别,即在于它的开放性和基于统一标准,真正做到“独立于实现服务的硬件平台、操作系统和编程语言”。 为了尽可能的提供业务与技术效益,服务还应尽量具备一些次要特征,如:自治性、可复用性、可组合性、动态发现性、单实例、无状态性等。 5)服务粒度 根据web服务接口的功能大小,可大致将其分为粗粒度的接口和细粒度的接口。粗粒度接口其功能可能是执行某一个具体业务,细粒度的接口可能是执行该业务的具体几个方法。 从业务敏捷性角度考虑,服务组件的粒度越细,日后被直接复用的可能性就越大,对于日后服务的组合和流程的编排的优势就越明显;从系统性能的角度考虑,服务组件的粒度越细,组件的数量就越多,而组件之间复杂的通信方式和传输层海量的消息数据必将严重降低系统性能。可见,确定服务粒度的大小需因地制宜。 一般来说,在企业内部推荐使用细粒度组件接口,便于灵活定制个性化的服务;企业之间推荐采用粗粒度组件接口,以优化系统性能和确保请求者调用服务的一致性[3]。 在系统设计和实施过程中,使用细粒度的组件服务提供基本的功能单元,并通过某种可配置的方法,动态组装、编排这些细粒度组件为粗粒度组件服务;在业务变化涉及到组件服务的内部服务时,又能够通过修改配置,重新组装细粒度服务组件,来重构粗粒度服务[4]。 基于web服务的工作流技术,即是一种将细粒度组件服务整合或编排成为粗粒度的服务,并发布为web服务的方法。3.2 工作流(workflow)和业务流程管理(bpm)
工作流(workflow)就是工作流程的计算模型,即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。 在组织的日常工作中,绝大多数属于流程类工作,比如审批流程、各类申请表单、公文签审、业务处理、各类请款与收付等。一项工作,经过一个步骤处理后再转往下一站的连续步骤,称之为“工作流”。 这些工作流程反映到计算机中,可能是某些组件、应用程序的接口、服务或者模块化的程序集等。在基于soa进行企业eai时,这些工作流程单元(比如审批、申请表单、公文签审等)一般设定为松耦合、可复用的web服务,然后通过工作流引擎将这些具备独立功能的web服务按照一定的业务逻辑规则串联到一起构成工作流。 采用工作流技术编排web服务可以带来以下好处:其一,可以将分散在多系统中的细粒度的程序模块(如服务、组件等)协调计算,实现工作流程的计算机化和自动化,并能对其进行有效的管理;其二,在组织结构和业务流程发生变化时,能够很少修改或者不修改原先应用的情况下,仅仅通过适当调整或重新定义工作流程就能适应变化了的情况,实现业务和it的一致性。 “工作流”和“业务流程管理”都关注流程的自动化。“工作流”一般局限于技术领域,用来描述人与计算机系统的一系列相关交互。“业务流程管理”涉及的范围更广一些,业务流程管理还从管理人员的角度涉及了非技术问题,比如分析、监管、组织的效率等。3.3 企业服务总线(esb)
企业服务总线(esb),是基于中间件技术实现并支持soa的一组基础架构功能,主要实现消息的传输、转换和路由,是连接企业各种纷繁复杂应用的骨干神经系统。 soa的目的之一就是关注于服务如何支持业务,以及如何具有连接到环境中其它部分的本质能力。因此,soa通过将应用程序的不同功能单元(或称为服务)定义良好的接口和契约来实现互连。这些接口独立于实现其功能的硬件平台、操作系统和编程语言,以使得构建在这些接口之上的系统可以以一种统一和通用的方式进行交互。esb支持这些接口的交互,并通过提供集成的通信、消息传递以及事件基础架构来支持这些功能,解决了异构分布式系统潜在的不兼容性和维护冲突的问题。 esb主要实现以下几点功能[5]: (1)提供位置透明的路由和寻址服务;控制服务寻址和命名的管理功能;至少一种形式的消息传递类型(如请求/响应,发布/订阅等)。 (2)请求者和服务之间的传输协议转换(如socket、http/soap、mq等协议的转换)。 (3)请求者和服务之间的消息格式转换(如xml报文和异构格式报文的转换等)。 (4)处理各种来自不同业务的事件。 (5)保证服务质量(安全、可靠和交互处理等)。 当然,在许多情景下往往需要esb实现其它功能,包括:面向服务的原数据管理、服务代理、管理和自治和基础架构智能等功能。 总之,esb充当了使用不同数据和消息格式、网络协议和编程语言的服务之间的“粘合剂”;充当了服务的提供者和使用者之间的中间层,允许部署中介、以执行各种操作;充当了整个soa架构中实现服务间智能化集成与管理的中介。4 基于soa实现eai的解决方案框架图
图2是综合了以上讨论的web service技术、工作流/bpm技术以及企业服务总线(esb)等基础上提出的soa实现eai的解决方案框架图。企业通过将底层的应用和信息资产(如遗留系统、数据信息等)进行封装,包装成松耦合的、满足特定服务质量的、细粒度的服务。这些功能独立的服务可以直接提供给本地终端应用调用,也可以参与到某一工作流程中完成特定的业务功能。 工作流/bpm是一些细粒度服务的集合,其按照某一顺序或逻辑规则与分布式应用中的一组服务进行交互,以满足特定业务要求。工作流本身也可以发布为服务,并被外界所调用。工作流/bpm也常用来解决应用系统中一些更为复杂技术难题,如事务处理等。 it服务管理,主要涉及与系统规模和性能相关的能力,用来监测和管理服务、流程、应用及资源等在系统运行时的表现。 服务注册中心是一个服务和数据描述的存储目录,服务提供者可以通过服务注册中心发布它们的服务(包括细粒度的服务和粗粒度的服务),而服务使用者(比如终端应用)可以通过服务注册中心发现或查找可用的服务。 框架图的底层是连接层,也就是企业服务总线(esb)。esb提供了所有的互联互通的能力,是连接上层各种纷繁复杂应用的骨干神经,在系统间的交互上(包括通信、集成和服务的请求响应等)实现消息流的传输、转换和路由。
5 应用案例研究与实现
为了形象的说明如何将遗留系统包装成服务、如何将服务编排到业务流程当中、业务流程如何与终端应用进行交互等,下面结合一个企业订单业务案例来描述soa在企业eai的具体实施过程。该案例只是企业内部若干业务流程中的其一,该业务流程跨越了多个部门,将多个分布式、异构的应用系统紧密联系到一起。(注:案例中省略了对服务的发现与发布、服务和流程的监管、连接层消息的传递等问题的描述。)图3 订单处理流程图
在订单处理流程中,首先要根据库存状况由系统生成订单;订单生成后将被发送到审批部门进行审批;审批通过的订单交由财务部门做财务处理;最后交给采购部门,采购处将和生产厂家进行对话,建立一个事务性质的采购流程并完成采购业务。 整个流程的基本组成单元是一些基于xml作为消息传输载体的web服务。这些中立的、松耦合等特点的web服务,遵循国际统一标准,打破了分布式系统的异构屏蔽性,将它们所在的遗留系统的信息释放出来,提供良好契约的接口并按照一定的逻辑规则参与到企业的业务流程当中去;同时,这些web服务具备良好的可复用性,可以灵活的被其它业务流程所调用。 这样,原本分布式、异构、僵化的it底层系统,就被分解为一组组透明、中立、灵活的web服务;这些服务将作为“原材料”提供给上层的流程层或表现层。以下是上述流程中部分web服务示例: ●order service - 用来生成订单的服务。 ●approval service - 对订单进行审批,记录审批意见和结果。 ●finance service - 用来对订单进行财务计算、处理,并生成票据、报表的服务。 ●purchase service - 采购物品;包含三个事务单元服务:reserve goods、pre deal和report build,分别用来进行资源预占、预交易和报表或票据生成等。 整个订单流程大部分工作由计算机自动处理,并由人参与其中进行监督管理。这种业务流程处理方式,打破了各部门系统之间的异构屏蔽,实现了库存处、财务部门、采购部门甚至企业外部生产厂家之间的信息传递自动化。在订单处理过程中,如果其中一个环节出现问题,流程将会中断回到初始状态并发送中断日志给管理人员。同时,在业务发生变动时,该流程模型会灵活、迅速的做出新的调整,保持业务流程与it基础架构步调一致,解决了以往企业有心开发新业务却无力改变it现状的难题。 可以说,基于soa实现企业的eai,就是在一定程度上实现了流程的集成、信息的集成和人的集成。