（计算机软件与理论专业论文）soa框架下面向web服务的注错测试工具研究.pdf

s o a 框架下面向w e b 服务的注错测试工具研究 摘要 随着w e b 服务的兴起而提出的面向服务的体系架构s o a 为i n t e r n e t 上的分 布式计算提供了支持异构平台和多种语言的构件式程序架构。s o a 强调的是w e b 服务之间的互操作，而w e b 服务互操作时可能引发消息和通讯等错误，因此如 何测试w e b 服务问的交互关系，对w e b 服务软件进行总体测试十分重要。 本文基于注错测试技术对s o a 框架下各w e b 服务之间交互的系统健壮性进 行了测试研究，主要工作如下： 1 研究了s o a 及w e b 服务的相关概念和技术及系统架构，并分析了基于注 错技术的测试方法。 2 研究w e b 服务交互的特点，提出一种用于w e b 服务交互的健壮性测试的 注错测试方法；在详细分析w e b 服务错误类型的基础之上，提出了针对w e b 服 务交互时通信错误的错误扩展模型；基于上述测试方法和错误模型创建测试用 例。 3 设计并实现了s o a 架构下w e b 服务消息交互健壮性的注错测试工具 f i t 4 s o a ，并通过实验验证了该工具的有效性。 关键词：s o aw e b 服务注错测试测试工具 ar e s e a r c ho nf a u l ti n j e c t i o nt e s t i n gt o o lf o rw e bs e r v i c e u n d e rs o aa r c h i t e c t u r e a b s t r a c t a c c o m p a n y i n gt h er i s i n go fw e bs e r v i c e ，s e r v i c eo b j e c t e da r c h i t e c t u r ei sp u t f o r w a r d ，i tp r o v i d e s a c o m p o n e n ta r c h i t e c t u r e w h i c hs u p p o r t sh e t e r o g e n e o u s p l a t f o r ma n dm u l t i l a n g u a g ef o rd i s t r i b u t ec o m p u t i n go ni n t e m e t s o ae m p h a s i z e s t h ei n t e r o p e r a t i o no fw e bs e r v i c e s ，h o w e v e r ，t h ei n t e r o p e r a t i o no fw e bs e r v i c e s m a yi n d u c et h ef a u l to fm e s s a g ea n dc o m m u n i c a t i o n 。t h e r e f o r eh o wt ot e s tt h e r e l a t i o no fi n t e r a c t i o nb e t w e e nw e bs e r v i c e s ，i ti sv e r yi m p o r t a n tt o t e s tt h ew e b s e r v i c es o f t w a r ea saw h o l e t h i sd i s s e r t a t i o nh a v er e s e a r c h e dt e s t i n gt h ei n t e r a c t i o nr o b u s t n e s so fe a c h w e bs e r v i c e su n d e rs o ab a s e do nf a u l ti n j e c t i o n t e c h n o l o g y ，t h em a i nt a s k s a c h i e v e da r el i s t e da sf o l l o w s ： 1 t h er e l a t e dc o n c e p t ，t e c h n o l o g ya n da r c h i t e c t u r eo fs o aa n dw e bs e r v i c e w e r er e s e a r c h e d ，a n dt h et e s t i n gm e t h o d sb a s e do nf a u l ti n j e c t i o nt e c h n o l o g yw e r e a n a l y s i e d 2 r e s e a r c h e do nt h ec h a r a c t e r i s t i co fw e bs e r v i c e si n t e r a c t i o n ，ak i n do ff a u l t j n j e c t i o nt e s t i n gm e t h o dt h a tw a su s e dt ot e s tt h ew e bs e r v i c e s i n t e r a c t i o n r o b u s t n e s sw a sp u tf o r w a r d t h e nb a s e do nt h ea n a l y s i so ft h ef a u l tt y p eo fw e b s e r v i c ei nd e t a i l ，a ne x t e n d e df a u l tm o d e lf o rt h ec o m m u n i c a t i o nf a u l to fw e b s e r v i c e s i n t e r a c t i o nw a sp u tf o r w a r d a n dt e s tc a s e sw e r ee s t a b l i s h e do nt h et e s t i n g m e t h o da n dt h em o d e la b o v e m e n t i o n e d 3 f i t 4 s o a ，af a u l ti n j e c t i o nt e s t i n gt o o l ，w a sd e s i g n e df o rw e bs e r v i c e s m e s s a g ei n t e r a c t i o nr o b u s t n e s su n d e rs o a a n di t sv a l i d i t yw a st e s t i f i e db y e x p e r i m e n t sa tt h ee n do ft h ep r e s e n tt h e s i s k e y w o r d s ：s o a ，w e bs e r v i c e ，f a u l ti n j e c t i o nt e s t i n g ，t e s t i n gt o o l 插图清单 图2 一l 面向服务的体系结构的元素8 图2 - 2 面向服务的体系结构中的协作9 图2 3w e b 服务协议层次1 1 图2 4 简单的s o a p 消息处理1 3 图2 - 5 请求响应消息交换模式1 4 图2 - 6s o a p 消息结构1 5 图2 - 7u d d i 规范和a p is c h e m a 1 8 图2 - 8u d d i 数据信息1 9 图3 一lw e b 系统体系结构2 6 图3 2 互操作性2 8 图3 3 注错测试系统模型3 3 图4 - 1s o a 的j a v a 实现3 9 图4 - 2 注错测试工具f i t 4 s o a 模型架构4 0 图4 - 3 系统流程顺序图4 2 图4 - 4 注错测试模块4 3 图4 5 注错测试模块数据库模型4 4 图5 - 1j d b c 配置图4 7 图5 - 2y m s 配置图4 8 图5 - 3w e b 服务部署图“4 9 图5 4 测试结果显示5 4 表格清单 表3 - i 测试分类图2 4 表3 2 通信错误的错误扩展模型3 6 表5 1 测试用例表5 3 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标志和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得金胆工业太堂或其 他教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做 的任何贡献均已在论文中作了明确的说明并表示谢意。 学位论文作者签字：黑葡签字日期：矽占年f 月现日 学位论文版权使用授权书 本学位论文作者完全了解金理工些盘堂有关保留、使用学位论文的规 定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被 查阅或借阅。本人授权盒胆兰些太堂可以将学位论文的全部或部分论文内 容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇 编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者签名：黑营导师签名： 签字日期：加以年箩月弘日签字日期：“年r 月日 学位论文作者毕业后去向： 工作单位：霉镍岛呋鼍 通讯地址：套j ；j 巴夸羹荔南材尹f 。噻 电话；l 萄6 。3 瑚2 邮编：2 ；卿i 致谢 衷心感谢我的导师李心科副教授! 在本论文的选题、写作和修改的过程中， 自始至终得到了李老师的关心、指导和帮助。导师的悉心培养和谆谆教诲伴随 我走过了三年的时光，没有导师的培养和指导，也就没有本文的顺利完成。在 我的研究生学习和生活期间，得到了导师的极大帮助和关心。导师渊博的学识、 敏锐的思维、严谨的治学态度、高尚的道德情操、平易近人的人格魅力、所有 这些都使我终身受益。 感谢计算机学院的老师们，感谢他们给我提供的学习条件和机会。 感谢软件工程实验室的同学们在我论文写作期间给予的无私帮助和支持。 感谢我的家人，他们始终如一的爱和关怀是我求学道路上最大的支持! 最后，再次衷心感谢所有关心和支持我的师长、同学、朋友和亲人们，他 们的帮助和期望是我在学习和生活中前进的不竭动力! 作者：吴蕾 2 0 0 5 年4 月 第一章概述 本章主要对课题的研究背景、研究意义，国内外研究现状，以及本文的组 织结构进行介绍。 1 1 研究背景 1 1 1 基于w e b 服务的s o a 架构的广泛应用 随着互联网技术应用与产业的快速发展，客观上要求企业之间甚至大型企 业内部软件应用之间进行复杂的交互。这样就必然要求在i n t e r n e 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 n t e r n e t 环境下的协同计算 ( 如网格计算、虚拟组织等等) 。就目前而言，w e b 服务是实现s o a 架构的最合适 的现实技术。1 ，w e b 服务被看作是s o a 的i n t e r n e t 应用，通过对w e b 服务的构建， 人们期望得到一个可编程的i n t e r n e t ，实现分布式的计算和异构平台的信息集 成。而代码可以跨平台的j a v a 成为开发w e b 服务及s o a 集成的自然选择。 目前己经有一系列基于x m l 的w e b 服务标准被业界广泛接受，形成了w e b 服务 的核心技术。服务的提供者可以用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 服务；用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 ) 注册中心发布、注册w e b 服务：服务的请求者通过u d d i 进行查询，找到所需的服 务后，利用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 0 1 ) 绑定、调用这些服务0 1 。 w e b 服务继承了x m l 语言的优势，是一种与开发语言、平台无关的开发技术，并 采用和支持国际公开的开放技术标准规范。针对业己公布的标准，许多大型企 业( 如i b m ，m i c r o s o f t ，s u n ，b e a 等) 开始着手对基于w e b 服务的面向服务的体系架 构予以实现和推广。 1 1 2 现有测试方法的局限性 由于s o a 强调的是架构中各w e b 服务之间的互操作，对s o a 集成测试的关键在 于测试w e b 服务之间交互时可能引发的消息及通信错误。这类通信错误主要包 括：消息的丢失、重复、延迟、乱序或内容错误。传统的分布式系统一般运行 在l a n 中并可以假定这一类型的错误可忽略，但是在s o a 架构中，如果在消息传 递时出现这类错误就会被认为系统是不可靠的。而由于消息通信类错误的发生 存在极大的偶然性，有时系统运行上百次某一通信错误也不发生一次，这时我 们并不能说明这种类型的错误就不可能发生，因此我们必须选择合适的测试技 术才能很好地对通信类错误进行测试，从而维护系统的容错性。研究表明，错 误注入简称注错技术是解决以上问题的一个很好的方法“1 。 由于实时性限制等原因，传统的注错技术并不适用于分布式应用系统的测 试；而目前利用注错技术对分布式系统的测试研究工作也仍然聚焦在基于紧密 耦合的系统”，这对于测试s o a 显然是不合适的。此外，现存的注错工具大多能 够有效地测试网络消息的丢失和毁坏“1 ，但是对于w e b 系统的其它更详细性能的 测试是无效的。所以我们要通过对s o a p 消息中的x m l 文档进行解析，注入有意义 的错误才能更好地、更有针对性的测试s o a 集成时的消息通信错误。 1 1 3 测试工具研究现状 w e b j j 艮务的广泛应用促使了w e b 服务测试研究的兴起。w e b n 务测试研究 可分为服务功能测试、负载测试、客户端测试等几种。目前开发的大部分测试 工具针对的是单个w e b 服务测试，支持w e b ) j 务集成的测试工具相对较少。目前 的w e b 服务测试工具有： s o a p t e s t 测试软件是由p a r a s o f t 公司开发的一个测试w e b 服务的工具。 主要能实现功能测试、负载测试等。 j m e t e r 是a p a c h e 组织的开放源代码项目，它是功能和性能测试的工 具，1 0 0 的用j a v a 实现。 注错测试技术给验证容错计算机和软件系统的可靠性提供了一种有效的解 决方式。应用注错来检测和验证硬件设计已经有很长的历史了，而有很长一段 时间，使用软件进行注错在研究领域一直没有被重视起来。但是，由于其复杂 性和系统用户的数量迅速增加，导致软件错误的潜在后果相当严重，将软件注 错技术应用于软件学说具有重要的意义。目前的注错工具有： 中国安天实验室( a n t i yl a b s ) 参考国际容错和诊断技术的思路和成果， 开发了基于u n i x 系统的错误注入平台i n j e c t e r ，这个工具可以自动对软件系 统注入错误，从而达到高效测试软件缺陷的目的”1 。 d o c t o r “1 和o r c h e s t r a ”都能够被用来执行状态扰动和网络层错误注入，但 是它们被设计为以协议测试和系统测试为一般目标，不能实现在s o a p 消息中注 入有意义的错误。 1 2 研究内容和主要工作 本文研究内容主要分为以下四个方面： 1 研究了s o a 及w e b 服务的相关概念和技术及系统架构，并分析了基于注 错技术的测试方法。 2 研究w e b 服务交互的特点，提出一种用于w e b 服务交互的健壮性测试的 注错测试方法；在详细分析w e b 服务错误类型的基础之上，提出了针对w e b 服 务交互时通信错误的错误扩展模型：基于上述测试方法和错误模型创建测试用 例。 3 设计并实现了s o a 架构下w e b 服务消息交互健壮性的注错测试工具 f i t 4 s o a ，并通过实验验证了该工具的有效性。 为了使测试工具实现自动在w e b 服务之间传递的消息中执行s o a p 译码和状 态扰动，从而实现将消息丢失、重复、延迟、讹传、乱序等w e b 交互时可能发 生的有意义的错误注入系统以测试s o a 框架下w e b 服务集成的容错性的功能。 本课题分析现有的注错方法和工具，结合s o a 结构和w e b 服务的特点。利用j a v a 的w e b 服务开发包j w s d p ( j a v aw e bs e r v i c e sd e v e l o p e rp a c k ) 在j 2 e e 平台上 开发所需的注错测试工具，并将所实现的工具应用到一个实例场景中来收集测 试数据进行分析评估该工具有效性。 1 3 文本的组织 本文共分为六个部分： 第一部分：课题概述；本章阐述课题的研究背景和国内外研究现状，以及 研究内容、主要工作和文本的组织； 第二部分：相关理论介绍与分析；本章首先介绍了面向服务的软件体系结 构的基本概念和原理，然后从w e b 服务入手，介绍了组成w e b n 最务的几个规范标 准，包括x m l ，s o a p ，w s d l ，u d d i 标准，最后给出了面向服务的软件体系结构与w e b 服务之间的关系。 第三部分；注错测试技术；本章以传统的软件测试、w e b 测试及注错测试 技术为立足点，结合w e b 服务交互的特点，提出了面向w e b 服务的注错测试技 术。并在分析了w e b 服务通信错误的基础上，建立了w e b 服务交互的错误扩展 模型。 第四部分：基于j a v a 测试工具的设计与实现；本章首先介绍了如何用代码 可以跨平台的j a v a 技术实现s o a 架构，然后提出了基于j a v a 面向w e b 服务的 注错测试工具模型架构，并进一步系统介绍了该工具的实现模块。 第五部分：测试工具的应用及评估；本章说明了将f i t 4 s o a 注错测试工具 应用于特定场景时的情况，并通过对测试数据的收集分析论证了该注错工具的 有效性 第六部分：结束部分；对本文的工作进行了总结与展望。列出了论文中较 有特点的工作，提出了进一步的研究方向。 第二章s o a 及w e b 服务 w e b 服务的兴起提出了s o a ( s e r v i c eo b j e c t e da r c h i t e c t u r e ) 的软件体系 结构，为i n t e r n e t 上的分布式计算提供了支持异构平台和多种语言的构件式程 序结构。随着新一代i n t e r n e t 的兴起，该程序设计模型必将得到广泛应用。“1 2 1s o a 软件体系结构 2 1 1s o a 的定义及原则 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 是指为了解决在i n t e r n e t 环境下业务集成的需要，通过连接能完成特 定任务的独立功能实体实现的一种软件系统架构。 2 1 。1 1s o a 的定义 理解这个概念我们需要体会两个方面的含义： 1 、软件系统架构： s o a 不是一种语言，也不是种具体的技术而是一种软件系统架构，它尝 试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模 式( p a t t e r n ) 。因此它与很多已有的软件技术比如面向对象技术，是互补的而非 互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。 2 、s o a 的使用范围： 需求决定同时也限制功能。s o a 并不是包治百病的万灵单，它最主要的应 用场合在于解决在i n t e r n e t 环境下的不同商业应用之间的业务集成问题。在下 面我们会详细讨论i n t e r n e t 的各种特点是如何决定了s o a 的特点，这里我们只 需要先简单回顾一下i n t e r n e t 环境区别于i n t r a n e t 环境的几个特点： 1 ) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语 言也不同： 2 ) 大量、频繁的数据传输仍然速度缓慢并且不稳定； 3 ) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者 间接的使用某个服务。 2 1 1 2s o a 需遵循的原则 1 、业务驱动服务，服务驱动技术 从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构 设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方 面，同样要理解服务与提供这些服务的底层技术之间的关系。 2 、业务敏捷是基本的业务需求 s o a 考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需 求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构 都必须满足业务敏捷的需求，因为，在s o a 中任何的瓶颈都会影响到整个i t 环境的灵活性。 3 、一个成功的s o a 总在变化之中 s o a 工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋 房子”。i t 环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不 会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭 新的思维方式。 2 1 2s o a 的优势及作用 企业正在处理两个问题：迅速地改变的能力和降低成本的要求。为了保持 竞争力，企业必须快速地适应内部因素( 如兼并和重组) 或外部因素( 如竞争 能力和顾客要求) 。需要经济而灵活的i t 基础设施来支持企业。 我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处， 有助于我们在今天这个动荡的商业环境中取得成功： 1 利用现有的资产 s o a 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在i t 方 面的投资。方法是将这些现有的资产包装成提供企业功能的服务。组织可以继 续从现有的资源中获取价值，而不必重新从头开始构建。 2 更易于集成和管理复杂性 在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明 性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针 对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于 管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得 更加重要。 3 、更快的响应和上市速度 从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的 组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发 生命周期( 包括收集需求、进行设计、开发和测试) 所需的时间。这使得可以 快速地开发新的业务服务，并允许组织迅速地对改变做出响应和减少上市准备 时间。 4 、减少成本和增加重用 通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地 使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增 加。 5 、说到做到 通过s o a ，企业可以未雨绸缪，为未来做好充分的准备。s o a 业务流程是 由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时期 的需要。s o a 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关 重要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到s o a 也并非一件 可以轻而易举就完成的事情。请鄹指望一个晚上就将整个企业系统迁移到面向 服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业 功能的适当部分。 2 1 3s o a 的特征 1 、独立的功能实体： 在i n t e r n e t 这样松散的使用环境中，任何访问请求都有可能出错，因此任 何企图通过i n t e r n e t 进行控制的结构都会面临严重的稳定性问题。s o a 非常强 调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如n e t r 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 td 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 或者x 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 上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布 式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选 择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想 的兼容性。 2 。1 4s o a 的体系结构 2 1 4 1s o a 体系结构堆栈 图2 - l 面向服务的体系结构的元素 面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系 统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元 素可以分成功能元素和服务质量元素。图2 1 展示了体系结构堆栈以及在一个 面向服务的体系结构可能观察到的元素。“， 体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右 边的一半集中于体系结构的服务质量方面。这些元素详细描述如下： 8 功能性方面包括： 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者， 并且将来自服务提供者的响应传送给服务使用者。 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务 使用者可以就将要请求的内容和将要返回的内容进行沟通。 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服 务以及成功地调用服务需要什么数据。服务描述实际可供使用的服务。 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则 进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就 产生了业务流程可以由不同粒度的服务组成的观念。 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务 注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可 用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。 服务质量方面包括： 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务 可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我 们在功能和服务质量两个区中都有策略功能。 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和 访问控制。 传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要 使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个 完成。 管理是属性集，可以应用于管理提供的服务或使用的服务。 2 1 4 2s o a 协作 图2 2 面向服务的体系结构中的协作 图2 2 展示了面向服务的体系结构中的协作。1 这些协作遵循“查找、绑 定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册 9 中心来查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接 口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、 绑定和调用”范例的实体。 服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务 的另一个服务。它发起对注册中心中的服务的查询。通过传输绑定服务，并且 执行服务功能。服务使用者根据接口契约来执行服务。 服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来 自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务 使用者可以发现和访问该服务。 服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务 的存储库，并允许感兴趣的服务使用者查找服务提供者接口。 面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中 心这三种角色中的某一种( 或多种) 。面向服务的体系结构中的操作包括： 发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和 调用它。 发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准 的服务。 绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的 信息来调用服务。 2 1 4 3s o a 中的构件 服务：可以通过己发布接口使用服务，并且允许服务使用者调用服务。 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来 自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和 或服务质量( q o s ) 级别。 除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具 有以下特征： 服务是自包含和模块化的。 服务支持互操作性。 服务是松散耦合的。 服务是位置透明的。 服务是由组件组成的组合模块。 这些特征也是满足电子商务按需操作环境的要求的主要特征，如 “e b u s i n e s s0 1 2d e m a n da n ds 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 ”所定义的。 2 2w e b 服务软件体系结构 w e b s 务( w e bs e r v i c e ) 通常指通过w e b 提供的各种服务。一个典型的w e b 服务过程是：一个业务应用通过使用h t t p 的s o a p 协议向某个指定u r l 上的一个服 务发出请求，这个服务接收并且处理该请求后返回一个响应。” w e b s 务的体系结构是一种分布式的、用来促进跨平台的点对点程序间的通 信。服务a ( 一个“请求者”应用程序) 使用一个w e b 服务编程接口( s o a p ) 和一个注册中心( u d d i ) 来定位服务“b ”。可以用( 也可以不用) w s d l 来帮助 程序确定互相通信的参数。“”所有这些都发生在因特网上( 使用h t t p 作为通信 协议) 。要解决这种通信，最重要的概念就是将紧密耦合的应用程序变成松散 耦合的应用程序。构建松散耦合的应用程序相对于紧密耦合的应用程序而言更 简单，因为开发者不需要花大量的时间定义哪里可以找到合作应用程序，也不 需要花时间定义允许他们通信的规则。松散耦合的应用程序的维护相对也较容 易，因为紧密耦合的应用程序的任何一方一旦崩溃，则双方的应用程序都会崩 溃，而这种情况通过w e b 服务可以很好的克服，因为可以动态查找替补应用程序， 并且可以自动运行。应用程序的松散耦合还提供了一定级别的灵活性和互操作 性。但是这种为实现松散耦合而提出的w e b s 务体系结构也存在着一些安全性、 可靠性、服务保证方面的缺陷，因此在做系统集成测试时需充分考虑到这些因 素1 。 为了完成在松散耦合下的对象访问，w e bj 9 务定义了一系列的协议规程，如 图2 - 3 所示： 2 2 1x m 。 图2 3w e b s 务协议层次 x m l 是”e x t e n s i b l em a r k u pl a n g u a g e ”的缩写，即可扩展标记语言。它是 i n t e r n e t 环境中跨平台的、依赖于内容的技术，是这个时代中处理分布式结构 信息的选择工具。在w 3 c 组织领导下的工作小组发展并支持x m l 技术，使用它 来简化通过i n t e r n e t 的文档信息传输。 x m l 是年轻的m e t a 语言。早在1 9 9 8 年，w 3 c 就发布了x m l l 0 规范“”。内 容建设者们已经开始开发各种各样的x m l 应用程序，比如说数学标记语言 m a t h m l ，化学标记语言c m l 等等。 x m l 不仅满足了w e b 开发者的需要，而且适用于任何对出版业感兴趣的人。 o r a c l e 、i b m 以及m i c r o s o f t 公司都积极地投入人力与财力研发x m l 相关软件， 这无疑确定了x m l 在i t 产业的美好前景。 2 2 1 1 ) ( m l 的发展 最初x m l 的目标是让各种结构的文件都作为统一的网络文件的一部分在网 上传输过去这些文件是h t m l 实现的。h t m l 允许指定明确的元素类型说明，比 如特定的商品标号，文档标识，或是可测量的数值和h t m l 相比，x m l 允许客户定 义他们自己的文件元素集合，同时也可以指示这些素元在屏幕上如何按指定的 要求表现。 在早期，为了解决怎样在固定的目标之间传输数据元，x m l 被定义为一种自 然的编码形式。在一些方案被考虑之后，一种被称为r d f ( 资源描叙框架) 的方 案倍受亲睐。r d f 为x m l 提供了数据元编码定义。这就像是一个公用的翻译器， 为不同的固定目标之间的数据提供翻译。 x m l 将支持更加专业的数据语言，比如说o s d ( 开放软件描叙) 。o s d 是由 m i c r o s o f t 和m a r i m b a 提出的一种新的格式描叙语言。在这种格式下软件在网 上能时时检查，时时刷新版本。不是等用户自己更新，或由是软件提供商提供类 似的服务。当o s d 镶嵌于x m l 支持的c d f ( 频道定义格式) 中时，o s d 更能使支持 频道的桌面自动地更新。 x m l 的应用弥补了许多h t m l 的缺陷，我们把它在网上的应用总结为四点： 1 当网络客户必须在不同的数据库之间传递信息时的应用。 2 当需要把大部分从网络服务器载下的数据在用户端处理时的应用。 3 当相同的数据对于不同的用户需要有不同的界面时的应用。 4 当网络情报供货商要把发现的信息精心裁减，并发送给不同的个人用户 时的应用。 2 2 1 2x m l 的特点 x m l 是s g m l 的子集，包含s g m l 的主要有点，但同时保留人们对w e b 简洁性的 要求。正是x m l 的特点决定了其卓越的性能表现。x m l 作为一种标记语言，有许 多特点： 1 可扩展性：标记是面向内容的，用户可以自定义对自己有实际意义的标 记。 2 具有结构化特性：x m l 文档的实现是一种树形的结构，通过标签的嵌套， x m l 可以描述任意层次的文档结构。 3 内容与表现的分离性：x m l 文档只是对内容的描述，它的外观则需要通过 x s l 来描述。 4 平台无关性：x m l 是一种自描述的语言，数据本身就己经包含了元数据， 即关于数据本身的信息。另乡f x m l 是基于纯文本的语言，能够被各种平台支持。 2 2 1 3 删l 的应用 近年来x m l e 经逐渐成为不同应用之间彼此交换结构化数据的开放和有效 的机制。具体而言，x m l 主要有以下几个应用领域： 1 元数据和文档归档 2 数据传输 3 w e b 和互联网的应用 4 多媒体中的应用 5 行业应用 x m l 在这几个领域中的应用又可以归结成两种方式： 1 x m l 作为文档 2 x m l 作为消息 2 2 2s o a p s o a p 是一种轻量级协议，用于在分散型、分布式环境中交换结构化信息“”。 s o a p 利用x m l 技术定义一种可扩展的消息处理框架，它提供了一种可通过多种 底层协议进行交换的消息结构。这种框架的设计思想是要独立于任何一种特定 的编程模型和其他特定实现的语义。 a n yc o m m u n i c a t i o n s s o a pm e s s a g e 图2 4 简单的s o a p 消息处理 这个定义确实体现了s o a p 现在的主旨。s o a p 定义了一种方法以便将x m l 消息从a 点传送到b 点( 参见图2 - 4 ) 。为此，它提供了一种基于x m l 且具有以 下特性的消息处理框架：1 ) 可扩展，2 ) 可通过多种底层网络协议使用，3 ) 独立 于编程模型。 2 2 2 1s o a p 的特性 首先，s o a p 可扩展性是关键所在。在“s o a p ”这个缩写词中“s ”意味 着“简单”，事实上简单性总是比效率和纯技术更重要，因而互操作性成败的关 键，就在于必须绝对要求简单性。简单性是s o a p 的主要设计目标之一，这一 点的例证就是s o a p 缺少分布式系统的很多特性( 如安全性、路由和可靠性等) 。 s o a p 定义了一种通信框架，允许以分层扩展的形式随着时间推移而加入这些特 性。m i c r o s o f t 、i b m 和其他软件厂商正在积极开发一个s o a p 扩展的通用套 件，该套件将加入大多数开发人员期待的特性。 其次，s o a p 可在任何传输协议( 诸如t c p 、h t t p 、s m t p ，甚至是m s m q ) 上使用( 参见图2 4 ) 。然而，为了保持互操作性，需要定义一些标准协议绑 定以便草拟用于每种环境的规则。s o a p 规范提供了一种用于定义任意协议绑 定的灵活框架，并且由于h t t p 的使用极为广泛，它现已为h t t p 提供了一种 显式绑定。 第三，s o a p 允许任何编程模型，并且不依赖于r p c 。大多数开发人员立 刻将s o a p 与对分布式对象进行的r p c 调用等效起来( 因为s o a p 最初就是关 于“访问对象”的) ，但实际上。基本的s o a p 模型更接近于传统的消息处理系 统，如m s m q 。s o a p 定义了一种模型以便处理个别的单向消息。你可以将多 条消息组合成一条整体的消息交换。图2 - 4 说明了一种简单的单向消息，其中 发送方不会收到响应。但是，接收方可以向发送方发回一条响应( 参见图2 5 ) 。 s o a p 允许使用任何数量的消息交换模式( m e p ) ，请求响应只是其中一种。其 他示例包括要求响应( 与请求响应相对) 、通知和长期运行的点对点对话等。 请歆潲感 贼成溺虑 图2 - 5 请求响应消息交换模式 开发人员经常将请求响应与r p c 混为一谈，而实际上二者之间的差别很 大。r p c 使用请求响应