（计算机软件与理论专业论文）基于soa的应用系统的设计与实现.pdf

中文摘要 中文摘要 摘要：s o a ( 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 是解决这两个难题的最佳方案，s o a 更易于集成和管理复杂性， 具有更快的响应速度，能够减少成本和增加重用。设计良好的缓存机制，减少分 布式环境中相当耗费资源的远程服务的响应时间，是面向服务应用的关键。当服 务分布到不同的服务器和地理位置时，很难追踪服务的操作和错误，需要创建可 靠的日志记录底层结构。 本文从引入s o a 的概念和面向服务的思想开始，分析了s o a 的特征、体系结 构组成、角色及其协作，重点研究并论述了服务的概念及其设计原则。在此基础 上，设计并实现了基于s o a 的某企业应用系统的部分子系统。本文主要通过w e b s e r v i c e 实现s o a ；分析了怎样提高服务的可扩展性、性能和可靠性；描述了服务 设计中自治性、安全性及参数设计等方面的处理。随后本文设计了一个由业务驱 动的多库的数据库方案；提出了包括浏览器，i i s 页面和应用数据缓存的缓存方案， 并设计了依赖于数据库的应用缓存的刷新机制；建立了插件式的日志记录模块， 通过读取配置文件任意组合多种日志类型与记录方式；以系统管理为例阐述了本 应用的业务服务设计，以及系统中体现的面向服务开发的思想。最后本文给出了相 关实现。 图1 5 幅，表4 个，参考文献3 2 篇。 关键词：面向服务的体系结构：w e b 服务；服务设计；缓存设计 分类号：t p 3 1 1 5 2 a b s t r a c t ：s o a ( 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 ) i sac o m p o n e n tm o d e l ，w h i c hw i l l b ea p p l i e dt oc o n t a c td i f f e r e n tf u n c t i o nc o m p o n e n t s ( s e r v i c e ) o fa l la p p l i c a t i o n ，u s i n g t h ew e l l d e f i n e di n t e r f a c e sa n dc o n t r a c tb e t w e e n s e r v i c e s ”t h e s ei n t e r f a c e sa t ed e f i n e d u s i n gan e u t r a lp a t t e r n ，w h i c ha r ci n d e p e n d e n to nt h eh a r d w a r ep l a t f o r m ，o p e r a t i n g s y s t e ma n dp r o g r a m m i n gl a n g u a g et h a tr e a l i z i n gt h e s e r v i c e s ”t h i sm a k e ss e r v i c e s i n t e r a c tw i t ho t h e rs e r v i c e si nv a r i o u ss y s t e m sw i t hi n t e g r a t e da n dg e n e r a lm a n n e l t h ea p p l i c a t i o n s y s t e md e v e l o p m e n ti sf a c i n gp r o b l e m so fh e t e r o g e n e o u s a r c h i t e c t u r ea n dr a p i dc h a n g e m o s to fe n t e r p r i s e sh a v ei t ss o f t w a r ei nd i f f e r e n tp e r i o d a n du s ea l lk i n d so ft e c h n i q u e s m e a n w h i l ei n t e n s i v ec o m p e t i t i o n sr e s u l ti ni n c r e a s i n g r e q u e s t sf r o mc u s t o m e r s s o ai st h eb e s ts o l u t i o nt os o l v et h e s et w op r o b l e m sf o ri t s l o o s ec o u p l i n ga n ds t a n d a r di n t e r f a c e i tm a k e si te a s i e rf o ri n t e g r a t i o na n dm a n a g e m e n t o fc o m p l e x i t y ，h a saf a s t e rr e s p o n s es p e e d i tc a l la l s or e d u c ec o s t sa n di n c r e a s er e u s e d e s i g n i n gas t a n d o u tc a c h i n gm e c h a n i s mt or e d u c et h er e s p o n s et i m eo f r e m o t es e r v i c e i nd i s t r i b u t e de n v i r o n m e n ti sac r i t i c a lc h a l l e n g ei nm a n yr e a ll i f ec a s e s w h e nt h e s e r v i c e sd e p l o y e dt od i f f e r e n ts e r v e r sa n dl o c a t i o n ，i ti sd i f f i c u l tt ot r a c et h eo p e r a t i o n s a n de r r o r s ，s oar e l i a b l el o gr e c o r d sf r a m e w o r kn e e dt ob ee s t a b l i s h e d i nt h ef i r s tp a r to ft h i st h e s i s ，t h ec o n c e p t sa n ds e r v i c e o r i e n t e dt h i n k i n ga l e i n t r o d u c e d ，a n dt h ec h a r a c t e r i s t i c s ，a r c h i t e c t u r e ，r o l e sa n dt h e i rc o l l a b o r a t i o no fs o aa t e a n a l y z e d ；t h ec o n c e p ta n dd e s i g no ft h es e r v i c e sa t ef o c u s e do n f o rf u r t h e r , b a s e do n t h e s es t u d i e s ，s o m es u b s y s t e m so fa ne n t e r p r i s ea p p l i c a t i o nb a s e do ns o aa t ed e s i g n e d a n di m p l e m e n t e d t h ei m p r o v e m e n to fe x t e n s i b i l i t y , p e r f o r m a n c ea n dr e l i a b i l i t yi s a n a l y z e db yt h i sw e bs e r v i c ea p p l i c a t i o n t h ew a yo fd e s i g na u t o n o m o u sa n ds e c u r c s e r v i c e ，t h ea r g u m e n td e s i g n i n go fs e r v i c ei sd e s c r i b e d b e s i d e s ，am u l t i d a t a b a s e s o l u t i o nd r i v e nb yb u s i n e s si sd e s i g n e d t h ei n t e g r a t e da p p r o a c hc o n t a i n st h eb r o w s e r , i i sp a g ea n dt h ea p p l i c a t i o nd a t ac a c h ew i t har e f r e s hm e c h a n i s mi sp r o p o s e d al o g r e c o r d sm o d u l ei sb u i l t ，w h i c hc a nm a k ev a r i o u sl o gt y p e sa r b i t r a r yc o m b i n ew i t hm e d i a t h r o u g hc o n f i g u r a t i o nf i l e u s i n gs y s t e mm a n a g e m e n ts u b s y s t e ma sa ne x a m p l e ，t h e d e s i g no fb u s i n e s ss e r v i c e sa n dt h i n k i n go fs e r v i c e - o r i e n t e dd e v e l o p m e n ti sd e s c r i b e d f i n a l l y , r e l a t i v ei m p l e m e n t a t i o n sa t eg i v e n k e y w o r d s ：s o a ；w e bs e r v i c e ；s e r v i c ed e s i g n ；c a c h ed e s i g n c i 。a s s n o ：t p 3 5 2 学位论文版权使用授权书 本学位论文作者完全了解北京交通大学有关保留、使用学位论文的规定。特 授权北京交通大学可以将学位论文的全部或部分内容编入有关数据库进行检索， 并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国 家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 本学位论文保密，三年内不得公开发表。 学位论文作者签名： 0 强气 导师签名： 压_ 签字日期：b p 年f 1 月1 日 签字日期：2 刎石年加日 致谢 本论文的工作是在我的导师康川老师的悉心指导下完成的，康川老师严谨的 治学态度和科学的工作方法给了我极大的帮助和影响。在此衷心感谢三年来康川 老师对我的关心和指导。 贾卓生老师悉心指导我完成了实验室的科研工作，在学习上和生活上都给予 了我很大的关心和帮助，在此向贾卓生老师表示衷心的谢意。 白建军老师对于我的科研工作和论文都提出了许多的宝贵意见，在此表示深 深的感谢。 在实验室工作及撰写论文期间，刘成、周艳、孟旭老师对我的论文提出了许 多的有益建议，刘开、熊飞等同学对我论文中的w e bs e r v i c e 相关研究工作给予了 热情帮助，在此向他们表达我的感激之情。 另外也感谢我的父母和家人，感谢他们对我始终如一的支持与关怀，他们的 理解和支持使我能够在学校专心完成我的学业。 最后感谢各位专家评委耐心审阅我的论文。 引言 1 引言 1 1研究背景及意义 1 1 1 应用系统开发对软件体系结构的新需求 目前，应用系统的开发面临着两个基本的问题：异构和改变。 一方面，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的 体系结构。不同技术使应用之间的通讯变得十分困难，而且代价高昂。由于每个 应用都有自己的基础架构，在部署、更改和维护上成本很高，企业不得不为每套 应用配置特有的专业技术人员，并保持与不同技术提供商或解决方案供应商的密 切合作。同时这些应用不能方便的被重用，也不能随着企业商务的扩展实现应用 规模的扩展。虽然用户希望尽可能地消除这些“信息孤岛一，但“孤岛 本身却又 是他们难以舍弃的重要投资，如何保护前期投资对企业的应用系统提出了最强有 力的挑战【1 1 。而集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们 也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此 之难【刃。 另一方面，全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争， 产品周期缩短了，在竞争产品和可以从i n t e r a c t 上获得的大量产品信息的推动下， 客户的要求更快速地进行改变。为了满足客户提出的越来越多的新要求和产品、 服务方面的改进，应用软件必须具有灵活性，比如快速的应用集成，自动化业务 流程，支持多渠道服务( 包括固定设备和移动设备) 的应用，以更好地适应这种 改变。 1 1 2 传统应用系统体系结构的局限性 异构意味着对跨平台的需求，改变意味着对松耦合、重用的需求，而传统的 应用系统基本上是按照业务流程逐一对应开发的，虽然任何应用都包含最基本的 三个内容：界面展现、业务逻辑和数据处理，但是因为每个应用自成体系，在开 发一个新应用时并不能重用原来的成果，而是需要重开发一遍界面与数据处理， 重写一遍业务代码，浪费了大量时间和人力。而且因为所有的应用都是从一次性 开发的角度实施的，应用的每一个更改都需要由特定的程序员来完成，于是很难 北京交通大学硕士学位论文 被再次定制和扩展。这样，当需要融入新的业务流程，为额外的用户群提供访问 界面，继承不同的业务应用以为用户提供更完整的服务时，都不得不从最初的系 统设计开始做起。 面向对象设计的基本操纵单位为对象，对象间通过消息传递机制实现功能调 用。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用的机 制，但是这样的对象的粒度级别太低，没有适当的标准可以用来使重用广泛应用 于实践之中。另外，语言的单一性和源代码级的共享决定了其在跨系统重用的过 程中必定会有各种各样的困难。 面向组件中二进制级别的组件共享继承了面向对象的显著的优点，使得r r 基 础架构能够更加快速适应业务变化。但是组件粒度通常过小，往往是用某单一技 术来实现一个技术功能，如j a v a s c r i p t 实现的日历，不但组装成本高，而且一个组 件的改动对另一组件的影响很大。此外，平台单一性依然阻碍了其复用程度。 面向集成的所有的应用都是以业务应用为主题组织的，但是集成高昂的成本 让许多企业望而却步。一方面集成的效率比较低【3 1 ，需要非常高水平的专家来实施， 另一方面也需要专门的集成工具或者适配器等来实现。 1 1 3s o a 的出现 为了减少异构性、互操作性和不断改变的需求的问题，减少成本和增加重用， 需要一种体系结构能提供平台来构建具有下列特征的应用程序： 1 、松散耦合 2 、位置透明 3 、协议独立 于是业界提出面向服务的体系结构( 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 ，s o a ) ，s o a 支持将业务作为服务即可重复业务任务进行集成，可在需要时通过网络访问这些 服务和任务。这个网络可能完全包含在企业内部，也可能分散于各地且采用不同 的技术，通过对来自不同地点的服务进行组合，可让最终用户感觉这些服务似乎 就安装在本地桌面上一样。服务的底层实现可能各不相同，但是都能以统一的方 式进行访问，需要时可以将这些服务彼此结合，组装为按需应用程序，以完成特 定业务任务，使业务能够适应不断变化的情况和需求。 从技术角度而言，s o a 带来了“松散耦合”的应用程序组件，在此类组件中， 代码不一定绑定到特定的基础设施。这使得这些组件即服务能够组合为各种应用 程序，大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务 和访问服务的使用者并未彼此绑定，因此需要时可以完全替换服务，而使用者将 2 引言 永远不会知道这个更改。从业务的角度来说，s o a 的重点在于开发能帮助完成业 务任务的技术，而不是通过技术约束来规定企业行动1 4 j 。 诸如跨平台开发集成，急需加快r r 系统对业务需求的响应速度，快速且低成 本地完成r r 系统建设等企业经常遇到的难题，在s o a 面前将迎刃而解。 可以预见，几年以后，s o a 将成为占有绝对优势的软件工程实践方法。综上 所述，跟踪、研究和掌握s o a 这一新的知识体系并生成一个较为实用的s o a 模 型，对帮助指导国内企业建立新的r r 系统无疑是意义深远的。 1 2研究现状 1 9 9 6 年，国际权威n 研究与顾问咨询公司g a r t n e r 首次提出s o a 的思想，2 0 0 2 年，g a r t n e r 提出s o a 是“现代应用开发领域最重要的课题 ，g a r t n e r 为s o a 描 述的远景目标是：在于让r r 变得更有弹性，以更快地响应业务单位的需求，实现 实时企业( r e a l t i m ee n t e r p r i s e ) 。 2 0 0 5 年，i b m 开始建立并实施s o a 应用软件，s o a 开始成为m i c r o s o f t 、i b m 、 s u n 、b e a 、s a p 等等1 1 r 界巨头关注的焦点，各厂商纷纷推出自己的s o a 解决方 案。而随着x m l w e bs e r v i c e s 技术的成熟，也给s o a 奠定了坚实的基础【5 1 。 不过从现有情况看，开展s o a 还有很多难点： 1 、标准仍不完备。w e b 服务是实现s o a 最好的方式，但w e b 服务本身还有 很多不成熟的方面。除了s o a p ( s i m p l eo b j e c ta c c e s sp r o t o c o l ，简单对象访问协 议) 和w s d l ( w e bs e r v i c e sd e s c r i p t i o nl a n g u a g e ，w e b 服务描述语言) 相对成熟 外，在可靠消息传递、安全w e b 服务、w e b 事务处理等方面的标准还有待完善， 无论u d d i ( u n i v e r s a ld e s c r i p t i o n ，d i s c o v e r ya n di n t e g r a t i o n ) 、e b x m l ( e l e c t r o n i c b u s i n e s su s i n ge x t e n s i b l em a r k u pl a n g u a g e ) 还是u b l ( 通用商业语言) 等在定 义业务方面都还需要走很长的路。软件作为一种社会科学，在设定标准方面，要 比硬件难得多。 2 、服务大小的问题，也就是所谓服务粒度( s e r v i c eg r a n u l a r i t y ) 粗细的问题， 是目前需要不断尝试的工作。就s o a 架构来说，服务粒度大小问题，在某种程度 上决定着整个系统的灵活性和效率，要在灵活和效率之间找到一个平衡点。而平 衡点需由实践来检验。 3 、服务是会变的。仅仅有一个组件化的概念是不够的，还需要自动能够解决 服务的来源问题，即不仅是如何快速组装，而且解决如何最快速度地生成这个服务 或调整这个服务。这是一个系统工程，不是一个点能解决所有的问题。 除此之外，如何建立可靠的服务，加快服务的响应速度，提高服务的安全性等， 3 北京交通大学硕士学位论文 都是对s o a 所提出的挑战。 总体来说，国内业界对s o a 还是缺乏研究，没有理解其深层次的含义。由于 它的实用性已经展现出来，加上i b m 、m i c r o s o f t 等大公司都在大力推动，会有更 多人来关注s o a 。 1 3研究内容 本文的主要工作是在研究s o a 的基础上，设计了一个基于s o a 的应用系统， 并使用w e bs e r v i c e 实现了该系统，解决目前应用系统开发所面临的异构和改变的 困境。本文的研究内容可以总结为以下几部分： 1 、深入研究和分析s o a 的理论、面向服务的设计思想，着重讨论面向服务应 用的整体和服务设计原则。 2 、提出系统的综合缓存方案，并设计实现依赖于数据库的缓存刷新机制，优 化服务的响应速度。 3 、提供系统的可靠底层服务，设计实现由配置文件控制记录方式的插件式的 日志记录，提升服务的灵活性和易改变性。 4 、分析和抽取业务服务，给出由业务所驱动的多库的数据库设计方案；设计 实现应用的系统管理部分，以此为例描述应用的面向服务设计思想和方法。 1 4 论文的章节安排 本文包括五章： 第一章：简要介绍了目前应用系统的开发中面临的两个基本的问题，以及传统 软件体系结构在解决问题时的局限性，阐述了s o a 的研究现状及意义。 第二章：介绍了s o a 的相关理论，包括s o a 中的服务，s o a 的特征，应用 层次设计，组成和协作，s o a 与w e b 服务的关系，总结了s o a 的优点，详细讨 论了面向服务的设计原则。 第三章：设计了基于s o a 的应用系统，给出了系统的总体设计，服务设计， 以及缓存、日志、系统管理子系统的详细设计方案。 第四章：根据第三章的设计方案和设计思想，给出了系统的实现过程，主要包 括多库的数据库方案、缓存、日志、系统管理中的用户服务的实现。 第五章：总结本文的研究工作，提出需要改进的地方。 4 s o a 相关理论 2s o a 相关理论 2 1 理论概要 随着企业计算的发展，企业级应用需求要求新的软件系统不再是从底层做起。 而只是依据企业逻辑需求重新组织已有的数据存储，将现有的数据和事务通过新 的渠道，比如i n t e r a c t 浏览器或者手持设备呈现给用户。另外，为了提高企业计算 的高效性、可用性、规模性，现有许多的企业应用系统都是分布式系统，运行在 许多机器之上。这样的企业级解决方案就必须具有协调运行在群组硬件之上的功 能。 实现这种系统的一种方法就是将该系统组织成为群组服务的模式，每一个服 务都提供一组定义良好的功能集合。整个系统其实就被设计和实现为一组相互交 互的服务，而将功能以服务的形式展现出来是该系统灵活性的关键。它使得系统 中的某些服务能够充分利用其他的服务而无需考虑其物理位置。系统通过添加新 的服务来不断的升级，这样s o a 就应运而生了。 s o a 是一个组件模型，它将应用程序的不同功能单元( 称为服务) 通过这些 服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的， 它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中 的服务可以以一种统一和通用的方式进行交互。 基于这样的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为 底层基础设施或服务“总线将代表使用者做出适当的选择。基础设施对请求者 隐藏了尽可能多的技术。 s o a 中，中立的接口定义( 没有强制绑定到特定的实现上) 的特征称为服务 之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是组成整 个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。 而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧 密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显 得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵 活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作 伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性 质。能够灵活地适应环境变化的业务被称为按需( o nd e m a n d ) 业务，在按需业务 中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。 5 北京交通大学硕士学位论文 2 1 1s o a 中的月艮务 s o a 中关键的概念之一就是“服务”。服务是对现实世界中业务活动的一种 抽象与建模。在万维网联盟w 3 c 中给出的服务定义是：服务提供者完成一组工作， 为服务使用者交付所需的最终结果。最终结果通常是使用者的状态发生变化，但 也可能是提供者的状态发生变化，或者两者都发生变化。 可以先从业务的观点来看一下服务的概念，大多数商业或政府机构都要为顾 客、合作伙伴等提供服务，例如银行出纳员要为银行的客户提供服务，包括：账 户管理，贷款，存款与转账，外币兑换等。银行中存在多个提供一组相同服务的 出纳员，这有利于分摊工作量和提供较高的可用率。不过就用户而言，他们只关 心能否完成服务，至于银行内部如何安排则与他无关。如果是一个复杂的交易， 客户可能需要与多个出纳员接触才能完成处理，这就是一个业务流程流，即多个 服务的有序组合。s o a 将业务服务作为协调1 1 r 系统与业务需求的关键组织原则， 它认为如果能确保“r r 系统所实现服务的定义一与“业务功能和业务流程一致， 那么r r 系统将更易于支持业务目标1 6 l 。 在s o a 中，服务是封装成用于业务流程的可重用组件。它提供信息或简化业 务数据从一个有效的、一致的状态向另一个状态的转变。用于实现特定服务的流 程并不重要，只要它响应服务请求者的命令并为服务请求者提供高质量的服务就 可p a y t n 。 通过定义的通信协议，可以调用服务来强调互操作性和位置透明性。一个服 务表现为一个软件组件，因为从服务请求者的角度来看，它看起来就像是一个自 包含的函数。然而，实际上服务的实现可能包括在一个企业内部的不同计算机上 或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服 务可能是一个组件，也可能不是一个组件。如同类对象，请求者应用程序能够将 服务看作是一个整体【8 l 。 服务具有两个部分，接口部分和实现部分。接口部分定义了服务使用者和服 务提供者间进行程序访问的契约。接口必须包含服务的m 、服务详尽的输入输出 数据以及数据在服务中的作用和目的等信息。实现部分包含了服务的作用或商业 逻辑等信息【9 】。实现部分对于服务的使用者是在“暗箱”中进行的，使用者也没有 必要知道服务实现的具体做法。 服务分为五种类型： l 、数据访问服务 数据访问服务允许用户访问、集成、翻译以及转换整个企业的各种关系型和 非关系型的数据资源。这些服务通常隐藏了对资源的直接访问，隐藏了基本格式 6 s o a 相关理论 的复杂性，也隐藏了数据的直接转换和操纵。它们提供了一个统一的a p i 、松散耦 合、一个公共的数据模型以及整个应用程序中一致信息的重用。数据访问服务是 s o a 架构中最常见的，使用最广泛的，同时也是最容易实现的服务，数据层和应 用层的分离通常是很直接的。随着数据资源的广泛访问和共享，它们已成为服务 实现的首要目标。x m l 广泛应用于应用程序间的数据交换。一个可以对任何数据 源进行抽象的、统一的数据访问的基础架构对于s o a 实现是很有价值的。x m l 数据服务( ) s ) 提供了对多种数据资源的访问、数据建模功能，物理数据向逻 辑数据的翻译和转换以及对逻辑数据的基于x m l 的访问。 2 、组件服务 提供访问打包应用的服务。组件服务是粗粒度服务，无论这些服务是否是打 包应用程序( 例如，企业资源规划 e r p 、客户关系管理 c r m 或者供应链管理 s c m ) ，它们都可以从一个单一的企业资源来发布。组件服务的一个示例可能是 “向e r p 中添加客户 。这些服务被认为有足够的价值，所以可以直接发布。组 件服务实现的方法是用各个应用程序a p i 来提供可重用的功能的。这些服务可以 用分布式计算技术( 例如j 2 e ee j b 、c o m d c o m 以及c o r b a ) 来实现。 3 、业务组件 提供多项功能的打包或定制应用的复杂服务。业务服务的功能( 由业务应用 程序提供) 执行一个或者多个业务操作。业务服务通常是由多个应用程序的多个 业务事务处理构成。它们可以是端到端的业务流程。 4 、复合服务 集上面的三种类型创建的一个新的服务，这个服务包括新的和已经存在的功 能。组合式应用程序是通过将新的逻辑与事务处理进行合并创建而成的，现有的 应用程序将这些事务处理作为业务或者组件服务提供出来。应用集成技术和业务 流程管理工具在创建复合服务中扮演着关键的角色。 5 、共享或企业基础结构服务 底层服务，比如消息日志等，能重用并快速创建新的高层服务。s o a 所提供 的最大价值在于它能够通过重用现有的服务快速一致地合成应用程序。这些可以 称为共享服务、公共服务或者企业基础架构服务。 如图2 - 1 ，与传统的体系结构相比，s o a 引入了“服务”的抽象层，表现层并 不是直接操作业务对象，而是通过“服务 去访问它们。服务层中的服务是粗粒 度的，增加了重用的可能性；是开放的，基于标准的，可以更容易地与几乎任何 现有环境集成，而不必处理由不兼容的应用引入的复杂性。 7 北京交通大学硕士学位论文 l ，7 粤：捆 数 据 访 问 一服务卜 图倒 层 li ， if 1 服务卜 i 图2 - 1s o a 的服务抽象层 从业务的角度来看，服务是对应于真实的业务活动或可识别的业务功能的盯 资产。从技术角度来看，服务是粗粒度的，可重用的r r 资产，良好的接口定义令 服务的外部访问接口与内部技术实现相分离。用服务来设计、开发和部署应用， 需要思维方式上的重大转变。n 部门的职责将划分为两个部分： 创建服务，处理部署服务所涉及的下层技术的复杂性，并确保服务的描述与 服务消费者的需要相一致，而且双方共享着应有的数据。 使用服务，组装新的合成应用与业务流程流，确保共享数据及流程能够准备 反映业务的运营和战略需求。 上述职责的划分实现了技术问题与业务问题的明确分离。在目前的1 1 r 项目中， 最困难的问题之一是确定谁能衔接起业务与技术之间的鸿沟，也就是说，哪位项 目成员将有相当的能力来确保业务问题可被很好的理解并以技术来实现，且确保 技术问题可被很好的理解以满足业务需求。用s o a 来构建解决方案有助予解决这 一始终存在的难题，因为其很好的分离了业务分析师与服务开发者的关注点，服 务开发者可以负责实现满足业务需求的服务，而业务分析师可以负责定义如何将 服务组合起来以实现业务流程。 2 1 2s o a 的特征 s o a 是一种粗粒度、松耦合的软件架构，其服务之间通过简单、精确定义接 口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征： 1 、松散耦合 服务间的松耦合是指具有中立的接口定义，没有强制绑定到特定的实现上的 服务特征。简单的说，就是服务提供者和服务使用者可以用定义良好的接口来独 8 s o a 相关理论 立开发，服务接口作为与服务实现分离的实体而存在。服务提供者可以更改服务 的数据或者消息版本，而不会对服务使用者造成任何影响，从而将服务使用者和 服务提供者在服务实现和服务使用方面分离开来【。服务请求者到服务提供者的 绑定与服务之间的松耦合关系意味着，服务请求者可以不知道提供者实现的技术 细节，比如程序设计语言、部署平台等。服务请求者往往通过请求消息和响应调 用操作，而不是通过使用a p i 和文件格式。这个松耦合使会话一端的软件可以在 不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况 下，服务提供者可以将以前基于遗留代码( 例如c o b o l ) 的实现完全用基于j a v a 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的， 只要新代码支持相同的消息模式。 松耦合的优点是：灵活，组成整个应用程序的一个服务的内部结构和实现发 生变化不影响其继续存在。但是一般来说，松耦合方式的缺点是松耦合方式效率 不如紧耦合【1 1 1 。松耦合是s o a 中的关键概念之一，也是s o a 的一个显著特点。 2 、粗粒度服务 服务粒度指的是服务所公开功能的范围，包括细粒度( f i n e g r a i n e ds e r v i c e ) 和 粗粒度( c o a r s e g r a i n e ds e r v i c e ) 。 其中，细粒度服务是那些能够提供少量商业流程可用性的服务，例如基本的 数据访问服务等。细粒度服务实现最小的功能，同时消耗并返回最小量的数据。 细粒度服务可以用w e b 服务来实现，也可以利用基于r m i ( r e m o t em e t h o d i n v o c a t i o n ，远程方法调用) 、d o t n e t 或者c o r b a 的分布式对象来实现。细粒度服 务的优点是可在粒度一级来实施严格的安全和访问策略。实现和单元测试都很简 单，而且相互独立，细粒度的接口主要用于企业内部。 粗粒度服务是那些能够提供高层商业逻辑的可用性服务。粗粒度服务可以灵 活组合稳定性强、重用性高的细粒度服务，而快速形成新的业务逻辑。粗粒度服 务比细粒度服务实现更多的功能，并消耗不同数量的结构化数据或者消息。它们 返回类似的数据或者消息，可能还含有内嵌的上下文。粗粒度服务不需要通过网 络多次调用来提供有意义的业务功能1 1 2 。 虽然细粒度的接口为请求者应用程序提供了更多的灵活性，但它同样也意味 着交互的模式可能随着不同的服务请求者而不同，这可能使对于服务提供者的支 持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。s o a 不要求 使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用 来创建运行由细粒度操作组成的业务流程的粗粒度接口【1 3 j 。 3 、标准化的接口 服务描述的重点在于与几部分交互所用的操作：服务、调用操作的消息、构造 9 北京交通大学硕士学位论文 这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息的信息。 s o a 通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和 任何用户接口使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的 硬件或软件平台和编写服务所用的编程语言使用服务。 4 、无状态服务 服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请 求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时， 它们最好定义成通用业务流程、函数和数据模型，而不是实现构件( 比如会话密 钥) 。如果请求者应用程序需要服务调用之间的持久状态，需要将状态管理移至别 处，与服务提供者分开。 2 1 3应用层次设计 面向对象技术和语言是实现组件的伟大杠杆，在架构s o a 系统的时候，虽然 一个面向组件的设计并不能完全演化为一个合乎要求的面向服务的设计，但组件 是实现服务的有效途径。 对于一个s o a 系统，可将其应用实现层划分为三层：l 、服务在最上层，是 最粗粒度的实现，它作为应用系统的外部视图；而内部的重用和组合仍然使用传 统的组件设计。2 、组件层。3 、类对象层。 fl彳 7 l _ j 服务层 口 富 组件层 ， 类对象层 l 图2 - 2 应用程序实现层：服务、组件、对象 在构建一个具体的s o a 系统的时候，首先给出系统的逻辑模型，这个逻辑模 型用类对象图来进行建模；然后依据具体的需求给出相应的组件模型，组件的 设计主要在于设计其功能接口；最后就是服务模型，为了使设计更加合理，要使 用具体的组件平台或相关的设计模式。 1 0 s o a 相关理论 2 1 4组成元素 s o a 提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功 能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素 和服务质量元素。 图2 3s o a 的组成元素 如图2 - 3 所示，s o a 的体系结构堆栈分成两半，左边的一半集中于体系结构 的功能性方面，而右边的一半集中于体系结构的服务质量方面。这些元素详细描 述如下。 1 、功能性方面包括： ( 1 ) 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者， 并且将来自服务提供者的响应传送给服务使用者。 ( 2 ) 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服 务使用者可以就将要请求的内容和将要返回的内容进行沟通。 ( 3 ) 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用 服务以及成功地调用服务需要什么数据。 ( 4 ) 服务描述实际可供使用的服务。 ( 5 ) 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规 则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就 产生了业务流程可以由不同粒度的服务组成的观念。 ( 6 ) 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服 务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可 北京交通大学硕士学位论文 用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。 2 、服务质量方面包括： ( 1 ) 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服 务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我 们在功能和服务质量两个区中都有策略功能。 ( 2 ) 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权 和访问控制。 ( 3 ) 传输是属性集，可以应用于一组服务，以提供致的结果。例如，如果 要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个 完成。 ( 4 ) 管理是属性集，可以应用于管理提供的服务或使用的服务。 2 1 5s o a 中的协作 为了更清楚地勾画出对s o a 的描述，必须对s o a 中的角色、操作、生命周 期和应用作一个理解和描述。s o a 中的协作遵循“查找、绑定和调用一范例，其 中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹 配的服务。如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。 图2 4 展示了s o a 中协作支持“查找、绑定和调用范例的实体【1 4 1 。 绑定和调用 图2 - 4s o a 中的协作 l 、s o a 中的角色包括： ( 1 ) 服务使用者。服务使用者是一个应用程序、一个软件模块或需要一个服 s o a 相关理论 务的另一个服务，它发起对注册中心中的服务的查询，通过传输绑定服务，并且 执行服务功能。服务使用者根据接口契约来执行服务。 ( 2 ) 服务提供者。服务提供者是一个可通过网络寻址的实体，它接受和执行 来自使用者的请求，它将自己的服务和接口契约发布到服务注册中心，以便服务 使用者可以发现和访问该服务。 ( 3 ) 服务注册中心。服务注册中心是服务发现的支持者，它包含一个可用服 务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。 s o a 中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的 某一种( 或多种) 。 2 、s o a 中的操作包括： ( 1 ) 发布。为了使服务可访问，需要发布服务描述以使服务使用者可以发现 和调用它。 ( 2 ) 发现。服务请求者定位服务，方法是查询服务注册中心来找到满足其标 准的服务。 ( 3 ) 绑定和调用。在检索服务描述之后，服务使用者继续根据服务描述中的 信息来调用服务。 3 、s o a 的生命周期 s o a 中的每一个服务的生命周期，对于三个角色主体即服务提供者、服务请 求者、服务注册者来讲都涉及到了设计实现、部署和运行、管理四个阶段。而这 四个阶段对于每个角色主体来说任务和需求都是不同的。 ( 1 ) 设计实现( d e s i g na n di m p l e m e n t a t i o n ) 在设计实现的阶段包括服务实现、服务的接口描述文件制定、服务接口定义 的开发和测试。服务的实现可以通过以下的集中方式进行： 开发新的服务； 将现有的应用转化为服务； 将其他的服务和应用组合为新的服务。 ( 2 ) 部署( d e p l o y ) 服务的部署包括两个方面： 服务描述信息的发布，把服务对应的描述文件发布给服务的请求者或者是 服务的注册表； 将服务的可执行体部署到一个可执行的环境中，通常情况下该可执行环境 就是一个应用服务器。 ( 3 ) 运行( r u n ) 运行阶段可以调用服务。在该阶段，服务已经部署完毕，可以通过传输媒介 1 3 北京交通大学硕士学位论文 来调用，服务请求者可以执行查找和绑定操作。 ( 4 ) 管理( m a n a g e ) 管理阶段涵盖了服务的各个方面，安全性、可用性、性能、服务质量( o o s ) 以及企业流程，这些都是管理阶段所必须考虑的问题。 2 1 6s o a 的优点 采用s o a 将带来几方面的好处，有助于企业在今天的商业环境中取得成功： l 、利用现有的资产 s o a 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在r r 方面 的投资，方法是将这些现有的资产包装成为提供企业功能的服务。组织可以继续 从现有的资源中获取价值，而不必重新从头开始构建。 2 、更易于集成和管理复杂性 在s o a 中，集成点是规范而不是实现。这