（计算机应用技术专业论文）基于bpel的soa架构应用研究.pdf

哈尔滨工程大学硕十学位论文 摘要 面向服务架构( s o a ) 是一种用于构建复杂企业级应用系统和分布式系统 的先进的软件架构，具有松耦合、平台无关等良好特性。s o a 软件架构为构建 具有灵活性、良好的互操作性的企业级应用提供了良好的解决方案。在基于 s o a 架构的系统中，具体业务功能由许多松耦合的，具有统一接口形式的组 件( 这里使用w e bs e r v i c e ) 构成。要想构建一个业务敏捷的，能够适应业 务变化的企业级系统，s o a 软件架构是最好的选择。 本文在高校信息化建设的背景下，主要研究如何在高校中通过先进的面 向服务的软件架构( s o a ) 来构建能够整合原有异构系统，具有业务灵活，适 应需求变化特性的软件系统。 论文首先阐述了面向服务的软件架构s o a 的概念、目标、架构思想、特 征及原则，接着研究了实施面向服务软件架构主要技术：w e bs e r v i c e s ， w s b p e l 业务逻辑语言和企业级服务总线技术，验证了在j a v ae e 平台下用 w s b p e l 业务流程语言实现面向服务架构的具体实现技术，然后给出了一个 基于w s b p e l 业务流程语言的s o a 架构的层次架构模型，最后，通过一个在 线考试系统的服务整合案例实现和验证了这个系统架构。 关键词：面向服务架构，j a x w s ，业务流程执行语言，w e b 服务 哈尔滨丁程大学硕+ 学位论文 a b s t r a c t s e r v i c eo r i e n t e da r c h i t e c t u r e ( s o a ) i san e wa r c h i t e c t u r ef o rt h e d e v e l o p m e n to faf l e x i b l ee n t e r p r i s es y s t e ma n dd i s t r i b u t e ds o f t w a r es y s t e m i ti s a l la d v a n c e da r c h i t e c t u r eb e c a u s eo fi t sc h a r a c t e r so fl o o s e l yc o u p l i n ga n d p l a t f o r mi n d e p e n d e n c e w i t hs o a ，y o uc a ng i v eag o o ds o l u t i o nt ob u i l d i n ga f l e x i b i l i t ya n di n t e r o p e r a b i l i t ye n t e r p r i s es y s t e m i nt h es y s t e m sb a s e do ns o a a r c h i t e c t u r e 。s p e c i f i ca p p l i c a t i o nf u n c t i o ni s b u i l du pb van u m b e ro ft h e c o m p o n e n t s 。h e r ew eu s ew e bs e r v i c e t h e s ec o m p o n e n t sb el o o s e l yc o u p l e da n d h a v eau n i f i e di n t e r f a c e t h ea r c h i t e c t u r eo fs o ai st h eb e s tc h o o s eo fb u i l d i n ga b u s i n e s sa g i l ea n dc h a n g es u i t a b l ee n t e r p r i s es y s t e m t h e r e f o r e t h es e a r c ho fh o w t ob u i l ds o aa r c h i t e c t u r ei ne n t e r p r i s es y s t e mi sv e r yp r a c t i c a l t h i sp a p e rm a i n l yd i s c u s s e sh o wt ob u i l dab u s i n e s sa g i l ea n dc h a n g e s u i t a b l ea n dt oi n t e g r a t eo l ds y s t e me a s i l yw i t hs e r v i c eo r i e n t e da r c h i t e c t u r eu n d e rt h e b a c k g r o u n do ft h ep r o g r e s so fe d u c m i o ni n f o r m a t i o n f i r s t ，e x p l a i nt h ec o n c e p t ，o b j e c t ，t h ep r i n c i p l e ，c h a r a c t e r so fs o a t h e n ， r e s e a r c ht h ep r i m a r yt e c h n o l o g yo fi m p l e m e n t a t i o no fs 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 t h i si n c l u d e sw e bs e r v i c e s w s b p e la n de n t e r p r i s es e r v i c eb u s p r a c t i c et h ei m p l e m e n t a t i o no fs o au s i n gw s b p e lu n d e rt h ep l a t f o n no f j a v a e e g i v eam o d e lo fl a y e r e ds e r v i c eo r i e n t e da r c h i t e c t u r e f i n a l l y p r a c t i c ea l l t h e s et e c h n o l o g i e sb ya no n l i n ee x a ms y s t e m k e y w o r d s ：s o a ，j a x - w s ，w s - b p e l ，w e bs e r v i c e s 哈尔滨工程大学 学位论文原创性声明 本人郑重声明：本论文的所有工作，是在导师的指导下，由 作者本人独立完成的。有关观点、方法、数据和文献的引用己在 文中指出，并与参考文献相对应。除文中已注明引用的内容外， 本论文不包含任何其他个人或集体己经公开发表的作品成果。对 本文的研究做出重要贡献的个人和集体，均己在文中以明确方式 标明。本人完全意识到本声明的法律结果由本人承担。 作者c 擀：苟霄 日期：护7 年6 月二日 哈尔滨工程大学 学位论文授权使用声明 本人完全了解学校保护知识产权的有关规定，即研究生在校 攻读学位期间论文工作的知识产权属于哈尔滨工程大学。哈尔滨 工程大学有权保留并向国家有关部门或机构送交论文的复印件。 本人允许哈尔滨工程大学将论文的部分或全部内容编入有关数据 库进行检索，可采用影印、缩印或扫描等复制手段保存和汇编本 学位论文，可以公布论文的全部内容。同时本人保证毕业后结合 学位论文研究课题再撰写的论文一律注明作者第一署名单位为哈 尔滨工程大学。涉密学位论文待解密后适用本声明。 本论文( 口在授予学位后即可口在授予学位1 2 个月后口 荔了 碟 ： 阍拣抖“ 噍1 再p d 憾 翮 劲 存 警胄叩默踅 滨)7 蒯钧吖 嘭 登w 哈尔滨工稃大学硕十学付论文 1 1 课题的研究背景 第1 章绪论 随着高校信息化建设的快速发展，应用于高教领域的信息系统从数量和 规模上迅速增加。多年的持续i t 投入，留下了大量的异构系统，形成很多“信 息孤岛”。这些异构的系统往往具有重复的功能，或者具有大量冗余的数据， 如何尽可能的重用已有的业务逻辑和共享数据，成为目前高校信息化过程中 不可回避的一个头疼的问题。另外，在这些遗留系统之上开发新系统也仍然 要面临如何保护原有i t 投入，与原有系统进行业务集成的问题。 作者所在高校成立仅十年，短短十年中信息中心就先后购买和研发了教 务管理、学生管理、设备管理、人力资源管理、网络办公等软件系统。学院 信息中心一度为学院信息化水平的先进性而陶醉。然而，随着软件系统的数 量和规模的不断增加，信息管理部门却再也高兴不起来了，不仅仅是因为有 大量需要维护的软件系统，让他们一筹莫展的是这些独立的软件系统往往不 得不重复许多已有的业务功能，而且相互之间共享和重用非常困难。更为可 怕的是随着学院的不断改革发展，各个软件系统需要不断的修改业务逻辑以 适应需求的不断变化，这意味这需要不断的进行二次开发或研发新系统，也 就意味着不断的i t 投入，这似乎成了一个无底洞。这种现象在企业级应用中 较为普遍，也是近些年来困扰软件行业的一个头疼的问题。 本研究就是在这样的背景下，试图找到一种切实可行的解决方案，并应 用于信息化建设的实践。作者阅读了大量的资料，考查了很多行业的同类问 题的解决方案，认为面向服务的软件架构( s o a ) 是目前解决异构系统集成， 以及构建业务敏感、适应需求变化的信息系统的做好方案。 面向服务架构( s e r v i c e o r i e n t e da r c h i t e c t u r e ，s o a ) t 是为解决前述问题 而出现的，因而s o a 架构被一致认为有着很好的前景。面向服务的软件架构 哈尔滨1 二程大学硕十学位论文 能实现对传统系统的重用与封装，而不用对其进行修改。它强调服务的复用 性，能解决客户端与服务端之间的紧耦合问题，使服务使用者和服务提供者 在保持接口契约一致性的情况下可以独立演化，这样既可以保护原有的软件 系统的投资，又可以基于已有的服务灵活重组或开发新的业务逻辑以适应不 断变化的需求。 将s o a 先进的软件架构应用于高校信息化过程显然可以从根本上解决 高校内部甚至高校之间的信息孤岛问题，可以有效整合己存在的异构遗留系 统，有效地保护和延续旧有i t 资金的投入，使信息技术在高等教育中发挥核 心价值。 1 2 面向服务架构( s o a ) 的发展 面向服务的软件架构( s o a ) 的提出已经有些年了，1 9 9 6 年，g a r t n e r 最早提出面型服务软件架构( s o a ) 的思想，2 0 0 2 年1 2 月，g a r t n e r 提出s o a 是“现代应用开发领域最重要的课题”1 1 】，2 0 0 4 年初业界推出s o a 标准，2 0 0 5 年，一些i t 组织成功建立并实施s o a 应用软件，i b m 等厂商看到其价值， 也纷纷推出自己的s o a 解决方案；到2 0 0 8 年左右面向服务软件架构( s o a ) 才迅速兴起。s o a 作为一种新型的软件开发体系结构，具有无可比拟的优 势，符合按需计算的发展潮流，尤其适用于企业级的复杂业务应用开发。随 着互联网络的进一步发展，分布式应用的不断普及，s o a 的应用会更加的普 遍并被人们所接受，成为继面向对象、面向组件之后的新的设计方式。因此 可以预见，s o a 的发展会对软件设计思想产生很大的影响并对分布式企业应 用的不断普及起到重大的促进作用。可以使企业具有更迅速的响应能力，更 灵活的变化能力，是随需应变信息系统发展的重要技术，因此具有良好的发 展前景。 s o a 作为新一代的软件构架，在未来5 1 0 年里将给软件产业带来革 命性的变化。在s o a 时代，任何一个大的应用软件系统，都不再由一个软件 2 哈尔滨工程大学硕士学位论文 开发商独立完成，而是由不同厂商生产的基于标准和接口的服务相互协作完 成。每个厂商将专注于一种或几种服务类型的开发，努力提高这些服务的性 能和质量。从软件产业总体上看，这将降低软件开发成本，提高软件质量， 大大减少目前各软件厂商之间相同软件部分重复开发的问题。 1 3国内外研究现状及存在的问题 2 0 0 8 年以来，面型服务的软件架构( s o a ) 迅速被业界认可和支持，很 多大行业都倾向于转向s o a 框架结构架构他们的i t 系统。将这种先进的软 件架构应用高等教育信息化也是大势所趋。 1 3 1 国内外研究、应用现状 在国外，已经有了很多的成功的应用案例，将s o a 的设计思想应用到医 疗、电信、金融、电力等各行业，带来了巨大的价值。也有很多国际大公司 专注于s o a 架构的研究和应用，己经进入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 的推广应用也处于起步阶段，国内s o a 的发展需要积累大量的研发、 应用和推广经验，才能赶上并超越国外的先进水平。 但是，国内软件企业也具有一定的优势，第一，软件行业的发展不像其 他科研领域那样技术封锁严密，理论上我们完全可以迅速赶超他们；第二， 中国巨大的s o a 应用的市场，为我国s o a 研究发展提供的巨大的动力；第 三，国外软件企业在本地化进程中完全没有优势。所以，国内s o a 虽然起步 较晚，却具有巨大的潜力。 现在我国教育信息化的基础设施建设已经初具规模，特别是高等院校， 哈尔滨 二程大学硕士学位论文 教育信息化的基础设施建设相对比较完备。随着硬件条件的成熟，各级教育 部门为各自的发展建立了规模不一的信息系统【2 】。 目前绝大多数教育信息系统都是功能固定的并且缺乏灵活性，无法适应 教育事业业务不断扩展与变更的进化需求，很多单位教育局经常是投巨资建 起了自己的信息系统，但往往因为领导换届、业务模式变化等原因，要求系统 功能上有所变更，系统却无法适应变化，只能再开发一个新的，永远处于一 种新的系统替代旧的系统的状态，而不能在已有的系统上进化发展，不能实 现多个系统的聚合效应，也不能实现积累和进化。并且绝大部分大型教育机 构的信息系统建设都是条块分割的，各部门自行开发自己的系统，缺乏标准 化、规范化和兼容性，信息资源难以共享，出现了一个个“信息孤岛”，与网络 共享的基本要求背道而驰。单个部门，或多或少有一些应用系统，但是他们相 互之间却不能实现数据共享，不能进行互联互通。 国内面向服务软件架构( s o a ) 在高等教育领域的应用严重滞后于电力、 电信、能源、交通等大行业的应用领域。主要源于高校和研究机构重研究轻 应用，在工程应用领域相对滞后于其他行业。因而将s o a 软件架构应用于高 校信息化建设非常迫切。 1 3 2s o a 架构对国内软件行业的重要意义 在国外，s o a 的大规模实施受到传统软件厂商形成的利益团体的阻碍， 同时，由于国外信息化建设比较饱和，市场需求乏力，因此s o a 并没有规模 化出现。但是，在标准建设、技术研究以及成熟的工具方面，国外已经有相 当的积累。在国内，市场应该能快速接受s o a 的技术与建设，同时，政府相 关管理部门能否看到s o a 对国内软件产业的革命性影响，将成为能否促使中 国成为s o a 技术的应用大国，从而成为领导世界s o a 应用发展的重要因素。 s o a 将会使由中国集成商转型成的咨询服务商更有竞争力，因为他们更 了解本地的行业特色及具体实践。这些集成商将有机会找到自己真正具有优 势的领域，从而摆脱只能处于价值链低端的不利局面。s o a 也将让中国的软 4 哈尔滨工程大学硕十学位论文 件外包公司有一个明确的业务方向及核心技术能力，让中国所生产的标准化 软件服务像中国的鞋、纺织品、小商品一样，畅销世界。 总之，s o a 是中国软件行业的一个重要机会，甚至很可能是未来2 0 年 里的唯一机会【3 j 。 1 3 3s o a 架构对高校信息化的重要意义 随着现代通信技术、计算机网络技术以及信息产业的飞速发展和普及， 高校信息化建设正在向全面数字化的方向一“数字化校园 迈进。为此，我 们提出了校园信息化统一平台的方案，以构成统一的用户管理、统一的资源 管理和统一的权限控制。由于传统的软件开发使用的平台、开发工具、操作 系统在结构上的耦合，使得过去校园内位置分散的各种管理系统如：务管理 系统、学生管理系统、科研管理系统、教学辅助系统、财务管理系统等逐渐 形成了“信息孤岛”。学校不希望废弃原有的系统重新研发，那样代价太高 昂，也不科学，因为重新开发后将来可能还会遇到类似的问题。当前数字化 校园建设的关键问题在于，如何重用已有的管理系统模块，加快数字化建设 步伐，并使得被重用的模块最好是“非侵入的方式，将这些系统中的数据 和功能包装起来，方便地将旧系统纳入新系统。基于面向服务的体系结构 ( s o a ) 的校园信息化统一平台方案，在不改变学校各种应用底层架构的基础 上，可以很好地解决上述问题，它支持在中间层以服务模块方式实现的解决 方案，当多个运行在不同平台和技术下的应用程序需要相互通讯时，这种 s o a 结构尤其适用【训。 1 4 本文的研究目标与内容 本文目标是在高校信息化的背景下对新兴的s o a 软件架构进行研究和 应用。本文主要关注于解决以下几个问题：第一，深入阐释s o a 架构的概念、 思想和原则；第二，研究w e bs e r v i c e 相关的理论及技术实现，研究业务流 程语言w s b p e l 及其实现技术；第三，提出一种具有推广意义的j a v ae e 哈尔滨工程大学硕士学位论文 平台下s o a 架构的实现方案。 本文围绕研究目标，具体内容阐述如下： 第二章：面向服务的架构，主要介绍了面向服务架构s o a 的架构概念、 特征、实施目标和原则，阐述s o a 架构计本模型，以及实施s o a 架构的优 势所在。 第三章：实现s o a 架构的相关技术，本章主要介绍实施s o a 所需要的相 关技术，主要介绍目前主流方案所需要的技术，主要包括：x m l 、w e b s e r v i c e 、w s b p e l 和e s b 等。 第四章：j a v ae e 平台下s o a 的实现技术，本章只要研究在j a v ae e 平 台下如何开发和发布w e bs e r v i c e ，如何使用w s b p e l 语言及相应的工具 来开发业务流程。 第五章：使用s o a 架构整合系统资源，本章主要介绍如何使用s o a 架 构进行高校软件系统资源的整合和开发新系统。分析整合需求，设计s o a 系 统架构模型，最后通过在线考试业务流程的整合实现验证了基于b p e l 的 s o a 架构模型和实现技术。 6 哈尔滨t 程大学硕十学位论文 第2 章面向服务的企业级架构 2 1 面向服务软件架构( s o a ) 的概念 s o a 一直被业界认为是最有前途的企业级架构方案，各大软件组织和软 件公司争相转向这种新兴的软件架构，而且推出了一些市场化的s o a 产品。 但是，迄今为止，对于面向服务的体系结构( s o a ) 还没有一个公认的定义。 许多组织从不同角度和不同侧面对s o a 进行了描述。下面给出业界一些关于 s o a 定义： 万维网联盟( w o r l dw i d ew e bc o n s o r t i u m ，w 3 c ) 将s o a 定义为【5 】：“一 种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务， 这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来 形成务流程”。w 3 c 将服务定义为：“服务提供者完成一组工作，为服务使 用者付所需的最终结果”。 s e r v i c e a r c h i t e c t u r e t o m 将s o a 定义为1 6 】：“本质上是服务的集合。服 务间此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务 协调行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、 封装善、独立于其他服务所处环境和状态的函数 。 g a r t n e r 将s o a 定义为：“面向服务的体系结构( s o a ) 是客户端朋艮务器 的软件设计方法，一项应用由软件服务和软件服务使用者组成，s o a 与大多 数通用的客户端服务器模型的不同之处，在于它着重强调软件组件的松散耦 合，并使用独立的标准接口1 7 ”。 从上述的定义中我们可以看到s o a 的几个关键特性：首先，将所有的功 能都定义为独立的服务；第二，服务是粗粒度、松耦合的，可以是异构的； 第三，所有的服务之间都通过明确定义的契约进行通讯，对底层编程接口和 通讯模型透明；第四，服务是被大粒度的重用。 7 哈尔滨t 程大学硕士学位论文 s o a 不是一种具体的技术，而是一种软件系统架构方法。在s o a 架构 下，业务逻辑以服务的形式出现，服务可以在应用程序之间、企业之间被共 享、重用和配置。在s o a 架构企业应用集成时，服务在开发之时就已经考虑 到重用问题，并提供了标准的接口，可以被各种应用和其他服务所调用。因 此通过s o a 架构，服务可以独立地设计和开发，在需要的时候通过集成，服 务成为应用程序的一部分。 这里，我们可以将面向服务的体系结构定义如下：面向服务的体系结构 是一个基于服务的开放的、可扩展的、可重用的组件模型。服务是程序功能 单元的封装，服务之间通过定义良好的接口和协议联系起来，接口的定义独 立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这样的系 统中的服务可以用一种一致的方式进行交互。 2 2 实施s o a 的目标 实施s o a 架构，是要给我们的i t 投入创造更大价值，所以我们要始终 清楚实施s o a 的目的是什么，否则错误的理解和实施s o a 可能使事情变得 更糟。我们分析一下实施s o a 项目的主要目标： 1 获得流程的可见性和灵活性 s o a 潮流无疑具有巨大的潜力。s o a 已经逐渐融合了分布式计算领域的 几个重大变化。许多组织总是大力投资技术，以便领先竞争对手，而s o a 正 是提供了这种突破性机会。与此同时，许多组织还一直在改善业务流程，以 充分发掘竞争优势。 新出现的业务流程管理( b p m ) 有望不断改进流程、促进业务部门和i t 部 门之间实现前所未有的协作。s o a 是集大成者，在它的统领之下，多家组织 齐心协力，获得全面了解数据和流程的可见性、不断进行改进，并且以一种 有效、透明的方式实施细粒度控制。 2 消除孤岛 s o a 的第二个目标就是消除应用、部门、交易合作伙伴当中的孤岛。这 8 哈尔滨工程大学硕士学位论文 些孤岛是由于多年的软件开发工作形成的，s o a 有望消除这些孤岛，让组织 获得更清楚地了解数据及流程的可见性。 3 管理更准确的数据 一家组织不但需要更有效地管理数据，还需要管理更准确的数据。确保 这一点很重要：跨组织及交易合作伙伴生成及使用的数据是干净的、可靠的、 安全的、妥善管理的、易于获取的。s o a 的目标之一就是，为组合式数据服 务平台提供一套统一的组件，这些组件用于数据存取、质量、转换、管理、 缓存及其他许多以数据为中心的服务。 4 重复使用服务 s o a 的一个相关目标就是有效地管理及重复使用企业的服务和数据。如 果由组织内某一部门开发的服务在易于访问的注册中心里面采用标准格式发 布并加以描述，它们就可以供该组织内外的其他任何部门使用。如果数据和 服务属于所有者，使用者需要时，又可以共享它们，就能减少与维护及管理 数据和服务有关的操作成本。重复使用是s o a 最主要的优点之一。 5 统一组织目标 s o a 的另一个目标就是协调业务部门和i t 部门，共同实现组织的目标： 有助于更好地开发灵活、可配置的业务流程。在过去，业务部门和i t 部门几 乎采用独立的方式来提高组织的经济效益。 2 3s o a 的基本架构 面向服务的架构是一种面向服务的企业应用体系结构，是一种分布式的 软件架构模型。在这种体系结构中所有的功能都用相互独立的服务来实现， 它们可能集成在一个应用中，也可能是分布在互联网上或者建立在异构的平 台上。s o a 的核心理念是将应用程序的不同功能组件从复杂的环境中独立出 来并组件化封装为服务。 s o a 是一种设计方式，它指导着业务服务( b u s i n e s ss e r v i c e ) 在其生命周 期中包括创建和使用的方方面面。s o a 也是一种定义和提供i t 基础设施( i t 9 哈尔滨t 程大学硕士学位论文 i n f r a s t r u c t u r e ) 的方式，它允许不同应用相互交换数据、参与业务流程，无论 它们各自背后使用的是何种操作系统或采用了何种编程语言博j 。 s o a 体系结构由服务提供者、服务请求者和服务注册中心组成，基本操 作包括服务注册发布、服务查找和服务绑定，如图2 1 所示。 图2 1s o a 基本架构 1 服务提供者( s e r v i c ep r o v i d e r ) 服务提供者是一个可通过网络寻址的实体，它接受和执行来自服务请求 者请求。它将自己的服务和接口契约发布到服务注册中心，以便服务请求者 可发现和访问该服务。 2 服务请求者( s e r v i c er e q u e s t e r ) 服务请求者负责查找发布在一个或者多个服务注册中心的服务描述，并 负责利用服务描述，绑定或者调用由服务提供者提供的服务。服务请求者有 时候叫服务使用者、服务消费者。 3 服务注册中- i 二, ( s e r v i c e sr e g i s t r y ) 服务提供者可以在服务注册中心发布服务描述，服务注册中心负责为其 登记，并允许服务请求者搜索服务注册中心所包含的服务描述集合。服务注 册中心的作用就是服务请求者和服务提供者之间的中介。一旦服务注册中心 l o 哈尔滨工程大学硕士学位论文 完成了匹配，它也就完成了任务，其余的交互也就是在服务请求者和服务提 供者之间的直接服务调用。服务契约是服务请求者和服务提供者间交互方式 的规范，指明了服务请求和响应的格式【9 1 。 对应于s o a 中的三个角色，s o a 也包含三个操作：发布( p u b l i s h ) 、发现 ( f i n d ) 和绑定调用( b i n d i n g i n v o k e ) 。这些操作定义了s o a 角色之间的约定 关系。 1 发布操作是一种服务注册或者服务登记的行为。它起着服务注册中心 与服务提供者之间的连接作用。当服务提供者在服务注册中心发布其服务描 述后，服务注册中心就将该服务的细节通知给服务请求者。发布的实际细节 取决于服务注册中心的实现。简单的发布是将服务描述发布到应用服务器的 目录结构中，复杂的发布操作则通过独立的单元来管理服务描述。 2 发现操作是获得服务的调用细节信息，起着服务注册中心和服务请求 者之间连接作用。在进行发现操作时，服务请求者向服务注册中心提供查询 条件，如服务类型、服务质量保证、安全验证等等。服务注册中心根据查找 条件在所发布的服务描述结合中进行搜索，查找与查找标准匹配的服务描述。 3 绑定操作是服务请求者通过分析从服务注册中心中得到的服务绑定 信息，包括服务的访问路径、服务调用的参数、返回结果、传输协议、安全 要求等，对自己的系统进行相应配置，进而远程调用服务提供者所提供的服 务。 从概念上讲，s o a 中有四个不同抽象级别的组件：消息、操作、服务 和业务流程。 消息代表完成工作单元所需要的部分或所有数据。操作代表单个逻辑工 作单元( l o g i c a lu n i to fw o r k ，l u w ) 的事务。每一个操作监管服务能够执行 特定功能的处理。执行操作通常会导致读、写或修改一个或多个持久性数据。 s o a 操作可以直接与面向对象( 0 0 ) 的方法相比。它们都有特定的结构化 接口，并且返回结构化的响应，完全同方法一样，特定操作的执行可能涉及 哈尔滨工程大学硕士学位论文 调用附加的操作。服务代表操作的逻辑分组。业务流程是为实现特定业务目 标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。 在s o a 术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列 操作。操作的排序、选择和执行称为服务或流程编排。操作发送及接收消息 以执行工作，操作最常由其处理的消息来定义。服务最常由包含它的操作来 定义。流程实例可组成服务，但是不必由其服务定义，因为也许只需要服务 所提供的功能子集。 2 4s o a 的特征 实施s o a 的关键目标是实现企业i t 资产的最大化重用。要实现这一目 标，就要在实施s o a 的过程中牢记以下特征【1 1 】： 1 可从企业外部访问 通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服 务。业务伙伴采用先进的b 2 b 协议相互合作。当业务伙伴基于业务目的交换 业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多 条业务信息的交换。会话类型( 会话复杂或简单、长或短等) 取决于业务目 的。除了b 2 b 协议外，外部用户还可以访问以w e b 服务方式提供的企业服 务。 2 随时可用 当有服务使用者请求服务时，s o a 要求必须有服务提供者能够响应。大 多数s o a 都能够为门户应用之类的同步应用和b 2 b 之类的异步应用提供服 务。同步应用对于其所使用的服务具有很强的依赖性。许多同步应用通常部 署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同 步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着 提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。 相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以 容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台， 1 2 哈尔滨工程大学硕士学位论文 用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时 间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将 罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死 锁。服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。 在多数情况下，采用异步模型可以达到同样的效果，但更能够体现s o a 的最 佳特性。当然，并不是所有情况下都应当采用异步设计模式。但大多数情况 下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很 短时尤其如此。 3 粗粒度服务接口 粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方 法。举个例说明最为清楚向计费系统中添加一个客户是典型的粗粒度服务， 而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统 中，添加详细的客户联系方式、添加计费信息等等。 采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的 往复，一次往复就足够。i n t e m e t 环境中有保障的t c p i p 会话已不再占据主 导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接 口的优点更为明显。 除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包 含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中 止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反 馈的唯一途径。 4 分级 一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为 粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。 解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服 务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差 哈尔滨t 程大学硕十学位论文 的服务。 在服务分级方面，须注意服务层的公开服务通常由后台系统( b e s s ) 或 s o a 平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重 要的。正确的文档、配置管理和私有服务的重用对于i t 部门在s o a 服务层 快速开发新的公开服务的能力具有重要影响。 5 松散耦合 s o a 具有“松散耦合组件服纠1 2 1 ，这一点区别于大多数其他的组件架 构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务 方面隔离开来。 服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服 务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情 况下进行修改。 大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够 兼容多种传输方式( 如h t t p 、j m s 、t c p i p 、m o m 等) 。基于消息的接口 可以采用同步和异步协议实现，w e b 服务对于s o a 服务接口来讲是一个重 要的标准。 当使用者调用一个w 曲服务时，被调用的对象可以是c i c s 事务、d c o m 或c o r b a 对象、j 2 e ee j b 或t u x e d o 服务等，但这与服务使用者无关。 底层实现并不重要。 消息类w e b 服务通常是松散耦合和文档驱动的，这要优于与服务特定接 口的连接。当客户调用消息类w e b 服务时，客户通常会发送的是一个完整的 文档( 如采购订单) ，而非一组离散的参数。w e b 服务接收整个文档、进行 处理、而后可能或者不会返回结果信息。由于客户和w e b 服务间不存在紧密 耦合请求响应，消息类w e b 服务在客户和服务器间提供了更为松散的耦合。 6 可重用的服务及服务接口设计管理 如果完全按照可重用的原则设计服务，s o a 将可以使应用变得更为灵 1 4 哈尔滨工程大学硕十学位论文 活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量 时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工 作。由于服务设计是成功的关键因此，因此s o a 实施者应当寻找一种适当的 方法进行服务设计过程管理。 服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷? ? 走捷径的项目战术与企业构建可重用通用服务的长期目标。超越项目短期目 标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还 需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。 在大型组织中实现重用的一个先决条件是建立通用( 设计阶段) 服务库 和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发 的服务文档进行评估也是成功利用服务库的关键。 简言之，不按规则编写服务将无法保证可提供重用性的s o a 的成功实 施。在执行规则的过程中会产生财务费用，需要在制定s o a 实施计划时加以 考虑。 7 标准化的接口 近年来出现的两个重要标准x m l 和w e b 服务增加了全新的重要功能， 将s o a 推向更高的层面，并大大提升了s o a 的价值。尽管以往的s o a 产品 都是专有的、并且要求i t 部门在其特定环境中开发所有应用，但x m l 和 w e b 服务标准化的开放性使企业能够在所部署的所有技术和应用中采用 s o a 。这具有巨大的意义。 w e b 服务使应用功能得以通过标准化接口( w s d l ) 提供，并可基于标 准化传输方式( h t t p 和j m s ) 、采用标准化协议( s o a p ) 进行调用。例如， 开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可 以重用e r p 系统和定制化j 2 e e 应用中的现有服务，而完全无须了解这些应用 的内部工作原理。采用x m l ，门户开发人员无须了解特定的数据表示格式， 便能够在这些应用间轻松地交换数据。也可以不采用w e b 服务或x m l 来创 哈尔滨工程大学硕十学位论文 建s o a 应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前 只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为 企业的服务访问方法。 8 支持各种消息模式 s o a 中可能存在以下消息模式。在一个s o a 实现中，常会出现混合采 用不同消息模式的服务。 1 ) 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处 理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信 息，从而更易扩展。 2 ) 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息 包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信 更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其 整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提 高了交换服务提供者的服务难度。 3 ) 等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相 同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改 进服务可靠性。 9 精确定义的服务接口 服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及 使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意 的关键点是，服务契约必须进行精确定义。 m e t a 将s o a 定义为：“一种以通用为目的、可扩展、具有联合协作 性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托 给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。 该定 义的最后部分表明在服务接口和其实现之间有明确的分界。 2 5 实施s o a 的原则 1 6 哈尔滨t 稃大学硕士学位论文 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 工作的场景，更像是一个活的生 物体，而不是像传统所说的“盖一栋房子”。i t 环境惟一不变的就是变化， 因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师 来说，要转向设计一个活的生物体要求有崭新的思维方式。s o a 的基础还是 一些类似的架构准则。 2 6s o a 的优势 在企业级应用中采用面向服务的体系结构具有以下优势【1 4 】： ( 1 ) n 用现有的资产 s o a 提供了一个高层次的抽象层，通过这个抽象层，可以将业务构造成 现有服务的集合。使用这种新的服务只需要知道它的接口和名称，服务的内 部细节以及组成服务的组件之间的数据复杂性都对外界隐藏了。这种组件的 匿名性使组织能够利用现有的资产，从而通过合并构建在不同的机器上、运 行在不同的操作系统中和用不同的编程语言开发的组件来创建服务。组织可 以继续从现有的资源中获益，而不必重新构建系统。 ( 2 ) 更易于集成和管理 1 7 哈尔滨工程大学硕士学位论文 在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现的 透明性，并将因为基础设施和实现发生的改变带来的影响降到最低限度。通 过提供针对基于完全不同的系统构建的服务规范，使应用集成变得更加易于 管理。特别是当多个企业一起协作时，这会变得更加重要。 ( 3 ) 更快的开发速度 利用现有的组件和服务，可以缩短软件开发生命周期( 包括收集需求、进 行设计、开发和测试) 。包含松散耦合的、可组合的、以及可互操作的和有复 用潜力的服务的标准化技术环境，可以建立更具适应力的自动化环境，从而 提高了企业适应业务变化的能力。 ( 4 ) 与技术的松散耦合 在基于s o a 的应用开发中，服务建模独立于服务的执行环境。通过构建 服务能够建立一个业务逻辑抽象和技术抽象，把业务逻辑与具体实现技术分 离开来，使企业应用彻底摆脱、面向技术的解决方案的束缚。 ( 5 ) 有利于职责的划分 业务人员和技术人员分别关注业务问题和技术问题，两组人员通过服务 契约进行协同。 2 7 本章小结 本章首先对面向服务的软件架构( s o a ) 的概念进行了阐述，根据s o a 实施的目标，说明了面向服务软件架构的架构思想、架构特征、实施原则， 总结了面向服务软件架构的先进性。 1 8 哈尔滨工程大学硕士学传论文 第3 章实现s o a 的相关技术 3 1w e bs e r v i c e s 近年来w e bs e r v i c e 获得了巨大发展。许多软件公司纷纷宣布了对w e b s e r v i c e s 的支持和应用。w e b 服务( w e bs e r v i c e s ) 是目前程序设计领域中的一 项新技术，是一个崭新的分布式计算模式，在不同系统平台之间具有互操作 性，通过因特网，实现不同应用程序之间的远程过程调用。 3 1 1w e bs e r v i c e s 的概念 根据w 3 c 关于w e b 服务的定义，w e b 服务是用于支持网络上机器与机 器间互操作的软件系统。包含机器可处理的格式描述的接口( 特别的如 w s d l ) 。其他系统与w e b 服务的交互，采用s o a p 消息描述，h t t p 以及与 x m l 序列化相关的其他w e b 标准进行传输1 1 5 】。