摘要:面向服务的软件架构正越来越为人们所接受,而基于构件总线的方式正是这一架构思想的良好实现。该文针对物流行业的信息化所存在的问题,提出了基于构件总线技术下SOA架构的解决方案以及相应实现方式。
关键词:构件;构件总线;SOA;服务集成
中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)13-3409-03
1 引言
传统的信息系统的建设方式存在如下几点不足:软件系统建设周期较长;维护困难;可扩展性和灵活性差;成本很高[1],基于这些缺点,传统的软件开发方式显然无法满足物流企业的信息化需求。
基于构件总线的物流平台尝试从体系结构,实现机制以及交付方式上来解决这些问题。随着软件技术的不断发展,构件及构件总线技术,SOA技术、WebService技术以及SaaS(软件即服务)技术的不断进步,为解决上述问题提供了新的思路。本文提出了采用SOA架构模式,基于构件总线的实现模式,以及SaaS的交付模式的物流平台设计方案。该方案克服了传统的软件开发方式的缺陷,采用基于构件的软件开发方法以及基于构件总线的架构模式。极大的缩短的软件的开发周期,能够快速适应用户的需求的变更,从而降低企业的信息化成本与运营成本,提高企业的核心竞争力。
2 构件总线
随着WebService技术的不断发展,这种新型的分布式构件模型越来越得到人们的广泛关注。当SOA推出以后,WebService构件技术更是得到进一步的发展,它被认为是实现SOA架构模式的最好的实现方法。本文正是基于WebService服务构件,企业服务总线这种构件总线来进行物流信息平台的设计与开发。企业服务总线的通常定义如下:它是由中间件技术实现并支持的面向服务架构的一组基础架构功能,支持异构环境的服务、消息以及基于事件的交互,并且具有适当的服务级别和可管理性。企业服务总线(ESB)是一种使得企业应用具有被组织结构内外的其他应用重用能力的框架;是一个实现了通信、互连、转换、可移植性和安全性标准接口的企业基础软件平台,是一种能够在一个框架架构中实现统一并连接服务、应用和资源的中间件模式。
2.1 构件总线所应具备的功能
1) 通信:为了提供服务的交互,企业服务总线需要提供一个交流层来实现服务之间的交互。为了实现各种服务的交互,服务总线应该支持各种通信协议来支持服务之间的通信。
2) 整合:企业服务总线应该可以支持各种平台的整合,包括异构平台的整合,包括那些未提供服务接口的应用,打包应用,以及其他的各种EAI系统。
3) 服务交互:服务总线应该支持SOA的关于接口的使用的概念,应该支持服务操作的声明,以及服务质量的需求。另外,为了支持服务交互,服务总线还应该来保证消息模型与接口的一致,同时能够传递接口的相关背景信息,例如:安全,事务,以及消息的相关性。
4) 管理:跟其他的组件一样,服务总线也应该提供相应的管理策略,来监控和管理控制服务的命名和寻址等。
3 物流信息平台的架构设计
本物流信息平台主要是针对中小型物流企业。传统的信息系统建设普遍按照自有的标准设计,没有通用的技术和架构标准,因而通用性较差。同时软件开发采用传统的模块化软件开发方式,模块间耦合度很高,因此系统的维护和修改比较困难,维护成本高。另外,本系统要服务于大多数的中小型企业,为了适应各个物流企业业务的差别,我们需要系统具有很高的可扩展性,能为客户快速定制一些个性化服务。为了解决上述问题,在面向构件的基于构件总线的软件开发方法进行了深入研究,通过提出面向服务的体系架构和构件化的实现技术来解决在物流信息平台开发所面临的问题。
3.1 平台的架构设计
为了实现系统的松散耦合,我们采用面向构件的方式来设计。对于系统中的业务,统一采用构件的方式来封装。构件与业务的结合,使得面向构件更准确地表现了业务模型,更好地支持了业务流程。构件业务化,是面向构件技术发展的必然,提高了业务构件的复用及适应业务变化的能力,使企业能够通过自身和业务构件的转换来应对市场的变化[3]。构件采用新一代构件模型WebService封装,并能够分布式部署。为了提高系统的灵活性,高可扩展性,采用企业服务总线这种构件总线对构件进行集中式管理。通过企业服务总线,可以对服务构件进行热拔插式的管理,另外,企业服务总线还能处理多种消息请求,并将这些消息请求格式化为统一的消息,从而调用外部的服务。例如:对于JMS,RMI请求,都可以将这些请求转换成标准的HTTP/SOAP请求格式,从而调用外部的服务,因此,企业服务总线实现了异构系统,不同协议服务的集成,是SOA架构思想的一种比较好的实现模型。在本物流信息平台中,将以服务总线为核心,将系统分为五层,分别是:数据层、服务层、总线控制层、门面层、以及前端调用层。每一层的改变都不会影响到其他部分的变化,这样将最大限度的保持系统的稳定性、兼容性和扩展性[5]。如图1为系统的架构示意图。
1) 数据层:提供信息平台的数据存取服务,因为这里的数据量很大,所以数据库都采用分布式部署。
2) 构件服务层:将系统所需要的功能,业务等封装成构件,以服务的形式提供服务;例如:在对信息平台进行了业务构件分析后,得知在系统中需要基础业务构件、车辆构件、短信构件、业务构件、票本构件等业务构件提供服务。另外,对于系统而言,可能还有许多个性化的需求,比如:为了车辆行驶的安全,需要知道物流车辆到达某地的天气情况。这个时候,就需要将外部的服务集成到本系统中来,然后再向用户提供。这样就做到了最大的灵活性,和可扩展性。
3) 总线层:主要是将系统中的业务构件集成起来,为了系统的简便性和开发的便利,我们在这里统一将业务构件以WebService封装,包括遗留系统提供的服务,外部系统提供的服务。因此对于总线层来说,主要是提供服务的代理以及将服务编排之后新的服务。同时总线层也屏蔽了前台对后台服务的访问地址,有利于系统的安全性的提高;服务的更改也完全不会对前台的使用造成影响,为系统的维护提供了极大的便利性。
4) 门面层:门面层是前端接入统一的入口。也就是说前端通过调用门面层的服务来完成业务交互。为了完成这个任务,门面层完成了WSDL文件到服务代码的转换。从而方便客户端的调用。
前端显示层:根据客户的接入终端的类型,提供相应的渲染界面。前端显示层直接与门面层交互,获取数据。为了前台开发的便利性和可维护性,采用基于MVC的开发模式。
4 物流信息平台的系统实现
本系统采用基于构件总线的架构思想。在上面我们已经阐述了系统的体系架构,为了实现这样一种架构,我们采用Java EE 平台来实现[4]。基于JBI(Java Bussiness Integration)规范的总线结构,为实现SOA体系架构提供了便利。JBI将服务分为服务提供者和服务请求者两类。服务请求者不能直接和服务提供者联系。所有的请求和响应消息都通过传输通道(Deliver Channel)送到NMR,再由NMR通过传输通道将消息传给服务提供者。在JBI中主要由BC(绑定组件Binding Component)、SE(服务引擎Service Engines)以及NMR(规格化消息路由器Normalized Message Routers)三部分组成[6-7]。
4.1 基于ServiceMix的物流信息平台的实现
Apache ServiceMix 是一种开源企业服务总线(Enterprise Service Bus). 它基于SOA架构以及实践驱动架构来创建了一种灵活的企业级的企业服务总线。ServiceMix是一种轻量级的JBI容器,集成了Spring的支持,它不仅可以成为一个服务的总线的提供者,也可以给另外一个服务总线提供服务。它可以运行在Apache Geronimo以及JBoss等应用服务器中。同时,ServiceMix集成了BPEL、XPath、Drools规则引擎、对RSS的支持与JCA等。
当系统业务构件开发完成,并完成测试后,接下来就应该根据前台提出的需求,针对性的进行服务整合,这里服务的整合可能包括外部服务和本地服务,以及遗留资产等,服务的整合是系统的关键。基于ServiceMix的服务整合也就是对业务流程的设计,根据业务的需求来配置和定义业务流程模拟。业务流程对应于实际的业务需求。而在ServiceMix中,业务流程(Bussniss Process BP),服务集合(Service Assembly SA),服务单元(Service Unit SU),它们之间满足如下关系[2]:
BP = {n×SA+(deploy descriper)| SA∈U,U 为服务集合的全集,n为自然数}
SA = {n×SU+(SU descriper)|SU∈V,V 为系统所提供服务的集合}
SU = {n×(Component descriper)|Component∈W,W为系统组件的集合}
以上descriper为xml格式的描述文件。从上面的关系我们可以看出,业务流程的开发
涉及到的工作有:SU(Service Unit)组件的开发和部署。SA(Service Assembly)组件的开发和部署。显然对于一个HP来说,可以由n个SA组成;而当n=1时,也就只需要一个SA与部署描述符即可;同时SA又由n个SU组成,当n=1时,也就是说SA可以由一个SU组成,换句话说,一个BP同样可以由一个SU与组件描述符组成;从上面来看,对于一个发布在JBI容器的BP而言,可以分为n=1时简单服务集成和n>1复杂服务集成整合两类。下面分别就物流系统的系统权限认证和费用提成两个场景来描述这两种业务流程设计。
1) 简单服务集成
也就是能通过单个服务就能完成业务需求的集成。在这种情况中,服务总线只是起到了简单的代理作用。以系统权限认证为例,完成这个业务过程仅仅需要基础服务构件的支持,因此服务总线只需要代理这个服务即可。即只需要一个SU及一个组件描述符。物流信息平台的权限认证是基于RBAC来设计,图2为权限认证的活动图。
对于上面这个业务流程而言,所涉及到的业务构件只有一个基础服务构件,这个场景所需要完成的功能就是根据用户ID来判断该用户是否具有某资源的增删改查权限等。对于服务总线而言,这样的流程就是服务前端调用类根据前台的请求,发送此请求到服务总线,服务总线然后再转发到外部服务中,然后在外部服务中查找授权,然后返回授权信息。
为了完成相应的集成,需要在servicemix.xml将此集成过程体现出来,相应的核心代码如下:
endpoint="loginServiceHttpPort"> class="org.apache.servicemix.components.saaj.SaajBinding"> value="http://localhost:8080/bhwl/services/hello"/> 2) 复杂服务集成: 为了实现商业流程,无法通过服务总线上一个服务的集成来完成,需要通过多个服务的交互才能完成。这时候,就需要对服务总线上的服务进行流程编排,通过服务之间的交互,整合来共同完成业务流程。以物流信息平台中分理站和收货组的提成场景为例:在物流系统中,因为分理站是属于物流公司和地方共建的形式,因此就存在业务提成的问题,提成的业务流程如图4。 如图4所示,为了获得某个部门的提成信息,首先需要根据部门名称查询到部门ID所对应的业务列表,在遍历这个业务列表的过程中,需要查询业务所对应的业务类型,如看这个业务是发货,收货,还是原单返货等,然后再在这个基础上查询出这种类型的货物单笔业务所属分段信息所对应的提成比例,然后再乘以这个提成比例。这时候所得就是这个部门这种货物类型所对应的提成。 在这个过程中,我们涉及到三个服务的交互,首先是基础管理服务(BasicManageService),在这里可以通过部门名称查询到部门ID;在遍历业务列表阶段,需要通过查询出来的ID 在业务服务构件(BussManageService)中查询出业务类型ID;最后将部门ID以及业务类型ID传递给财务管理服务构件(FinManageService),然后在财务服务构件中返回所需要的提成值。 基于上面的应用场景,在ServiceMix中,集成多服务交互通过BPEL(Business Process Execution Language)来集成,它是一种新的业务流程语言,通过对WebService的编排,相当于重新编写了一个WebService以达到整合业务流程的目的。BPEL同样也是一种服务引擎,它依附与JBI容器,为JBI容器提供服务,因此它是一种SE。在ServiceMix中需要创建一个包含BPEL实例的SU,即此BP由一个SA和一个servicemix.xml组成,在这个SA中又包含两个SU。其中一个是服务绑定的SU以及一个bpel SU。因此对于复杂业务集成而言,关键来说就是bpel SU的开发。图5为bpel SU 编排业务流程图。 基于bpel的开发,主要是bpel文件的编写,对于上述应用场景来说,主要是上面三个根据上述三个服务的wsdl文件,在bpel中整合起来.如下所示为bpel文件的部分代码: query="FinanceService/getProfitResponse"/> query="BasicService/getNameRequest"/> …………………………… portType="finManage" operation="getProfit" inputVariable="financeService-request" outputVariable="financeService-response" sm:endpoint="urn:soa:finace:financeService" /> 5 结束语 本文采用面向服务的体系结构,基于构件总线设计和实现物流信息平台。该系统可以针对用户的需求的不同,动态地可以配置地完成服务的快速构建,构件总线的基于构件的整合屏蔽了平台之间,协议之间的差异,能够快速满足用户不断变化的需求。 参考文献: [1] 黄柳青,王满江.构件中国:面向构件的方法与实践[M].北京:清华大学出版社,2006. [2] 侯志刚,马忠杰.基于ESB的流程管理系统的研究与实现[J].微电子学与计算机,2008(6). [3] 梁爱虎.精通SOA:基于服务总线的整合应用开发[M].北京:电子工业出版社,2007. [4] http://servicemix.apache.org/home.html[EB/OL]. [5] Binildas C A.Service Oriented Java[M].Business Integration Packt Publishing,2008.
