（计算机应用技术专业论文）soa的研究与实现.pdf

摘要 本文分析了一种面向服务的架构( s o a ) 模型，该模型可以根据需求通过网络对松散 耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是s o a 的基础，可以直 接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。这种模型通过将 原有系统的应用和资源转变为可共享的标准服务，打破了”信息孤岛”，实现了对原有 系统的复用、组装和集成。构建这种模型的目标就是为企业构建一个灵活，可扩展的 r r 基础架构，以便更好地支持随需应变的企业业务。 本文以某网上书店系统的改进为例，该系统表示层采用a j a x 技术，应用层使用 无状态会话e j b 作为w e b 服务的实现组件，w e bs e r v i c e 作为服务的提供者，同时使用 企业服务总线对服务进行统一管理。通过对服务进行粗粒度的划分以及服务总线的使 用，实现系统的松祸合和服务的透明化，完成对原系统的整合应用。 关键字：面向服务架构w e b 服务e j b企业服务总线a j a x a b s t r a c t t h i sa r t i c l eh a sa n a l y z e do n ek i n do fs 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 ) m o d e l t h i s m o d e lm a y c a r r yo nt h ed i s t r i b u t i o n a ld e p l o y m e n t , t h ec o m b i n a t i o na n dt h eu s ea c c o r d i n gt o t h ed e m a n dt h r o u g ht h en e t w o r kt ot h el o o s ec o u p l i n gu s i n gt h em o d u l e t h es e r v i c el e v e li s t h es o a f o u n d a t i o n ，m a yd i r e c t l ya p p l yt r a n s f e r s ，t h u si na c t i v ec o n t r o ls y s t e ma n ds o f t w a r e p r o x yi n t e r a c t i v ea r t i f i c i a ld e p e n d e n c e t h i sk i n do fm o d e lt h r o u g ht r a n s f o r m e dt h eo r i g i n a l s y s t e ma p p l i c a t i o na n dt h er e s o u r c e sf o rt h es t a n d a r dw h i c hm i g h ts h a r es e r v o s ，h a sb r o k e n ”t h ei n f o r m a t i o ni s o l a t e d i s l a n d ”，r e a l i z e dd u p l i c a t eh a su s e d ，t h ea s s e m b l ya n dt h e i n t e g r a t i o nt ot h eo r i g i n a ls y s t e m c o n s t r u c t st h i sk i n do fm o d e lt h eg o a li sc o n s t r u c t sn i m b l e f o rt h ee n t e r p r i s e ，e x p a n d a b l ei tf o u n d a t i o no v e r h e a dc o n s t r u c t i o n ，i no r d e rt os u p p o r t sw e l l a l o n gw i t hn e e d st h es t r a i nt h ee n t e r p r s es e r v i c e t h i sa r t i c l et a k es o m eo n - l i n eb o o k s t o r es y s t e mi m p r o v e m e n ta sa ne x a m p l e ，t h e p r e s e n t a t i o nl a y e ru s e st h ea j a xt e c h n o l o g y ，s t a t e l e s ss e s s i o ne j ba p p l y i n gat i e rb e i n gp u t i n t ou s et h e r eb e i n gn os t a t ei st h er e a l i z a t i o nt h a tw e bs e r v e sm o d u l e ，w e bs e r v i c ei st h e p r o v i d e rw h os e r v e s ，u s e se n t e r p r i s et os e r v eah i g h w a ys e r v i n gt h eu n i f i e da d m i n i s t r a t i o n b e i n gi np r o g r e s sf a c et of a c ea tt h es a m et i m e b ys e r v i n gt h es i g m a t i s mc a r r y i n go u tr u d e s i z ep a r t i t i o na n ds e r v i n gah i g h w a yf a c et of a c e ，r e a l i z et h es y s t e m a t i cp i n ec o u p l i n ga n d s e r v et r a n s p a r e n t - r i z a t i o n ，i n t e g r a t i n gb e i n gc o m p l e t e dt op l a i ns y s t e ma p p l i e s k e yw o r d s ： s o kw e bs e r vi c ee j be s ba j a x 长春理工大学硕士学位论文原创性声明 本人郑重声明；所呈交的硕士学位论文，( s o a 的研究与实现是本人在指导教师 的指导下，独立进行研究工作所取得的成果。除文中已经注明引用的内容外，本论文 不包含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究做出重要贡 献的个人和集体，均己在文中以明确方式标明。本人完全意识到本声明的法律结果由 本人承担。 作者签名：啦 一1 叠型年坐月冱日 长春理工大学学位论文版权使用授权书 本学位论文作者及指导教师完全了解“长春理工大学硕士、博士学位论文版权使 用规定”，同意长春理工大学保留并向国家有关部门或机构送交学位论文的复印件和电 子版，允许论文被查阅和借阅。本人授权长春理工大学可以将本学位论文的全部或部 分内容编入有关数据库进行检索，也可采用影印、缩印或扫描等复铝4 手段保存和汇编 学位论文。 作者签名： 指导导师签名：确童幺 出z 年监月堑日 ， 丑年旦月堑日 1 1 研究目的和意义 第一章绪论 在现今商业活动中，正面临的一项挑战是如何使用更少的投入来获得更多的回报。 各个公司在无情的压力之下不得不以更快的速度向市场派送产品及服务，并且要求产 品服务质量更好，价格却更低廉，这种要求达到了前所未有的程度。企业期望通过在 i t 技术上的投资驱动业务向前发展，并期望不仅仅是提高效率和响应速度，还希望能 够以此创造更多更新的商机。 但事实上是，很多企业的i t 部门每年占用了近百分之七十五到百分之八十的预算， 却没有达到企业对于i t 技术的期望。与此同时，研究表明，对于一台普通的服务器来 说，平均的使用率只有百分之十五至百分之二十五。尽管这个数字不能反映出每个企 业的情况，但也足以警示大家，在现在的i t 企业存在着极大的效率低下现象，这样的 状况会导致消耗本来可以用于更多企业主动战略的资金和成本，造成不必要的浪费i l l 。 导致这样的效率低下原因很复杂，多数情况下是因为企业的吞并、获得、或功能 的冲突导致了一个松散臃肿的i t 组织构架，充斥着许多重复和交叉的应用程序或系统。 在面临着业务需求、项目上交时限等一系列问题的情况下，i t 部门通常不会对这种冗 余臃肿的结构进行调整，他们会把所有需要的系统都整合在一起，以应付业务需要。 尽管这么做的确能够满足需求，但是却会极大程度的增加重复性投资，使成本增加。 尽管还有一些i t 部门仍满足于现在这种状况，但还是有相当部分的人们注意到了 “i t 技术和业务结合”的重要性，并把它作为和i t 相关的首要工作来进行。但是，对 于i t 部门来说，企业提供的更改业务需求所用的仅百分之十五的预算并不足以操控i t 部门的改变。这样的问题非常普遍，两且凡乎每个行业领域都会存在这样的问题，很 明显，我们需要另外一种更基础和底层的变更方法。 在这种情况下，该需求的出现引领企业走向了一种面向服务的构架体系( s o a ) 。该 体系提供了一种构建i t 组织的标准和方法，并通过建立起合并、可重用的服务体系( 通 常指代的就是w e bs e r v i c e s ) 来减少i t 业务冗余并加快项目开发的进程。s o a 允许一 个企业高效地平衡现有的资源和财产，而不是因为业务需要，就将这些财力投入到另 一项多余的重复功能中。换个角度来说，这种体系能够使得i t 部门效率更高、开发周 期更短、项目分发更快，在帮助i t 技术和业务整合方面有着深远的意义。 1 2 国内外研究现状 近年来，面向服务体系结构( s o a ) 成为全球计算机软件行业的热点话题，被誉为软 件开发的下一个里程碑，成为企业软件架构的趋势。企业用户业务需求的不断变化， 要求企业i t 系统必须成为一个适应力强的竞争体，能随着企业环境的变化而改变，并 具备柔性扩展、随时支持业务流程变化的基础功能。 s o a 的重要特点包括松耦合、可灵活支持业务流程重构、广泛应用标准等，这使得 s o a 更适用于业务系统间的互操作和整合。s o a 适用的主要应用场景包括企业应用集成 ( e a i ) 、电子商务( b 2 b ) 、电子政务( 各部门间信息共享和协同工作) 等。s o a 架构可以帮 助客户更快地开发和实旌下一代应用，更好地解决针对各个单一业务应用所建设的各 自独立系统间资源无法共享、信息割裂等问题“1 。 s o a 架构独立于实现服务的硬件平台、操作系统和编程语言，构建在不同系统中的 服务可以用统一、通用的方式进行交互。因此实现s o a 需要一个平台来在各种不同服 务间进行协调、管理。能否使企业的i t 架构更为灵活，从容的应对市场环境的不断变 化：使企业现有的i t 系统之间充分整合，达到各个业务部门和环节更好的协同：使企业 i t 系统的复用性提高，有效降低i t 成本，都是衡量s o a 平台是否满足中国企业需求的 重要参考标准。 根据信息周刊和埃森哲公司对国内上千家企业机构的问卷调查，拥有$ o a 应 用的企业比例为8 8 ，在大中型企业中，比例可达到1 0 。四分之三的被调查企业未 对s o a 采取任何行动。而在早期己开始s o a 部署的企业中，6 0 的大中型企业和超过一 半的小型企业都表示，将增加在s o a 上的投入。数据表明：尽管s o a 在中国尚处于应 用启蒙阶段，但企业在s o a 上的投入却在快速增加。可以预计未来卜2 年，s o a 在中国 将进入快速发展期。 目前，在国内的很多行业，例如政府、电信、金融、医疗等等，都需要实施s o a “1 。 政府的电子政务建设需要围绕政府的具体职能，利用信息化的手段，达到业务标 准和业务资源的统一，实现数据自底向上的快速准确汇集和业务自上而下的高度协同。 中国的电子政务建设目前还处于起步阶段，政府传统的应用是条块的，不能完全满足 现实的需求，政府需要建设政府服务资源目录。在政府服务资源目录里，提供了政府 提供的服务的位置以及调用方法。尽管社会变化在加速，政府职能也在不断转变，但 政府所提供的业务点是固定不变的，通过实施s o a ，就可以对政府业务流程进行重组， 实现资源服务的整合，提高工作效率，以适应不断变化的需求。 电信运营业也是s o a 应用的重要领域之一。通过对电信运营商的信息系统进行s o a 架构的改造，应对电信运营业走向综合的信息化服务的挑战，是电信产业与i t 产业不 断实现融合的一个重要发展方向。电信运营商现有的i t 和网络基础设施往往是封闭和 专有的，各个系统间的运作缺乏统一和协调。这样的状况不仅会导致运营商在系统建 设方面不断重复建设所造成的投资浪费，由于各个系统间缺乏关联性，无法对消费用 户进行准确的分析，并制定相应的销售策略。服务整合几乎是每一个电信运营商无法 逾越的过程。如何将这些新l 且i t 系统进行有效整合，以实现数据的共享和集中对于运 营商而言格外重要。目前运营商在统一规划、统一框架、统一标准等原则下，通过s o a 平台对这些功能进行连接。在电信服务走向融合应用的过程中，能否更快速、更低成 2 本地将不同服务系统进行有效的捆绑、开通及管理便成为了提升竞争力的关键之一， s o a 架构正是提供这一能力的基础。 在金融行业中，金融企业的业务流程需要不断地自动化、优化，在企业范围内甚 至整个价值网络上进行流程的整合，将生产效率的提升从个人、部门，推动到整个企 业范围内，以及整个价值网络上。企业所面对业务流程的变化速度正在急剧提升，需 要在最短时问内推出一个全新的金融产品或服务，提高响应速度需要一个非常灵活、 快速应变、全面整合的i t 系统。目前，大多数金融企业的i t 投入，大约7 0 9 6 花在了已 有系统的运维和修补上，i t 的投资回报率较低。在银行业，调查统计表明，银行核心 系统占整个i t 投入的5 0 2 ，这种状况使得i t 面临窘境，无法使用有限的i t 投入来 满足业务持续不断的创新和变化。而且，金融企业所拥有的i t 系统孤岛很多，要在应 用、数据、流程、访问渠道、安全等层次上全面整合，以及在应用整合、流程端到端 的整合方面仍然任重道远。此外，金融企业i t 资产重用不够理想。主机上的核心系统 的数据和处理能力如何开放给其他非主机安全高效使用，如何以统一的方式来定义、 描述、使用和管理主机上和开放系统上的i t 资产，并且重复地使用这些资产都是需要 进行研究的问题。而采用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 架构的软件产品，其中包括i b m 的w e b s p h e r e l e s s a g e b r o k e r 、b e a 的a q u a l o g i c ， t i b c o 的a c i t v e m a t r i x ，i o n a 的a r t i x 等等，都为客户提供在异构计算环境中开发、 部署、管理和运行完整的s o a 的开放和独立的平台。 然而在国内实施s o a 与在国外实施s o a 存在一定的差异“1 。中国i t 应用成熟的企 业已经建设了大量的生产型系统，目前正在尝试着整合；而更多的企业正在进行系统 新建或改造优化，大量的服务性系统仍有待新建。对已有系统的改造优化主要是系统 升级、新建功能模块或新开发周边系统并集成到已有系统。在金融、电信等行业，已 经建设了近9 0 的生产性系统，但仍然缺乏大量的服务性系统。而外国的重量级产品大 都庞大而繁杂、实用性和解决客户需求能力差。引进国外产品的价格高昂，企业实际 都应用不到3 0 的功能，这对于国内各行业来说是一种极大的浪费。因此，外国的s o a 软件平台并不一定可以完全适应中国市场的需求。 长期以来，国内平台软件基本上走的是一条亦步亦趋的跟随型发展路线，这一发 展路线使我们在与国外软件的竞争中处于比较被动的局面，缺乏战略上的竞争优势。 而s o a 概念刚刚起步不久，从技术层面看，中国s o a 中间件企业与国际先进的s o a 中 间件企业之间不存在太多差距，相反，国内软件生产商更贴近客户的实际情况，有更 好的服务支持；有长期以来在应用软件方面的大量积累，更有更多的政策的支持。国 内厂商自主研发的s o a 平台产品完全可以把国内软件的竞争优势体现出来，有能力打 造自己的产品与企业品牌影响力，扩大产品的市场份额，借助s o a 理念实现自我的发 展和跨越。 w e b 2 0 、b p m 、s o a 等技术趋势将演变成为新的i t 服务形式，技术专家在i d c 举办 的s o a 专题讨论活动上发表了如下的观点“1 。 b e a 系统中国有限公司企业解决方案经理刘松指出，到2 0 0 8 年，s o a 将结束整体 化软件架构长达4 0 年的统治地位，成为主流的软件工程实践方法，对于i t 人员而言， 现在不是要考虑s 0 a 将带来什么影响，而是什么时候，怎样积极地去拥抱s o a 满足未 来需要，而不是守株待兔。s o a 的切入点包括：利用s o a 建立企业治理平台，利用s o a 提升监管力度，利用s o a 构建跨企业应用，客户服务响应提升，信息基础设施提升， 以及无处不在的新应用提供的机会。 针对目前部署s o a 的两种不同策略：自上向下和自下向上，b e a 大中国区首席s o a 顾问劳虎认为，两种策略各有优缺点。自上向下的部署策略优点在于面向业务，标准 化、可衡量、质量高、重用机会高、弹性大，缺点在于长期性、开始投资较大、要求 更高的企业治理水平等；而自下向上的s o a 策略可以在部门级别实施，成效快，容易 控制风险，缺点则在于弹性差、标准化无法全面、s o a 效益可能受损、长期开销大等。 他表示，企业可以根据自身不同的情况选择不同的部署策略。 i d c 中国副总经理万宁则指出，目前s o a 在中国还面临些阻碍因素：企业要大规 模应用s o a ，特别是要涉及到跨省跨多地区的应用时，会需要改造自己的业务系统，涉 及很多人员和投入，此外还要解决安全和效率的问题，用户会有较大的顾虑：其次， s o a 在可靠性、安全性、遗留系统支持等方面还存在一定不足，这些都影响了s o a 的实 际实施和推广。 ， 4 1 3 主要研究内容 本文以面向服务的体系结构的研究为主题，并根据理论研究结合实际项目，使一 种简单的s o a 架构在实际系统中得以实现。 本文主要研究内容如下： 1 分析s o a 架构的概念、特点，层次结构及原则等理论基础以及s o a 和w e b s e r v i c e 的关系。 2 论述s o a 架构的相关技术，包括w e bs e r v i c e 的工作原理，组成；e s b 在s o a 中的角色及采用a j a x 的理由等。 3 结合一个具体实例，提出一个基于a j a x 技术+ m v c 架构+ 企业服务总线( e s b ) 技 术的s o a 框架，并讨论了该框架在实际开发工作中的作用，分别对表示层及应用层进 行了详细设计。 第二章面向服务的体系结构( s o a ) 概述 w e b 服务一种作为炙手可热的技术，应用到企业的i t 系统和商业流程之中，并给 企业带来直接的经济效益，一直以来得到了国内外企业管理者的推崇。而在近两年， 伴随着企业需求的不断变化，一种被誉为下一代w e b 服务的技术架构，再一次引起业 内关注，这就是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 的一些基本知识。 2 1s o a 的概念 s o a ( 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 ，也叫面向服务的体系结构或面向服务架构) 是指为了解决在i n t e r n e t 环境下业务集成的需要，通过连接能完成特定任务的独立功 能实体实现的一种软件系统架构。s o a 是一个组件模型，它将应用程序的不同功能单元 ( 称为服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方 式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构 建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互“1 。 传统的w e b ( h t m l h t t p ) 技术有效的解决了人与信息系统的交互和沟通问题，极大 的促进了b 2 c 模式的发展。w e b 服务( x m l s o a p w s d l ) 技术则是要有效的解决信息系统 之间的交互和沟通问题，促进b 2 b e a i c b 2 c 的发展。s o a ( 面向服务的体系) 则是采用 面向服务的商业建模技术和w e b 服务技术，实现系统之问的松藕合，实现系统之间的 整合与协同。w e b 服务和s o a 的本质思路在于使得信息系统个体在能够沟通的基础上形 成协同工作。 s o a 不是一种技术，也不是一种产品，更不是一种时尚。s o a 是一种架构，是一种 思想，或者说，一种通过最佳技术手段实现企业业务整合的理想。s o a 不是一个新概念。 早在1 9 9 6 年，g a r t n e r 最早提出s o a 的思想，2 0 0 2 年，g a r t n e r 提出s o a 是“现代应 用开发领域最重要的课题”，并预计到2 0 0 8 年，s o a 将成为占有绝对优势的软件工程实 践方法，2 0 1 0 年，采用s o a 体系的企业将占8 0 。这或许就是2 0 0 7 年s o a 火遍i t 业 的原因之一。用友、金蝶、i b m 、s a p 等国内外重头软件企业，纷纷高举s o a 大旗，用 s o a 概念包装已有或即将推出的各种产品和解决方案，备战2 0 0 8 市场。 s o a 是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行 分布式部署、组合和使用。服务层是s o a 的基础，可以直接被应用调用，从而有效控 制系统中与软件代理交互的人为依赖性”1 。 s o a 的关键是“服务”的概念”1 ，w 3 c 将服务定义为：“服务提供者完成一组工作， 为服务使用者交付所需的最终结果。最终结果通常会往使用者的状态发生变化，但也 可能使提供者的状态改变，或者双方都产生变化。” s e r v i c e a r c h i t e c t u r e c o m 将s o a 定义为：“本质_ 上是服务的集合。服务间彼此 通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活 动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他 服务所处环境和状态的函数。” l o o s e l y c o u p l e d c o m 将s o a 定义为：“按需连接资源的系统。在s o a 中，资源被 作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构 相比，s o a 规定了资源间更为灵活的松散耦合关系。” g a r t n e r 则将s o a 描述为：“客户端服务器的软件设计方法，一项应用由软件服 务和软件服务使用者组成s o a 与大多数通用的客户端服务器模型的不同之处，在 于它着重强调软件组件的松散耦合，并使用独立的标准接口。” g a r t n e r 相信b p m 和s o a 的结合对所有类型的应用集成都大有助益，“s o a 极大的 得益于b p i v i 技术和方法论，但是s o a 面临的真正问题是确立正确的企业意识，即：强 化战略化的s o a 计划( 针对供应和使用 并鼓励重用。” 虽然不同厂商或个人对s o a 有着不同的理解，但是我们仍然可以从上述的定义中 看到s o a 的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确 定义接口进行通讯，不涉及底层编程接口和通讯模型。 需着重注意的是，s o a 并不是新生事物，大型i t 组织成功构建和部署s o a 应用已 有多年的历史，这要比现有的x m l 和w e b 服务长很多。i b mc i c s 和b e at u x e d o 就是过 去被用于构建s o a 应用的两种技术范例。 重点说嘎的是s o a 并不是一种现成的技术，丽是一种架构和组织i t 基础结构及业 务功能的方法。s o a 是一种在计算环境中设计、开发、部署和管理离散逻辑单元( 服务) 的模型。这一定义阐明了s o a 的范围。 s o a 要求开发人员将应用设计为服务的集合。s o a 要求开发人员跳出应用本身进行 思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、 “独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方 法将它们组合成较大型的服务，由此来实现重用“1 。 但是，s o a 并不仅仅是一种开发方法，它还具有管理上的优点。例如，现在管理员 可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分 析服务间的交互，s o a 可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使 管理员或分析师能够有针对性的优化业务流程。 2 2s o a 的特点 1 编码灵活性 可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这 些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务 实现方式本身也可以灵活使用 1 0 l 。 2 明确开发人员角色 熟悉b e s 的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了 解b e s 的实现，而将精力放在解决高价值的业务问题上。 3 支持多种客户类型 借助精确定义的服务接口和对x m l 、w e b 服务标准的支持，可以支持多种客户类型， 包括p d a 、手机等新型访问渠道。 4 更易维护 服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实 现。 5 更好的伸缩性 依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此 独立调整，以满足服务需求。 6 更高的可用性 该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解 提供者的实现细节，这样服务提供者就可以在w e b l o g i c 集群环境中灵活部署，使用者 可以被转接到可用的例程上。 2 3 $ o a 服务的层次结构 面向服务架构倡导通过服务的组合来构架灵活的系统，即将不太复杂的服务组合 成更复杂的服务、应用程序。在架构中，一个服务可能与其它服务组合形成上一层的 较大粒度的服务，同时被组合的服务又可能是其下层的一系列服务经组合而得到的， 这就是服务的层次结构“。 按照服务的层次结构来分可有原子服务和组合服务两种类型 1 2 1 0 原子服务是最基 本的功能逻辑单元，位于服务层次结构的最底层，类似“叶子”的概念。它存在的目 的是增强功能逻辑的重用性，其内部封装了实现特定功能的服务组件。组合服务，顾 名思义，是由多个原子服务通过编排、组合的方式形成的。它和原子服务一样提供接 口供外部调用。相对而言，组合服务经常特定于某个应用，其实现目的不是完全针对 重用性，而是侧重于如何灵活的组合一系列服务以贴切特定应用的需求。 可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗 粒度服务和组合服务“”。 细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。 如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生 在每个服务上的数据量较少，因而会对系统整体性带来影响。所以粗粒度服务的用户 不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服 务，因此它们不能提供粒度级的安全和访问控制“”。 组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量不是粗粒度服务 和组合服务之间的区别。租粒度服务例子，如创建新客户，在这一过程的操作是：需 要通过一些外部服务验证对客户进行验证，并在c r m 应用系统中创建客户记录。组合 服务例子可以是提供一个新的d s l 线，这需要一个服务调用来验证定单、创建或验证 客户，确认产品库存及为数据线分配资源。 2 4s o a 的三大基本特征 1 独立的功能实体 在i n t e r n e t 这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图 通过i n t e r n e t 进行控制的结构都会面临严重的稳定性问题。s o a 非常强调架构中提供 服务的功能实体的完全独立自主的能力。传统的组件技术，如。n e tr e m o t i n g ，e j b ， c o m 或者c o r b a ，都需要有一个宿主( h o s t 或者s e r v e r ) 来存放和管理这些功能实体； 当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部 分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。 s o a 架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术， 比如事务处理( t r a n s a c t i o n ) ，消息队列( m e s s a g eq u e u e ) ，冗余部署( r e d u n d a n t d e p l o y m e n t ) 和集群系统( c l u s t e r ) 在s o a 中都起到至关重要的作用。 2 大数据量低频率访问 对于n e tr e m o t i n g ，e j b 或者) ( m l r p c 这些传统的分布式计算模型而言，他们的 服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服 务器来回很多次函数调用才能完成。在i n t r a n e t 的环境下，这些调用给系统的响应速 度和稳定性带来的影响都可以忽略不计，但是在i n t e r n e t 环境下这些因素往往是决定 整个系统是否能正常工作的一个关键决定因素。因此s o a 系统推荐采用大数据量的方 式一次性进行信息交换。 3 基于文本的消息传递 由于i n t e r n e t 中大量异构系统的存在决定了s o a 系统必须采用基于文本而非二进 制的消息传递方式。在c o m 、c o r b a 这些传统的组件模型中，从服务器端传往客户端的 是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能：但是在 i n t e r n e t 环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同， 给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何 处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式 可以帮忙绕过兼容性。 此外，对于一个服务来说，i n t e r n e t 与局域网最大的一个区别就是在i n t e r n e t 上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无 9 法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的 那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。 从s o a 的几个重要特征可以看出，s o a 之所以被用于信息资源整合，是因为其具备 了标准化、可操作、可组装的特性。s o a 提供了一个通用的、可互操作的和有弹性的行 业标准架构，可以在软件基础架构中建立一系列支持商业模型的可重复利用的服务， 这些服务由不同应用系统的组件构成，能够罄助企业实现适应商业流程变化的需求“”。 2 5s o a 的原则 s o a 是一种企业架构，因此，它是从企业的需求开始的。但是，s o a 和其它企业架 构方法的不同之处在于s o a 提供的业务敏捷性。业务敏捷性是指企业对变更快速和有 效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个 业务敏捷的架构意味蕾创建这样一个i t 架构，它可以满足当前还未知的业务需求。 要满足这种业务敏捷性，s o a 的实践必须遵循以下原则“”： 1 业务驱动服务，服务驱动技术 从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师 一方面必须理解在业务需求和可以提供的服务之问的动态关系，另一方面，同样要理 解服务与提供这些服务的底层技术之间的关系。 2 业务敏捷是基本的业务需求 s o a 考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”；而不 是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏 捷的需求，因为，在s o a 中任何的瓶颈都会影响到整个i t 环境的灵活性。 3 一个成功的s o a 总在变化之中 s o a 工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。 i t 环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习 惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。 2 6s o a 和w e bs e r v i c e 的根本区别 s o a 和w e bs e r v i c e 有如下的共同点： 1 ) 都提供服务； 2 ) 服务接口都是基于开发的； 3 ) 服务接口和服务的具体实现都是分离的。 其实，w e bs e r v i c e 是构建s o a 的核心组件。 w e bs e r v i c e 服务接口需要绑定具体实现服务的服务组件来实现服务，它对具体的 服务实现完成了封装，如图2 1 所示，实现了服务的透明化，客户端不需要知道服务 l o 是如何实现的，但是w e bs e r v i c e 组件本身是知道服务是如何实现的，另外客户端调 用w e bs e r v i c e 组件时，需要知道w e bs e r v i c e 的具体位置和传输协议，这些都会造 成一定的不灵活性，它只是实现了一定程度上的抽象。 图2 1w e bs e r v i c e 服务接口绑定服务实现组件 s o a 架构平台只和服务接口进行绑定，对服务接口实现了封装，如图2 2 所示，实 现了服务接口的透明化，服务位置的透明化，服务传输协议的透明化。s o a 本身也不知 道服务具体是如何实现的。当客户端通过s o a 调用服务时，不需要知道真正的服务提 供者是谁，具体的服务位置在哪里和具体的传输协议是什么。s o a 实现了最高程度上的 抽象化，为实现具有最高灵活性的服务建立了架构基础。 图2 2s o a 架构平台和服务接口进行绑定 第三章s o a 的相关技术 3 1w e bs e r v i c e 概述 当前大多数企业都有过去遗留下来的异构系统、应用、商业流程以及数据源构成 的应用环境，应用环境的通信十分困难。从一定角度而言，我们必须解决这样两个问 题：一是实现跨平台的互操作；二是对己有系统的集成，包括已有的商业数据。只有 解决第一个问题，我们提出的方案才具有技术上的可行性；只有解决第二个问题，我 们提出的方案才具有商业上的可行性。自从有了i n t e r n e t ，h t t p 协议就广为使用，其 简单性、可靠性、通用性使得依靠它的网页可以流行在各个平台上。x m l 语言的诞生使 得信息的传输可以脱离平台和编程语言的限制，为网络上各种系统的“对话”提供了 一门“国际化的语言”。s o a p 协议为服务的请求、消息的格式定义了简单的规则，并 得到各大系统软件提供商的支持。这一切仿佛都使得w e b 服务的出现成为一种必然。 w e bs e r v i c e 的主要目标是跨平台的可互操作性| 1 7 1 0 为了达到这一目标，w e b s e r v i c e 完全基于) ( m l ( 可扩展标记语言) 、x s d ( x m l s c h e m a ) 等独立于平台、独立于 软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。w e bs e r v i c e 平台 需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型 系统。要实现互操作性，w e bs e r v i c e 平台必须提供一套标准的类型系统，用于沟通不 同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 ( i n t e r f a c e ) 的平台提供了一些方法来描述界面、方法和参数( 如c o m 和c o b a r 中的i d l 语言) 。同样的，w e bs e r v i c e 平台也必须提供一种标准来描述w e bs e r v i c e ，让客户 可以得到足够的信息来调用这个w e bs e r v i c e 。最后，我们还必须有一种方法来对这个 w e bs e r v i c e 进行远程调用。这种方法实际是一种远程过程调用协议( r p c ) 。为了达到 互操作性，这种r p c 协议还必须与平台和编程语言无关。 w e bs e r v i c e 并不是一个纯新的技术，它是建立在现有的技术和规范的基础上的一 个标准，如h t t p ，x m l ，s o a p ，w s d l ，u d d i 等标准。它是下一代分布式系统的核心。 作为一种部署在w e b 上的对象，它有着松散耦合、完好的封装性、使用标准协议规范、 高度的可集成能力等特征。 w e bs e r v i c e 本质上就是要以标准的方式实现企业内外各个不同服务系统之间的 互调或者集成。w e bs e r v i c e 的三个组成部分如图3 1 所示。 ij l i 卫 卫 丑 图3 1w e bs e r v i c e 的三个组成部分 3 2w e bs e r v i c e 相关技术 可扩展的标记语言( x m l ) 是w e bs e r v i c e 平台中表示数据的基本格式。除了易于建 立和易于分析外，x m l 主要的优点在于它既是平台无关的，又是厂商无关的。无关性是 比技术优越性更重要的；软件厂商是不会选择一个由竞争对手所发明的技术的。 x m l 是一种元语言，是i n t e r n e t 环境中跨平台的，依赖于内容的技术，也是当今 处理分布式结构信息的有效工具l l s l 。早在1 9 9 8 年，w 3 c 就发布了x m l l 0 规范，使用 它来简化i n t e r n e t 的文档信息传输。它是针对网络应用的一项较成熟的新技术。x m l 是w 3 c 的一个推荐标准。w 3 c 组织制定) 0 4 l 标准的初衷是，定义一种互联网上交换数据 的标准。w 3 c 采取了简化s g m l 的策略，在s g m l 基础上，去掉语法定义部分，适当简化 d t d 部分，并增加了部分互联网的特殊成分。因此，x m l 也是一种置标语言，基本上是 s g m l 的一个子集。因为x m l 也有d t d 所以y , m l 也可以作为派生其它置标语言的元语言。 因此，x m l 的用途主要有两个，一是作为元置标语言，定义各种实例置标语言标准；二 是，作为标准交换语言，担负起描述交换数据的作用。 ) ( m l 的发展异常迅速，有很多软件开发商都采用了x m l 标准。在未来的w e b 应用开 发中x m l 将无处不在，x m l 将和h t m l 一样受到重视，它们都是w e b 的基础技术，而x m l 也将成为最普遍的数据操纵和数据传输工具。x m l 具有以下特点n 盯： 1 x m l 可以从h t m l 中分离数据，即通过x m l ，可以在h t m l 文件之外存储数据。 在不使用x m l 时，h t m l 用于显示数据，数据必须存储在h t l d l 文件之内。使用了x m l 后，数据就可以存放在单独的x m l 文档中。 2 x m l 可用于交换数据，使得可以在不兼容的系统之间交换数据。对于开发者， 最耗费时间的工作就是遍布在网络中的系统之间交换数据。把数据转换为x m l 格式存 储将大大减少交换数据时的复杂性，可以使这些数据被不同的程序读取。 x m l 文档决定了文档的内容，样式表x s l ( e x t e n s i b l es t y l e s h e e tl a n g u a g e ) ， 则规定着文档的显示。c s s 是一种静态的样式描述格式，其本身不遵从x m l 的语法规范。 而x s l 不同，它是通过x m l 进行定义的，遵守x m l 的语法规则，是x m l 的一