（计算机软件与理论专业论文）基于soa的工资业务系统的研究与实现.pdf

摘要 摘要 大型企业应用软件比较复杂，传统的软件架构设计方法缺乏有效的模块复用和 信息交流能力，企业内部容易出现“信息孤岛”问题；不良的软件架构设计容易导 致增加企业维护和升级现有系统的成本，企业应用之间的整合投入高、周期长等问 题；传统开发设计方法下面的软件系统缺乏灵活变更能力，无法解决不断变化的业 务变化需求。为了解决这些问题，软件供应商和开发者提出了基于w e b 服务的软件 体系设计结构。 本文从实际的工资业务系统出发，引入w e b 服务、s o a 技术和服务复用技术， 提出了基于s o a 设计的工资业务系统，设计了一组跟工资业务相关的w e b 服务组 件，提高了组件的重用性和适应能力，使得该软件能够脱离平台相关性，满足不断 变化的工资业务需求；增强了系统与其他企业应用之间的交互能力，有效的解决“信 息孤岛”的问题；采用通用的x m l 语言定义数据元，具有平台无关性、可扩展和 易于理解等特点；用w e bs e r v i c e s 实现了通用的工资业务组件服务，使得新的工资 业务需求可通过配置方式，迅速的在现有的平台上实现。针对这些特点，本论文主 要做了以下方面的工作： 1 ) 分析了基于服务的软件架构设计方法( s o a ) 技术的基本要素和特点，提出 将s o a 设计方法引入到工资业务系统当中； 2 ) 分析了基于s o a 工资业务系统在设计上的可行性和应用上的优势，关注工 资业务服务的设计； 3 ) 对基于s o a 的工资业务系统的关键核心功能：工资业务规则执行服务、报 表查询服务和用户界面流程进行详细代码和数据库的设计，实现了一个基于s o a 的 工资业务系统的核心功能。 经过实践证明，基于s o a 的工资业务系统是可行的，使用基于s o a 的架构， 不仅开发者可以获得清晰的软件系统结构，也大大提高了企业应用的集成能力，方 便了使用者对软件的维护和扩充。 关键字：面向服务，工资业务，w e b 服务，规则执行 广东工业大学工学硕士学位论文 a b s t r a c t e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o na r ec o m p l i c a t e d ，w h i c hm a k e st h e t r a d i t i o n a ls o f t w a r ea r c h i t e c t u r ef a c e sd i f f i c u l t i e s t h et r a d i t i o n a ls o f t w a r e d e s i g nm e t h o dl a c k sr e - u s a b i l i t ya n di n t e r c o m m u n i o n ，w h i c hc a u s ea t r o u b l ec a l l s ”i n f o r m a t i o n i s l a n d ”i nt h e e n t e r p r i s e n o t w e l l f o r m a r c h i t e c t u r el e a d sah e a v yc o s tt om a i n t e n a n c ea n du p d a t ec u r r e n ts o f t w a r e ， a n do t h e rp r o b l e m ss u c ha s e x p e n s i v ea n dl o n g e rc y c l et oi n t e g r a t i o n b e t w e e ne n t e r p r i s ea p p l i c a t i o n s t h em o r eo fi tm a k e st h ea p p l i c a t i o nh a r d t oc h a n g ew h i l et h ec h a n g i n gd e m a n d i n gc o m e s t os o l v ea l lo fp r o b l e m s a b o v e ，t h ea p p l i c a t i o np r o v i d e r sa n d d e v e l o p e r sb r i n g f o w a r dan e w s o f t w a r ed e s i g nm e t h o d ：s e r v i c e o r i e n t e d a r c h i t e c t u r e t h i s p a p e rc o m e sf r o mt h ea c t u a l p r o j e c t n a m e d s a l a r ys y s t e m ， i n t r o d u c e st h ew e bs e r v i c e ，s o aa n ds e r v i c e sr e u s i b i l i t yt e c h n o l o g i e s ，a n d b r i n g sf o r w a r das a l a r ys y s t e mb a s eo ns o a t h i sn e wa r c h i t e c t u r em a k e s t h ea p p l i c a t i o nm o r ef l e x i b l e ，e l e g a n t ，a n du l t i m a t e l yr e u s a b l e i td e s i g n sa s e to fw e bs e r v i c e sc o m p o n e n t sr e l a t e dw i t hs a l a r yo p e r a t i o n ，w h i c hr e d u c e s t h er e l a t i o nw i t hp l a t f o r m ，c a nm e e tt h en e e d so fn e wo p e r a t i o nt ob u i l da n e w a p p l i c a t i o n ， e n h a n c e st h ei n t e r c o m m u n i o n a b i l i t y w i t ho t h e r a p p l i c a i t o n s i tc a ne f f e c t i v i t ys o l v et h e ”i n f o r m a t i o ni s l a n d p r o b l e m a c c o r d i n gt o t h e s ec h a r a c t e r i s t i c ，w e m o s t l yd i s c u s ss o m ea s p e c t sa s f o l l o w s ： 1 d i s c u s st h eb a s i ce l e m e n to fs o a ，a n db r i n gf o r w a r das a l a r ys y s t e m b a s eo ns o a ； 2 b r i n go u tt h es a l a r ys y s t e mb a s eo ns o a sa r c h i t e c t u r e ，p o i n to u ti t s f e a s i b i l i t ya n da p p l i c a t i o na d v a n t a g e s ； 3 c a r r yo u tt h es a l a ys y s t e mb a s eo ns o a sc o r ec o m p o n e n t ss u c ha s s a l a r yo p e r a t i o n r u l e e x c u t o r ，r e p o r t s d a t a q u e r ya n d u s e ri n t e r f a c e a p p l i c a t i o n ，w h i c hd e t a i l st ot h ed a t a b a s ea n dt h ec o d el e v e l a st h ep r a c t i c ep r o v e s ，t h en e w s a l a r ys y s t e mb a s eo ns o a i sf e a s i b l e ，i t n o to n l ym a k e st h es o f t w a r ea c h i t e c t u r em u c hc l e a rt ot h ed e s i g n e r s ，b u t a l s om a k e st h ea p p l i c a t i o ne a s i e rf o rt h eu s e r sm a i n t e n a n c ea n de x p a n s i o n k e y w o r d s ：s e r v i c e - o r i e n t e d ，s a l a r yo p e r a t i o n ，w e bs e r v i c e s ，r u l ee x c u t o r 独创性声明 独创性声明 秉承学校严谨的学风与优良的科学道德，本人声明所呈交的论文是我个人在 导师的指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以 标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，不包 含本人或其他用途使用过的成果。与我一同工作过的同志对本研究所做的任何贡 献均已在论文中作了明确的说明，并表示了谢意。 本学位论文成果是本人在广东工业大学读书期间在导师的指导下取得的，论 文成果归广东工业大学所有。 申请学位论文与资料若有不实之处，本人承担一切相关责任，特此声明。 指导教师签字 九言玲 论文作者签字姜f 沌叶 厶。占年厂月刁日 第一章绪论 1 1 引言 第一章绪论 随着软件开发方法的发展和i n t e r n e t 技术应用的深入，软件开发的规 模逐渐增大，复杂程度度逐渐增加，传统的瀑布型、螺旋型的软件工程 方法在处理复杂项目的时候，常常面临着多数相同功能的需求重复开发 的尴尬，传统工程下的软件系统无法脱离平台的相关性，缺乏平台无关 性的数据交流能力，容易造成“数据孤岛 等状况。面对日益复杂的业 务逻辑需求，紧密耦合的软件系统在适应能力上的瓶颈凸显，不断变更 的业务需求常导致不断地更换软件系统，造成i t 资源浪费，同时给开发 人员带来繁琐的维护工作。在现有软件结构下，系统难以及时向高层提 供决策信息，使得企业的i t 运行成本居高不下。因此，为了更好的重用 已开发的模块，且使得软件的重用可以脱离平台的相关性，早在l9 9 6 年，g a r t n e r 就提出了一种面向服务的体系结构s o a ( s e r v i c eo r i e n t e d a r c h i t e c t u r e ) 。这种软件体系通过面向服务的构件方式，把业务以服 务的方式展现在网络上，利用这些服务可以利用较面向对象和面向构件 更好的软件复用方法去构建一个松散耦合的分布式系统。 基于s o a 架构的服务的出现，使得企业在改变i t 系统的灵活性得到 很大的提高。面向服务的s o a 架构定义了搭建企业软件架构的一种新方 法，将任何共享应用和数据服务定制为能满足特定业务需求的复合型应 用，使一些大企业或地理分布范围比较广的开发队伍能够更好地合作， 降低开发成本，提高系统集成度和响应速度，同时帮助解决因为系统升 级带来的困难，因为这些s o a 架构下的中间件业务模块都能够被重新配 置或以新方式优化以满足新的需求。 广东工业大学工学硕士学位论文 1 2 国内外研究现状 s o a 架构在国外被视为下一代w e b 服务的基础架构，基于s o a 架构 的系统，注重于业务组件的开发和重用，把构件技术灵活应用在互联网 上，使得系统能够适应灵活多变的业务需求。目前，国外专注组件开发 的厂商包括i b m 、微软、甲骨文等软件厂商巨擘，都十分推崇s o a 架构， 并认为未来的软件开发将朝着s o a 方向发展，企业应用不再是传统的建 房子模式，而是通过松散藕合的各业务部件，有机的联系在起f 2 1 。根 据z a pl i n k 调研公司公布的一份报告显示，截止到2 0 0 6 年底，基于s o a 架构( 面向服务的架构) 的中间件产品已成为网络化商业系统的主要设计 思路，2 0 0 7 年s o a 架构下的中间件产品进入主流应用之中【3 】。开放s o a 合作组织( o p e ns o ac o l l a b o r a t i o n ，o s o a ) 是一个非正式的厂商联盟， 他的作用是使得各厂商能够共同开发一个语言中立的编程模型。该编程 模型帮助企业软件开发人员能够最大限度的发挥s o a 架构的特性和优 势。目前加入o s o a 的厂商包括i b m 、b e a 、s a p 、o r a c l e 等i 尽管o s o a 不是一个标准化组织，但由于有i b m 、b e a 等业界厂商的支持，它制定 的规范很可能会成为事实上的标准。o s o a 规范在2 0 0 7 年3 月发布了最 新的v 1 0 版本。一些开发商和开源项目大多实现了较早规范，最新规 范的实现正在紧密地进行中。 在国内，上海普元软件公司作为唯一加入o s o a 并致力于规范制定的 中间件产品供应商，已经开始把自己的注意力集中在面向构件与s o a 产 品的开发，并推出普元e o s ( p r i m e t o ne n t e r p r i s eo p e r a t i n gs y s t e m ) 企 业应用开发平台。普元e o s 是针对不断变化的需求而设计的面向构件的 中间件平台，它将构件技术、x m l 企业总线技术和可视化开发技术完美 结合，通过图形化的构件单元作为应用系统的基本组成元素，使应用系 统可以快速高质量的搭建，同时拥有最强的需求变化响应能力，并通过 构件积累来持续积累软件知识财富。e o s 平台基于互联网应用体系设计， 可在面向包括电信、金融、政府、制造业等所有企业级应用，具备较为 广泛的可用性。其他国内s o a 厂商也在崛起，2 0 0 7 年7 月2 4 日，主题为“驾 2 第一章绪论 驭s o a 驱动整合应用”的2 0 0 7 年s o a 应用年会暨s o a 应用方案颁奖典礼 在北京国宾酒店隆重召开，国内外的顶尖中间件厂商，十余个主流行业 的用户代表，资深技术专家齐聚一堂，针对s o a 主流技术发展及应用趋 势发表观点，并就s o a 企业应用、部署s o a 的方法、s o a 技术架构、开 发环境、流程设计、建模方法等进行了深入探讨【4 1 。 1 3 论文主要研究内容 本论文是在通过研究现实运行的工资业务系统，在此基础上建立基于 s o a 的工资业务系统，并在这个框架上实现工资业务系统的快速配置， 使得工资业务系统能够灵活响应不断变化的业务需求，并且实现和社保 基金管理局、税务局等外部系统实现在线数据交换。系统设计的目标是， 能使得运行后的统发工资业务能够及时响应统发工资政策的调整；能使 各个预算单位、各级部门的数据有机整合起来，有效进行业务协同工作； 提供灵活的报表输入输出功能；能利用s o aw 曲服务的特色，构造粗粒 度的工资业务服务，为系统的变更和升级提供灵活的解决方案。 本论文的主要研究内容包括如下几个方面： 1 、s o a 技术的理论的在工资业务系统的应用； 2 、建立一个基于s o a 的工资业务系统；这个工资业务系统的核心应 该是：基于s o a 的工资业务构件库，利用这些工资业务构件可以快速搭 建具有灵活工资业务需求的工资业务应用系统，这些构件能运行在网络 的环境下并具有高度复用能力； 3 、对基于s o a 的工资业务系统的关键核心功能：工资业务规则执行 服务、报表查询服务和用户界面流程进行详细代码和数据库的设计，实 现了一个基于s o a 的工资业务系统的核心功能。 1 4 本文的组织结构 本文第一章绪论介绍了课题的相关知识，对目前s o a 技术的研究状 况进行分析和概述，从而引入介绍本课题的来源和主要研究内容； 3 广东工业大学工学硕士学位论文 第二章从理论角度，分析了面向服务的软件设计方法体系结构的相关 技术；第三章引入统发工资系统的业务，分析当前工资业务系统的特点 和当前统发工资系统的状况，提出将s o a 设计方法应用于工资业务系统 的理论；第四章从系统实现的角度，详细分析了基于s o a 的工资业务系 统的技术设计方案，并对系统的安全性提出解决办法；第五章对系统的 关键实现部分给出了详尽的设计，实现了工资业务规则执行服务、报表 查询服务和用户界面流程三个工资业务的核心功能；第六章对本课题进 行了总结，阐述了系统的不足，并对本课题提出了展望和需要进一步的 工作。 4 第二章面向服务的软件设计方法 第二章面向服务的软件设计方法 2 1 面向服务体系结构 2 1 1s o a 的概念 i b m 给出s o a 的概念：面向服务的体系结构( s e r v i c eo r i e n t e d a r c h i t e c t u r e ，s o a ) 是一个组件模型，它将应用程序的不同功能单元( 称 为服务) 通过这些服务之间定义良好的接口和契约联系起来【5 1 。其中， 定义良好的接口应该是平台无关性的，基于这样的体系结构的系统具备 松散耦合结构，这样的结构有两个好处：一是灵活性，可以针对不断变 化的业务做快速反应；二是当服务内部结构改变时，整个应用程序可以 在不发生任何改变的情况下继续存在。 而e r i cn e w c o m e r 给出的定义则从企业整体i t 结构考虑，认为s o a 是一种设计方式，它指导业务服务在整个生命周期中创建和使用的各个 方面，并定义和提供了具有以下特征的i t 基础设施( i ti n f r a s t r u c t u r e ) ： 允许不同的应用相互交换数据和参与业务流程，无论它们各自背后使用 的是何种操作系统或采用了何种编程语言【6 】。 s o a 的基本实体是软件服务【7 。9 】。这种服务的概念，是比对象、构件 具有更高的抽象级别、更大的粒度与更强的独立性与可用性，因此便于 使用者直接使用。面向服务的体系结构( s o a ) 是一种架构模型和一套设 计方法学，其目的是最大限度地重用应用程序中的服务，以提高i t 适应 性和效率。它可以根据需求通过网络，对松散藕合的粗粒度应用组件进 行分布式部署、组合和调用。服务层是s o a 的基础，可以直接被应用调 用，从而有效控制系统中与软件代理交互的人为依赖性。s o a 的关键是 “服务 的概念，w 3 c 将服务定义为：“服务提供者完成一组工作，为 服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生 变化，但也可能使提供者的状态改变，或者双方都产生变化 【l0 1 。在面 5 向服务的体系结构中，s o a 定义的流程、原则和方法都是面向服务的( 也 称为面向服务开发，s e r v i c e o r i e n t e dd e v e l o p m e n t ) ；s o a 选择的开发工 具是面向创建和部署服务的；s o a 提供的运行时基础设施也是面向执行 和管理服务的。在面向服务的架构( s o a ) 中，服务是用作下列用途的 基本单元 6 】： 一进行跨部门和应用边界的业务信息共享 进行跨部门和应用边界的业务信息更新 2 1 2s o a 的组成元素 s o a 关注的服务各个方面，i b md e v e l o p e w o r k s 给出一个s o a 的体 系结构堆栈，认为可以从这个堆栈集中体现s o a 中服务是体系结构的关 键要素【1 1 1 。 图2 1 面向服务体系结构中的组成元素 f i g 2 1s o ac o m p o n e n t s 体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面， 而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下 【1 2 1 ： 6 第二章面向服务的软件设计方法 功能性方面包括： 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提 供者，并且将来自服务提供者的响应传送给服务使用者。 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者 和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何 调用服务以及成功地调用服务需要什么数据。 服务描述实际可供使用的服务。 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定 的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是 服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通 过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心 发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务 提供其他的功能。 服务质量方面包括： 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以 使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方 面；因此，我们在功能和服务质量两个区中都有策略功能。 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、 授权和访问控制。 传输是属性集，可以应用于一组服务，以提供一致的结果。例如， 如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成， 或者没有一个完成。 管理是属性集，可以应用于管理提供的服务或使用的服务。 2 1 3s o a 的基本原则 文献【13 】的作者总结了s o a 的几大原则，认为要了解s o a 是为了解 决什么问题，就先要了解s o a 有哪些原则。 7 广东工业大学工学硕士学位论文 s o a 的目标是松散耦合系统与业务敏捷性。松散耦合保证系统之间 互操作的健壮性，业务敏捷性保证采用s o a 的企业与组织快速应对业 务需求的快速变更。 成功的实施s o a 需要遵循三个基本的原则【1 3 】： 1 、业务驱动服务，服务驱动技术。从本质上说，在抽象层次上，服 务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务 需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与 提供这些服务的底层技术之间的关系。 2 、业务敏捷性是基本的业务需求。s o a 考虑的是下一个抽象层次： 提供响应变化需求的能力是新的“元需求，而不是处理一些业务上的固 定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求， 因为在s o a 中任何的瓶颈都会影响到整个i t 环境的灵活性。 3 、成功的s o a 总处于变迁中。s o a 工作的场景是一个不断变化的 场景，因此采用了s o a 就意味着要不断的变化来适应新的业务需求。 来自其他各方的学者也认为，业务粒度的划分影响s o a 架构的实施， 认为细粒度服务执行最小的功能，标量发送和接收了少量的数据，而粗 粒度服务执行了较大的业务功能，并交换了更多的数据，所以s o a 的遵 循的另外一个原则是粗粒度的服务；细粒度服务是供粗粒度服务或组合 服务使用的，而不是由终端应用直接使用的。从原则方面考虑，服务的 可重用性、基于标准的设计，也是s o a 不可或缺的必须遵循的原则之一。 2 1 4s o a 的业务流程 s o a 服务的服用依赖于粗粒度的业务组件的模块化。下图描述了一 个s o a 服务组件的分层结构【14 1 。 8 第二章面向服务的软件设计方法 lu j 璩p 越l| | 缓瞰鞭讲嘶l1 讲眦雕m 雕l iu 嘲li 伪黼ll 璩嘲h 讲嘲l 啦嗽ll u l 瞰l u t 嘲| l 臻mi蠊懈| | 诵豫| l 诩ml 铆p 蛾ll m 撕 广 n阁 m 虚恐锄糖。一 。门 一n 厂1 u”uu蕊一孺蹄一一”uuu 箩蠢用蘸毒气一文携缀辫崩锛壤羧努以麓翰隰努崩零缛服务 錾，一7 碧，一一“。毽霪慧黪潞瓣掣4 霹i 霉墅篓象秒，誓27 掰鬻遂篓；甥 到厂 陇貔旒澎镢剁凌施囊荔瓤；盔搿l。；象鳜蠢酝貔；翻缓壶缓蠡貔蒯 陵缓 i 椰鹳l 繁j卜蕊程弓 襄l| j 勰缎霉l 鼙l 援裘芎| 餮。l 数据引鬻； 图2 2s o a 服务分层图 f i g 2 2s o al a y e r s 最底层是基础硬件设施和数据库服务。在底层的各种业务使用的数 据库中，数据库本身可以是独立和分布式的。数据库之间不应该直接建 立太多的数据交互和传递。具体的数据同步和交互也需要注册到e s b 服 务总线上，按一定的规范标准提供数据服务。 在e s b 企业服务总线上有两类服务和引擎，一类是提供基础的技术 架构和服务的引擎，一类是提供业务s o a 服务的引擎。在快速软件开发 中我们强调的权限建模，流程建模，组织结构建模，报表和数据服务等 都可以抽象为标准的技术类服务引擎。这些引擎可以让我们快速的搭建 一个业务软件的开发平台。另一类是涉及业务的引擎，如采购服务引擎， 库存服务引擎，销售服务和信用服务引擎等等，这类引擎是对常见业务 的通用规则的抽象，同时又需要考虑在不同场景下使用时候的可配置性 和可扩展性。 当业务都已标准的s o a 服务暴露出去后，我们看到可以通过业务流 程编排将我们提供的各种业务s o a 服务编排在一起，完成一个完整的业 务操作和流程。一个完整的业务流程正是各种s o a 服务和引擎的编排和 组合。在流程编排过程中我们还可以设置各种业务规则，建立分支，因 此在这里是完全可以再抽象出一个独立的业务规则引擎。 9 2 2w e bs e r v i c e 技术 2 2 1w e b 服务 从表面上看，w e b 服务就是一个应用程序，它向外界暴露出一个能 够通过w e b 进行调用的a p i 。这就是说，你能够用编程的方法通过w e b 调用来实现某个功能的应用程序。从深层次上看，w e b 服务是一种新的 w e b 应用程序分支，它们是自包含、自描述、模块化的应用，可以在网 络( 通常为w 曲) 中被描述、发布、查找以及通过w e b 来调用。w e b 服务 是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的 技术规范，这些规范使得w e b 服务能与其他兼容的组件进行互操作。它 可以使用标准的互联网协议，像超文本传输协议h t t p 和x m l ，将功能 体现在互联网和企业内部网上。 当前，w e b 服务是一个热门话题。w e b 服务的主要目标是跨平台的 可互操作性。为了达到这一目标，w e b 服务完全基于x m l ( 可扩展标记 语言) 、x s d ( x m l s c h e m a ) 等独立于平台、独立于软件供应商的标准， 是创建可互操作的、分布式应用程序的新平台。在下列情况下使用 w e b s e r v i c e 会带来明显的好处【1 5 】。 1 、跨防火墙的通信 如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端 和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通 常会有防火墙或者代理服务器。w e b 服务利用s o a p ( s i m p l eo b j e c t a c c e s sp r o t o c o l s ，简单对象访问协议) 和x m l 对这些模型在通讯方面 作了进一步的扩展以消除特殊对象模型的障碍。w e b 服务主要利用 h t t p g e t 、h t t p p o s t 和s o a p 协议使商业数据在w e b 传输，w e b 服 务用户能够使用s o a p 和h t t p 通过w e b 调用的方法来调用远程对象。 下图是这样的一个调用过程： 1 0 第二章面向服务的软件设计方法 画 芒勤 u i i o c 甜o n a v 妇b s 崮榭 l o c a t i o nb 图2 3w e bs e r v i c e 调用过程 f i g 2 - 3w e bs e r v i c et r a n s f e rp r o c e s s 2 、应用程序集成 企业级的应用程序经常要把用不同语言写成的、在不同平台上运行的 各种程序集成起来，这样花费很大的开发力量，不同平台或同一个平台 上，不同软件厂商生产的各种软件也常常需要通讯和集成，通过 w e b s e r v i c e ，应用程序可以用标准的方法例如接口，把功能和数据“暴 露 出来，供其它应用程序使用。 另外，w e b s e r v i e e 是b 2 b 集成成功的关键。通过w e b s e r v i c e ，公司 可以把关键的商务应用“暴露 给指定的供应商和客户。用w e b s e r v i c e 来实现b 2 b 集成的最大好处在于可以轻易实现互操作性。只要把商务逻 辑“暴露”出来，成为w e b s e r v i e e ，就可以让任何指定的合作伙伴调用 这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语 言。这样就大大减少了花在b 2 b 集成上的时间和成本，让许多原本无法 承受e d i 的中小企业也能实现b 2 b 集成。 3 、软件和数据重用 软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。 最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形 式的组件重用。仅限于代码而非数据的重用级别低，存在严重的维护问 题。w e b s e r v i c e 在允许重用代码的同时，可以重用代码背后的数据。使 用w e b s e r v i c e ，再也不必像以前那样，要先从第三方购买、安装软件组 件，再从应用程序中调用这些组件；只需要直接调用远端的w e b s e r v i e e 就可以了。把当前基于组件的应用程序结构扩展为组件w e b s e r v i c e 的混 合结构，可以在应用程序中使用第三方的w e b s e r v i c e 提供的功能，也可 以把自己的应用程序功能通过w e b s e r v i c e 提供给别人。两种情况下，都 可以重用代码和代码背后的数据。 广东工业大学工学硕士学位论文 2 2 2w e b 月艮务禾口s o a 文献【16 】介绍了w e bs e r v i c e s 技术和面向服务架构的特点并深入的讨 论了他们之间的关系。w e b 服务系列技术是架构在x m l 技术的基础上， 为在平台层解决应用层集成所不可避免的问题而提出的开放式的技术架 构。w 曲服务是一种实现s o a 的技术架构，是建立在开放标准和独立于 平台的协议基础之上的分布计算单元，它描述了一组可以在网络上通过 标准化的x m l 消息传递访问的操作：它使用s o a p 协议在服务提供者 与服务使用者之间进行通信；通过w s d l 协议定义服务接口；使用u d d i 协议进行注册和查找。也可以说，w 曲s e r v i c e s 是一种基于服务组建的 开放的软件平台，是面向服务的i n t e r n e t 应用，它可以在网络( w e b ) 中被描 述、发布、查找以及调用。文献 7 卜【8 提出了基于w e bs e r v i c e 的s o a 的基本模型：“3 角色3 行为 模型，这个模型可以进行服务的“描述 发布发现绑定调用”的操作。 图2 4w 曲服务3 角色3 行为模型 f i g 2 - 4w e bs e r v i c e3 r o l e & 3 - b e h a v i o u rm o d e l 根据2 0 0 3 年4 月的g a r t n e r 报道，y e f i m v n a t i s 是这样解释的【1 7 】： “w e b 服务是技术规范，而s o a 是设计原则。特别是w e b 服务中的 w s d l ，是一个s o a 配套的接口定义标准，这是w e b 服务和s o a 的根 本联系。从本质上来说w e b 服务是s o a 的一种实现，但是并不是实现 1 2 第二章面向服务的软件设计方法 s o a 的惟一形式。但是毫无疑问，它是最成功、最流行的形式。s o a 是 一个比较虚的概念，比如只提出定义一些接口和协议但并没有使之具体 化，而w e b 服务就将它们具体化了：w e b 服务使用的协议都是基于x m l 的；s o a 只说应该有三种角色，而w e b 服务里这三种角色都有具体的实 现方式。下图为s o a 与w | e bs e r v i c e s 的层次映射关系【1 引。 溆功畿瓮蘩 w e bs e r v i c e s 棚荧貉汉 r 浚荔瀛蘸+ j -_ 一_ 。w s 薹r 乙、w 鬈笏纛 ，f ； 殿 f。凝务，_ 。h 一 。嚣d 疆 务。 瀣 一缀努壤鎏j 一一和 w s o l 瓣 r | l l 。鍪叁鎏照鎏望。卜 7 * _ - 。 s o a w x m l ， 心 卜髓赣j -_ 一-黼p 1 - l p ，鬈嬲黪 t * 图2 5s o a 与w e bs e r v i c e s 的映射 f i g 2 - 5s o a a n dw e bs e r v i c e sm a p p i n g 从上面的映射关系来看，w e bs e r v i c e s 是就现在而言最适合实现s o a 的一些技术的集合： ( 1 ) 通过u d d i 的目录查找，可动态改变一个服务的提供方而无需影 响客户端的应用程序配置。 ( 2 ) 通过使用w s d l 和基于文本的s o a p 请求，可以实现一次性接收 大量数据的接口。 ( 3 ) w e bs e r v i c e s 所有的通讯是通过s o a p 进行的，而s o a p 是基于 x m l 的，不同版本之间可以很轻松的使用不同的d t d 或者x m ls c h e m a 加以辨别和区分。 根据c aw i l y 权威杂志的一项调查，目前在使用s o a 架构的公司当 中，存在使用w 曲服务技术作为他们实现s o a 架构的首要技术的占了 大部分比例，下图是一个调查结果图 1 9 1 ： 1 3 广东r 业大学： 学硕士学位论文 w e b e n t e r p r i s e& s r n b u t e d p r o c e s sn o r eo l s e r v ；c e s s e r v i c eb u s e s p o r t a l ss e r v e r s t h ea b o v e s u r v e yr e s p o n d e n t so v e r w h e l m i n g l ys e t e c t e dw e bs e r v i c e sw h e na s k e d w h i c hs o at e c h n o l o g i e st h e y a r eu s i n go rc o n s i d e r i n g - 图2 6w 曲s e r v i c e s 技术应用调查 f i g 2 - 6s u r v e yo nw e bs e r v i c e sa p p l i c a t i o n s 2 2 3w e b 服务进化系统 遗留系统在组织中起着重要的作用。随着商业环境的快速变化，应该 不断用新技术对其进行进化。w e b s e r v i c e 和面向服务的体系结构( s o a ) 使我们能在面向服务的计算环境中进化遗留系统。 目前，将遗留系统进化为s o a 有三种方法【2 0 】： ( 1 ) 将遗留系统包装成w e b s e r v i c e 。利用这种方法，只需分析遗留接 口，不需知道遗留系统的内部细节。从长远来看，该方法使遗留系统的 维护和管理更加复杂。 ( 2 ) 利用业务逻辑将遗留系统再工程为w e b s e r v i c e 。这种方法利用逆 向工程技术从源代码中恢复业务逻辑，并根据恢复的业务逻辑开发一个 新的系统。在实现w e b s e r v i c e 的同时利用了有价值的业务逻辑和新技 术。从而节约了维护费用，提高遗留代码事务处理的效率。然而，完整 地恢复业务逻辑是一件非常困难的事。 ( 3 ) 将对遗留系统的包装和理解相结合。这种方法又称为灰盒方法。 1 4 第二章面向服务的软件设计方法 该方法以需求分析和系统再工程为基础，能快速可靠地集成系统和有用 的业务逻辑。该方法解决了工业和学术在面向服务计算环境中进化遗留 系统的有关分歧。 2 3s o a 带来的效益 在u n d e r s t a n d i n gs o aw i t hw e b s e r v i c e 一书中，作者认为s o a 技术 能同时带来技术上和业务上的效益。技术效益可以体现为： 高效的开发 更利于重用 简化维护 增量采纳 流畅的演进 这些技术效益为公司或机构带来的好处是可以降低开发成本和加快 开发周期。同时，s o a 也带来业务上的效益： 增强业务机动性 更好地配合业务 改善客户满意度 降低集成成本 2 4s o a 的发展状况 通过近几年的持续跟踪研究，计世资讯认为，在2 0 0 8 年或者说是下 一阶段，s o a 的以下五个方面值得关注【2 l j ： 第一是用户认知。早在2 0 0 3 年和2 0 0 4 年，中间件厂商i b m 和 b e a 就已经开始在国内宣讲s o a 的理念，但由于当时s o a 只是停留 在理念和技术层面，很多用户很难理解，即使大致明白其内涵，也觉得 离自己的实际应用很远。到了2 0 0 7 年，很多c i o 已经准确理解了 s o a 的内涵及其价值，甚至在系统建设规划中已经在考虑s o a ，这就 是变化。但是这种变化目前还停留在少部分人群中，s o a 若想更大规模 广东上业大学_ 学硕士学位论文 地推广，需要让更多的企业用户实现认知和认可，甚至是投资倾向。因 此，2 0 0 8 年用户认知普及程度将是我们关注s o a 的首要方面。 第二是用户应用推广。s o a 推广的关键是应用落地，经过三年的时 间，s o a 的产品和解决方案已经推向市场，而且在国内主要行业都已经 有了成功的s o a 试点应用，但是目前的典型案例还很少。用户还在考 虑下面几点问题：一是企业的业务需求与内部管理并未形成对s o a 的 i t 系统架构的迫切需求，也就是说企业的业务运营和生产没有达到向用 户提供随需应变的服务的水平，因此它们更无需部署s o a 的i t 系统； 二是企业已有系统较为庞大而复杂，改变整体架构并不是轻而易举的事； 三是s o a 技术、产品和标准都处于发展阶段，不同厂商的解决方案也 存在差异；四是即使在新系统中采用s o a ，用户也存在对s o a 价值认 可程度不足的问题。以上几方面都成为了我们关注s o a 应用推广的关 键。相信在未来三年，随着上述问题的逐步明朗化，s o a 将会走向规模 化应用，而2 0 0 8 年将是这一变化发展的关键阶段。 第三是s o a 需要国内厂商、中间件和中间件平台以外的提供商对 s o a 的全面推动。s o a 已成为了以i b m 、b e a 、s a p 和甲骨文为代表 的典型软件厂商共同关注和推广的主题，甚至部分国际化的主流软件提 供商已经将自己的软件业务的未来惟一战略方向定位于s o a 。 第四是产品的标准化或是技术标准的统一。在推动s o a 的过程中， 几家典型提供商所采用的技术、标准、产品甚至是方法论模型都不尽相 同，这对于企业用户未来系统的应用发展将是不可想象的。中间件本来 就是为了屏蔽底层软件平台的异构、不同应用系统集成兼容的问题，s o a 更是从根本的系统架构上来全面部署企业的i t 系统，而不同提供商所 采用的技术标准都不统一，那么用户即使应用了s o a ，在后续发展中依 然会面临不兼容的问题。可以说这个问题不解决，谈s o a 有点为时过 早，而这需要的是所有提供商的共同努力，同时也需要企业用户从需求 出发来要求提供商积极推动这方面的发展。 第五是s o a 技术和产品的发展。s o a 的技术产品发展不可谓不快， 而计世资讯认为，作为一种重要的新技术趋势，如果要全面影响i t 行 业的发展，就必须有一个相对较长的技术产品推动周期。而2 0 0 8 年将 1 6 第二章面向服务的软件设计方法 继续前两年的这一发展趋势，s o a 的新产品将会继续投入新的用户应 用；同时，我们也看到像w e b 2 0 、虚拟化、统一通信等新技术趋势和 s a a s 、b p m 的热点应用模式正在爆炸式地发展，这些都将对s o a 技术 和产品的发展产生重大影响。 2 5 本章小结 服务的概念已经在软件行业和商业界有了很深的基础。在本章，我们 介绍了s o a 体系结构的概念、组成元素、基本原则以及s o a 服务依赖 的业务流程组件，介绍了当前实现s o a 较为流行的w e bs e r v i c e ，并阐 述s o a 和w e bs e r v i c e 之间的关系；最后，我们给出s o a 架构下软件给 机构带来的技术和业务上的效益，并给出了s o a 当前的发展状况。 有了s o a 架构的基础后，从第三章开始，我们将通过分析统发工资 系统业务的特点，提出在统发工资系统引入s o a 的应用。 1 7 第三章统发工资业务系统 3 1 系统业务特点 3 1 1 统发工资业务 统发工资业务是指行政事业单位财政供养人员工资和离退休费实行 由财政委托银行统一发放。图3 1 表明一个统发业务工