（计算机应用技术专业论文）soap协议的安全性研究与应用.pdf

姿圈三些查兰堡主兰壁垒塞 。 摘要 简单对象访问协议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 0 1 ) 是一种轻量级协议，用于 在分散型、分布式环境中交换结构化信息。s o a p 利用x m l 技术定义了一种町扩展 的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。s o a p 提 供了一种简单的、可扩展的并且功能丰富的x m l 消息处理框架，用于定义高级别的 应用程序协议，从而在分布式异构环境中提供更高的互操作性。 s o a p 协议是w e bs e r v i c e 技术的核心。随着w e bs e r v i c e 技术的不断成熟以及在 电子商务等领域的不断发展，s o a p 协议的安全性显得越来越重要。作为w e bs e r v i c e 技术的核心，s o a p 协议的安全性承载着w e bs e r v i c e 技术安全性的绝大部分责任。 本文对s o a p 协议进行了深入剖析，包括s o a p 消息处理框架、扩展性、处理模 型、协议绑定、r p c 和编码以及s o a p 类型等。通过对s o a p 协议的应用环境w e b s e r v i c e 的全面理解和掌握以及对x m l 签名和x m l 加密技术的深入理解，将x m l 签名和x m l 加密技术规范融入到了s o a p 协议当中，利用s o a p 协议可扩展性强的 特点，对s o a p 协议进行了安全性方面的扩展，并从机密性、完整性、不可否认性、 身份验证和授权等方面对s o a p 协议的安全性扩展进行了论证。最后讨论了s o a p 协议安全性的应用，设计实现了一个简单的以w i n d o w s 窗体程序为客户端的基于w e b s e r v i c e 技术的采购系统原型，并将s o a p 协议的安全性应用到了这个原型的银行资 金转账w e bs e r v i c e 模块上，实现了s o a p 协议安全性的应用。 通过对s o a p 协议进行安全性扩展，可以有效弥补s o a p 协议本身安全性差的不 足，同时也提高了以s o a p 协议为基础的w e bs e r v i c e 技术的安全性，增强了企业接 受w e bs e r v i c e 这个新兴的分布式计算的解决方案的信心，对于新技术的推广有重要 意义。 关键词：s o a p ，w e bs e r v i c e ，x m l ，x m l 签名，x m l 加密 咒阳1 业大学硕士学位论文 r e s e a r c ha n d a p p l i c a t i o n o l is o a p s e c u r t t y a b s t r a c t s o a pi sal i g h w c e i g h tp r o t o c o la n du s e df o re x c h a n g eo fs t r u c t u r a li n f o r m a t i o ni n d i s p e r s i v ea n dd i s t r i b u t i n g e n v i r o n m e n t s o a pd e f i n e sak i n do fe x t e n s i b l em e s s a g e p r o c e s sf r a m e w o r k ，w h i c hp r o v i d e s ak i n do f m e s s a g es t r u c t u r et h a tc a l le x c h a n g eb ym a n y k i n d so fb a s e dp r o t o c o l ，w i t hx m lt e c h n o l o g y s o a pp r o v i d e s ak i n do fs i m p l e ， e x t e n s i b l ea n dr i c hf u n c t i o n a lx m lm e s s a g ep r o c e s sf r a m e w o r k ，w h i c h i su s e df o r d e f i n i t i o no fh i g hl e v e la p p l i c a t i o np r o t o c o la n dp r o v i d e sh i g h e ri n t e r o p e r a b i l i l y i n d i s t r i b u t i n ge n v i r o n m e n t s o a pi st h ec o r eo fw e bs e r v i c et e c h n o l o g y w i t ht h ec o n t i n u a lg r o w nu pa n d d e v e l o p m e n t i ne l e c t r o n i cc o m m e r c ef i e l d s ，t h es e c u r i t yo fs o a p b e c o m e sm o r ea n dm o r e i m p o r t a n t a st h ec o r eo f w e bs e r v i c et e c h n o l o g y , t h es e c u r i t yo fs o a p t a k e st h em o s t r e s p o n s i b i l i t yo f s e c u r i t yo f w e bs e r v i c e + t h i sa r t i c l ea n a l y z e ds o a pd e e p l y , i n c l u d es o a pm e s s a g ep r o c e s sf r a m e w o r k ， e x p a n s i b i l i t y , p r o c e s sm o d e l ，p r o t o c o lb i n d i n g ，r p c a n de n c o d i n ga n ds o a pt y p e s ； s t u d i e dt h ea p p l i c a t i o ne n v i r o n m e n to fs o a p - w e b s e r v i c ea n dx m l s i g n a t u r e a n dx m l e n c r y p t i o np a r t i c u l a r l y ；e m b e d d e dx m ls i g n a t u r e a n dx m l e n c r y p t i o ni n t os o a p , m a k i n gu s e o ft h e e x p a n s i b i l i t y o fs o a p , e x t e n d e ds o a pi ns e c u r i t ya s p e c t ；a n d d e m o n s t r a t et h ee x t e n d so fs o a p i nc o n f i d e n t i a l i t y , i n t e g r a l i t y , a f f i r m a n c e ，i d e n t i f i c a t i o n a n da u t h o r i z a t i o n 。i nt h ee n d ，d i s c u s s e dt h ea p p l i c a t i o no fs o a ps e c u r i t y , d e s i g n e da n d i m p l i e da s t o c ks y s t e mp r o t o t y p ew h i c hi sb a s e do nw e bs e r v i c ea n dt h ec l i e n to f i ti sa w i n d o w sf o r ma p p l i c a t i o na n da p p l i e ds o a ps e c u r i t yi nf u n dt r a n s f e rm o d u l eo ft h i s p r o t o t y p e ，i m p l i e d t h e a p p l i c a t i o n o fs o a p s e c u r i t y t h ee x t e n d i n go fs o a pi ns e c u r i t yc a nm a k eu pf o rt h es h o r t c o m i n go fs o a p i n s e c u r i t ya n de n h a n c et h es e c u r i t yo fw e bs e r v i c e , w h i c hi sb a s e do ns o a p i tc a n a l s o m a k et h ee n t e r p r i s eh a v ec o n f i d e n c et oa c c e p tw e bs e r v i c e ，w h i c hi san e wd i s t r i b u t i n g 2 沈阳工业大学硕士学位论文 c o m p u t es o l u t i o n ，a n dh a v ei m p o r t a n tm e a n i n g f o ra p p l i c a t i o no fn e w t e c h n o l o g y k e yw o r d 8 ：s o a p , w e b s e r v i c e ，x m l ，x m ls i g n a t u r e ，x m le n c r y p t i o u 3 独创性说明 本人郑重声明：所呈交的论文是我个人在导师指导下进行的研究工 作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方 外，论文中不包含其他人已经发表或撰写的研究成果，也不包含为获得 沈阳工业大学或其他教育机构的学位或证书所使用过的材料。与我一同 工作的同志对本研究所做的任何贡献均已在论文中做了明确的说明并表 示了谢意。 签名：羔盗签日期：坦! 童叠蝈童9 关于论文使用授权的说明 本人完全了解沈阳上业大学有关保留、使用学位论文的规定，即： 学校有权保留送交论文的复印件，允许论文被查阅和借阅；学校可以公 布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保存论 文。 ( 保密的论文在解密后应遵循此规定) 签名：垒生笙导师签名：奎墨查窆日期：丝! 皇! 亟! 旦 沈阳工业大学硕卜学位论文 1 绪论 简单对象访问协议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 0 1 ) 是一种轻量级协议，用于 在分散型、分布式环境中交换结构化信息。s o a p 利用x m l 技术定义了种可扩展 的消息处理框架，它提供了种可通过多种底层协议进行交换的消息结构。这种框架 的设计思想是独立于任何一种特定的编程模型和其它特定实现的语义 1 l 。 s o a p 提供了一种简单的、可扩展的并且功能丰富的x m l 消息处理框架，用于 定义高级别的应用程序协议，从而在分布式异构环境中提供更高的互操作性。从底层 开始，s o a p 的设计目标就是使之成为种非常广泛的协议，自够以各种不同的方式 满足不同的需求。s o a p 具有简单、轻便并在业界获得广泛支持等优点。 s o a p 协议是w e bs e r v i c e 技术的核心。w e bs e r v i c e 是封装成单个实体并发布到 网络上以供其它应用程序使用的功能集合，它是可扩展标记语言( x m l ) 、简单对象访 问协议( s o a p ) 、w e bs e r v i c e 描述语言- ( w s d l ) 、通用描述、发现和集成( u d d o 的整 合技术例。w e bs e r v i c e 从本质上讲是放置于w e b 站点上的可重用构件，它可以分散 于w e b 上的各个地方，通过i n t e r n e t 进行相互调用，它是对象组件技术在i n t e r n e t 上 的延伸。 最近几年，随着w e bs e r v i c e 技术的不断成熟以及在电子商务等领域的不断发展， 其安全性越来越显得重要，作为w e bs e r v i c e 技术的核心，s o a p 协议的安全性承载 着w e bs e r v i c e 技术安全性的绝大部分责任。然而，s o a p 协议从设计之初并没有过 多考虑安全性，而是更多地注重于简单性、可扩展性和互操作性，这就为s o a p 协议 的安全性埋下了隐患。 本文通过详细研究s o a p 协议的原理、机制和特点，利用s o a p 协议的可扩展性 对其进行了安全性方面的扩展，并从机密性、完整性、身份认证和不可否认性等方面 对这种扩展进行了安全性论证。最后，讨论了s o a p 协议安全性的应用，通过设计实 现了一个基于w e bs e r v i c e 技术的采购系统原型，并将s o a p 协议的安全性应用在了 这个系统上，从而实现了s o a p 协议安全性的应用。 沈用t 业大学硕十学位论文 2s o a p 的深入理解 s o a p 提供了一种简单的、可扩展的并且功能丰富的x m l 消息处理框架，用于 定义高级别的应用程序协议，从而在分布式异构环境中提供更高的珏操作性。本章对 s o a p 的底层运作机制进行了深入的分析和探讨。 2 1s o a p 简介 s o a p 最初代表的是“简单对象访问协议”，如果在几年前问任何一个人s o a p 的含义，他们很可能这样回答“s o a p 是用来使d c o m 和c o r b a 在互联网上丁作”。 原作者们也承认，在那时他们注重于“访问对象”，但随着时间的推移，人们希望s o a p 能够处理更广泛的情况，因此，s o a p 规范的重心很快从对象转移到了通用的x m l 消息处理框架上。 这种重心的变化给s o a p 缩写中的“o ”带来了一点小问题。如今，在最新的s o a p 1 2 规范中其定义并不提及对象；s o a p 是一种轻量级协议，用于在分散型、分布式 环境中交换结构化信息。s o a p 利用x m l 技术定义一种可扩展的消息处理框架，它 提供了一种可通过多种底层协议进行交换的消息结构。这种框架的设计思想是独立于 任何种特定的编程模型和其它特定实现的语义1 3 1 。这个定义确实体现了s o a p 现在 的主旨。s o a p 定义了一种方法以便将x m l 消息从i n t e r n e t 上的一端传送到另一端， 如图2 1 所示。 任何通讯协议 s o a p 消息， 图2 1 简单s o a p 消息处理 s o a p 提供了一种基于x m l 且具有以下特性的消息处理框架：( 1 ) 简单性( 2 ) 可扩 沈阳工业人学硕上学位论文 展性( 3 ) 可通过多种底层网络协议使用( 4 ) 独立于编程模型。 ( 1 ) 简单性。s o a p 中的“s ”意味着“简单”。有时候，简单性比效率和纯技术更 重要，而互操作性成败的关键，就在于必须绝对要求简单性。简单性仍然是s o a p 协议的主要设计目标之一，这一点的例证就是s o a p 缺少分布式系统的很多特性，如 安全性、路由和可靠性等。 ( 2 ) 可扩展性。s o a p 定义了一种通信框架，允许以分层扩展的形式随着时间的推 移而加入某些特性。 ( 3 ) 可通过多种底层网络协议使用。s o a p 可在任何传输协议( 诸如t c p 、h t t p 、 s m t p 、m s m q ) 上使用2 ”，如上图2 i 所示。然而，为了保持互操作性，需要定义一 些标准协议绑定以便草拟用于每种环境的规则。s o a p 规范提供了一种用于定义在任 意协议上绑定的灵活框架，并且由于h t t p 的使用极为广泛，s o a p 现在已为h t t p 提供了一种显式绑定。 h ) 独立于编程模型。s o a p 允许任何编程模型，并且不依赖于r p ct ”。人们通常 会将s o a p 与对分布式对象进行的r p c 调用等效起来，因为s o a p 最初就是关于“访 问对象”的，但实际上，基本的s o a p 模型更接近于传统的消息处理系统，如m s m q 。 s o a p 定义了一种模型以便处理个别的单向消息，也可以将多条消息组合成一条整体 的消息，图2 1 说明了一种简单的单向消息，其中发送方不会收到响应。但是，接收 方也可以向发送方发回一条响应。s o a p 允许使用任何数量的消息交换模式。请求， 响应只是其中一种。其它示例包括要求响应( 与请求口向应相对) 、通知和长期运行的 点对点对话等。 请求消息 响应消息 图上2 请求响应消息交换模式 人们经常将请求响应与r p c 混为一谈，丽实际上两者之间的差别很大。r p c 使 沈四1t 业大学硕士学位论殳 用请求响应，但请求响应不+ 定就是r p c 。r p c 是一种方法调用的编程模型。r p c 需要将方法签名转换成s o a p 消息。鉴于r p c 的广泛应用，s o a p 草拟了一项协议， 以便将r p c 用于s o a p 。 具备了上述四个主要特征，s o a p 消息处理框架就促进了在异构环境中交换x m l 消息，而在这类环境中，互操作性长久以柬就是极大的挑战。 2 2s o a p 消息处理框架 s o a p 规范的核心部分就是消息处理框架。s o a p 消息处理框架定义了一整套 x m l 元素，用以“封装”任意x m l 消息以便在系统之间传输。 s o a p 消息处理框架包括以下核心x m l 元素：e n v e l o p e 、h e a d e r 、b o d y 和f a u l t ， 所有这些都来自s o a p1 1 中的h t t p ：s c h e m a s x m l s o a p o r g s o a p e n v e l o p e 命名空间”1 。 s o a p1 1 完整的x m l 架构定义见附录a 。 如果检查一下e n v e l o p e 的c o m p l e x t y p e 定义，很快就能了解这些元素之间是如何 关联的，如图2 3 所示。 图2 3s o a pe n v e l o p e 结构 e n v e l o p e 元素始终是s o a p 消息的根元素。这就便于应用程序识别s o a p 消息一 只要检查一下根元素的名称即可。通过检查e n v e l o p e 元素的命名空间，应用程序也 可以确定所使用的s o a p 版本。e n v e l o p e 元素包含一个可选的h e a d e r 元素，后跟一 沈阳工业大学硕上学位论文 个必要的b o d y 元素川。b o d y 元素代表了该消息的有效内容。它是一种通用容器，凶 为它可以包含来自任何命名空间的任意数量的元素。 例如，以下的s o a p 消息代表了一个在银行账户之间转账的请求： 2 2 3 4 2 4 3 9 9 8 2 8 3 4 4 3 1 0 0 0 0 如果接收方支持请求响应，且能够成功地处理该消息，它应向最初的发送方返回 另一条s o a p 消息。在这种情况下，响应信息也应包含在b o d y 元素中，如下例所示： 2 2 3 4 2 4 3 9 3 3 4 5 9 8 2 8 3 8 4 3 9 3 2 7 3 些塑三些查堂堡堂竺堕塞 s o a p 消息处理框架还定义了一个名为f a u l t 的元素，用丁二在发生错误时在b o d v 元素中表示错误。这是不可缺少的，因为如果没有一种标准的错误表示方法，每个 应用程序将不得不自己创建，从而使得通用基础结构不可能区分成功和失败。以下示 例s o a p 消息中包含了一个f a u l t 元素，指明在处理该请求时发生了“i n s u f f i c i e n t f u n d s ( 资金不足1 ”错误： s o a p ：s e r v e r i n s u f f i c i e n tf u n d s 2 2 3 4 2 4 3 9 1 0 0 0 0 8 9 2 3 f a u l t 元素必须包含一个f a u l t c o d e ，后跟个f a u l t s t r i n g 元素。f a u l t c o d e 元素使用 一种符合命名空间的名称对错误进行分类，而f a u l t s t r i n g 元素提供了一种对错误可读 的解释f 类似于h t t p 的工作方式) 。表2 1 简要地说明了s o a p l 1 所定义的各种错误 码( 所有这些代码都包含在h t t p ：s c h e m a s x m l s o a p o r g s o a p e n v e l o p e g 命名空间中) 。f a u l t 元素也可以包含一个d e t a i l 子元素，以便提供该错误的细节，这样可以帮助客户端诊 断问题，特别是在有c l i e n t 和s e r v e r 错误码的情况下。 沈1 ；1t 业大学硕上学位论文 表2 1s o a p i 1 所定义的各种错误码 名称含义 v e r s i o n m i s m a t c h 处理方发现s o a p e n v e l o p e 元素的命名空间造无效的。 m u s t u n d e r s t a n d 处理方没有理解或服从s o a ph e a d e r 元素的某个直接子元素，而该子元素 包含一个值为“1 ”的s o a pm u s t u n d e r s t a n d 属性。 c l i e l i tc l i e m 类的错误表明消息的格式错误或者不包含适当的信息，因而不能成 功。这通常表明，如果不对该消息作h | 更改，就不应该重发该消息。 s e r v e rs e r v e r 类的错误表明该消息未能得到处理的原因与消息的内容并没有直接 关系，而是跟该消息的处理有关。 现在，假设你想在初始的消息中增加些验证信息，以便接收方能够确定发送方 是否有足够的权限来执行传输。要达到这一目的，一种方法就是在主体中添加凭证信 息，如下所示： 2 2 3 4 2 4 3 9 9 8 2 8 3 8 4 3 l0 0 0 0 d a v e e v a d 如果使用这种方法，每项需要验证的操作都必须处理这些凭证。这也意味着其它 沈阳_ t 业大学硕士学位论文 需要安全性的应用程序必须丌发自己的解决方案解决这个问题；归根结底，这将损害 互操作性。对于诸如安全性等公共需要，定义各方都同意的标准s o a p 标头将更有意 义。然后，各厂商可以在其通用的s o a p 摹础结构中建立对扩展功能的支持，这样各 方皆赢。这种方法可以提高开发人员的生产力，同时有助于确保更高级的互操作性， 而这正是s o a p 扩展性模型设计要实现的甘标f 9 j 。 2 3s o a p 扩展性 大多数现有的协议都区分控制信息( 如标头) 和消息有效负载。在这方面，s o a p 也不例外。s o a ph e a d e r 和b o d y 元素在易于处理的x m l 世界中也进行同样的区分 l ”】。除了易用性之外，可扩展e n v e l o p e 的关键优势在于它可以使用任何通信协议。 在各种应用程序协议中( 如h t t p 、s m t p 等) 标头总是具有重要的意义，因为标头 允许联网两端的应用程序就所支持命令的具体行为进行协商“1 1 。尽管s o a p 规范本 身并不定义任何内置的标头，但标头将逐渐在s o a p 中扮演同等重要的角色。随着 s o a p 标头的标准化，开发人员能够更方便地定义丰富的应用程序协议，而不必每次 都重新开始。 与b o d y 元素类似，h e a d e r 元素是控制信息的通用容器。其中可包含来自任何命 名空问( 除s o a p 命名空间之外) 的任意数量的元素。放置在h e a d e r 元素中的各个元素 被称为标头块。如同其它协议一样，标头块中包含的信息应该能够影响有效负载的处 理。因此，这里j 下适于放置诸如凭证一类的元素，以帮助控制对操作的访问，也可以 利用一个名为m u s t u n d e r s t a n d 的全局s o a p 属性对标头块进行标注，以指明接收方 在处理该消息之前是否需要理解标头。 d a v e e v a d 鎏塑三些查堂堡生兰垡笙塞 2 2 - 3 4 2 4 3 9 9 8 2 8 3 8 4 3 1 0 0 0 0 如果某个标头块被标注为m u s t u n d e r s t a n d = “1 ”，而接收方未设计为支持给定的标 头，则不应处理该消息，而应该向发送方返回一条f a u l t ( 带有s o a p ：m u s t t m d e r s t a n d 状 态g q ) 。如果m u s t t m d e r s t a n d = “0 ”或者没有提供m u s t u n d e r s t a n d 属性，则接收方可 以忽略相应的标头块并继续进行处理。在整个s o a p 处理模块中，m u s t u n d e r s t a n d 属 性起着核心作用。 2 4s o a p 处理模型 s o a p 定义了一种处理模型，它大致规定了从s o a p 发送方传输到s o a p 接收方 的过程中对s o a p 消息的处理规则l 。图2 1 只是说明了最简单的s o a p 消息处理 方案，其中一个应用程序( s o a p 发送方) 向另一个应用程序( s o a p 接收方) 发送一条 s o a p 消息。 但是，处理模型允许使用一些更复杂的体系结构，如图2 4 所示，这类体系结构 中包含多个中间节点。中间节点位于最初的发送方和最终的接收方之阳j ，并截获 s o a p 消息。中间节点可同时作为s o a p 发送方和s o a p 接收方。中间节点使得有可 能设计一些有趣且灵活的网络体系结构，而这些网络体系结构能受到消息内容的影 响。s o a p 路由就是一个很好的示例，它很大程度上利用了s o a p 中间节点。 在处理消息时，s o a p 节点承担着一个或者多个角色( r o l e ) ，这些角色会影响如何 处理s o a p 标头。各个角色被赋予独特的名称( 以u r 的形式) ，以便在处理过程中能 些塑三些查兰堕主兰堡堡塞 够识别这些角色。当s o a p 节点接收到一条要处理的信息时，它首先必须确定要假定 哪些角色。它可以检查该s o a p 消息以帮助确定。 s 巍o a p 幢 矧激9 发送者i 十i ：。= ： 图2 4 高级s o a p 消息处理 一旦s o a p 节点确定了要扮演的角色，它最后必须处理针对其角色之一的所有必 要标头( 标记为m u s t u n d e r s t a n d = “1 ”os o a p 节点也可选择处理针对其角色之一的 任何可选标头( 标记为m u s t u n d e r s t a n d = “0 ”) 。 s o a p1 1 只定义了一个名为h t t p ：s e h e m a s x m l s o a p o r g s o a p a c t o r n e x t 的角色。 每个s o a p 节点都必须承担n e x t 角色。因此，当s o a p 消息到达任一给定的s o a p 节点时，该节点必须处理针对n e x t 角色的所有必要标头，它可以选择处理针对该n e x t 角色的可选标头。除n e x t 外，s o a p1 2 定义了另外一些角色，且应用程序也可以定 义自定义角色3 l 。 s o a p 标头通过全局a c t o r 属性( 在s o a p1 2 中该属性名为r o l e ) 来指定具体的角 色。如果不存在a c t o r 属性，则标头默认地指向最终的接收方。以下s o a p 消息说明 了如何使用a c t o r ： 凹i r 一鎏里三些奎兰堡生堂生堡苎 由于w s r p ：p a t h 标头被指定为n e x t 角色且被标记为必要的( r n u s t u n d e r s t a n d = t t l ”1 ， 因此接收到此消息的第一个s o a p 节点必须根据该标头块的规范来处理此消息。如果 s o a p 节点不理解针对其角色之一的某个必要的标头，则它必须产生一个带 s o a p ：m u s t u n d e r s t a n d 状态码的s o a p 错误，并停止处理。s o a pf a u l t 元素提供了 f a u l t a e t o r 子元素，以指定在消息路径中哪一个节点导致了该错误的发生。f a u l t a c t o r 属性的值是一个u r i ，用以标识导致该错误的s o a p 节点。 如果s o a p 节点成功地处理了一个标头，则它必须从消息中删除该标头。s o a p 节点町以再插入标头，但是这样做会改变合同方它现在处于当前节点与该标头所指 向的下- 个节点之间。如果s o a p 节点恰好是最终的接收方，则它还必须处理s o a p 主体。 2 5s o a p 协议绑定 由于s o a p 消息处理框架独立于底层协议，每个中问节点可以选择使用不同的通 信协议而不会影响s o a p 消息1 1 4 。然而。为了确保各种s o a p 应用程序和基础结构 之间高级别的互操作性，标准的协议绑定是必要的。 一种具体的协议绑定准确地定义了应该如何利用给定的协议来传输s o a p 消息， 详细定义了s o a p 如何适用于另一种协议的范围，该协议很可能具有自己的消息处理 框架以及多种标头。协议绑定实际所定义的内容很大程度上取决于该协议的功能和选 项。s o a p1 1 规范仅规范化了一种用于h t t p 的协议绑定( 由于h t t p 的广泛使用) 。 h t t p 协议绑定定义了在h t t p 上使用s o a p 的规则。s o a p 请求棚自应自然地映射到 了h t t p 请求删目应协议模型上。 h t t p 请求和响应消息的c o n t e n t - t y p e 标头都必须设为t e x t x m l ( 在s o a p1 2 中是 a p p l i c a t i o n s o a p + x m l ) 。对于请求消息，它必须使用p o s t 作为动词，而u r i 应浚识 别s o a p 处理器。s o a p 规范还定义了一个名为s o a p a c t i o n 的新h t l 甲标头，所有 s o a p h t t p 请求( 即使是空的) 都必须包含该标头。s o a p a c t i o n 标头旨在表明该消息 的意图。对于h r i p 响应，如果没有发生任何错误，它应该使用2 0 0 状态码，如果包 含s o a p 错误，则应使用5 0 0 。s o a p h t t p 绑定如图2 5 所示。 洗阳t 业大学硕士学位论文 2 6s o a p r p c 和编码 圈2 5s o a p h t t p 绑定 尽管s o a p 规范已f 1 渐远离对象，但它仍然定义了一种约定，以便利用上述的消 息处理框架来封装并交换r _ p c 调用1 15 1 。定义一种标准的方法将r p c 调用映射到 s o a p 消息，这使得运行时基础结构可以在方法调用和s o a p 消息之间自动转换，而 不用围绕w 曲s e r v i c e 平台重新设计代码。 要利用s o a p 进行方法调用，基础结构需要以下信息： ( 1 ) 终结点位置( u r a ) ( 2 ) 方法名称 ( 3 ) 参数名称值 ( 4 ) 可选的方法签名 ( 5 ) 可选的标头数据 这些信息可以通过多种方法来传输，包括类型库、1 d l 文件，或是w s d l 文件。 1 2 沈阳t 业大学顾+ 学位论文 s o a p r p c 绑定定义了如何在s o a p 主体中封装并表示这些信息。为此，r p c 绑定首 先定义如何将方法签名映射到简单的请求响应结构，然后将这些结构以x m l 的形式 进行编码。r p c 绑定规定将以一个按照方法命名的结构来模拟方法调用。该结构将 包含对应于每个【i n 】或i i n o u t 参数的一个访问器，访问器的名称与参数名相同，其次 序由消息签名确定。方法响应也将作为一个结构来建模。结构的名称无关紧要，尽管 约定是使用方法名后跟“r e s p o n s e ”( 例如，对于a d d 操作，方法响应名应该相应为 a d d r e s p o n s e ) 。响应结构包含一个用于返回值的访问容器( 其名称在s o a p1 1 中无关 紧要，但在s o a p1 2 中必须是r p c ：r e s u l t ) ，其后是针对每个 o u t 或 i n o u t 】参数的访问 器。 假设a d d 操作具有以下的c 社方法签名： d o u b l ea d d ( r e fd o u b l ex ，d o u b l ey ) 根据刚才所说的r p c 绑定规则，代表该方法调用的请求结构应如下建模： s t r u c ta d d d o u b l e x ： d o u b l e y ； ) 而响应结构如下： s t r u c ta d d r e s p o n s e d o u b l er e s u l t ； d o u b l ex ： 那么，应该如何将这些结构映射到x m l 呢? s o a p 规范定义了一组编码规则， 专门用于此用途。s o a p 编码规则大致阐述了如何将当今最常用的数据结构( 如结构 和数组) 映射到普通的x m l 格式。根据s o a p 编码规则，以上的请求结构映射到以下 x m l 消息( 这将放在s o a p 主体中) ： 沈阳工业大学硕十学位论文 3 3 4 4 且上述请求的响应信息将映射到以下x m l 消息( 这个消息将进入响应消息的主 体) ： 7 7 3 3 x m l 架构的相关工作刚刚开始，s o a p 编码规则既已建立。既然x m l 架构已经 完成，开发人员可以简单地提供文字的x m l 架构定义，从而准确指定应该如何以 x m l 来格式化请求响应消息。由于利用x m l 架构定义更易于获得互操作性，因此 大多数开发人员已经决定完全摒弃s o a p 编码规则。实际上，自s o a p1 2 起，s o a p 规范不再正式要求支持s o a p 编码规则。从现在起，最好避免使用s o a p 编码规则。 尽管s o a pr p c 绑定和编码规则为那些不愿意涉及诸如x m l 架构和w s d l 等的 应用程序提供了一个很好的s o a p 集成层，因为r p c 绑定和编码规则易于导致互操 作性方面的问题，它们基本上已经失宠于w e bs e r v i c e 社区。 2 7s o a p 类型 有两种基本类型的s o a p 消息处理：文档和r p c 。文档类型指出主体只是包含一 个x m l 文档，而发送方和接收方都必须遵循该文档的格式。另一方面，r p c 类型指 h j ：体中包含某个方法调用的x m l 表示，j 下如上节所示。 两种方法可用于确定如何将数据序列化到主体中：使用文字的x m l 架构定义和 使用s o a p 编码规则。利用前一种方法，架构定义逐字确定了主体的x m l 格式，不 具有二义性。然而，利用后一种方法，s o a p 处理器必须在运行时遍历各种s o a p 编 码规则以确定主体j e 确地序列化。很显然，这种方法更易于导致错误和互操作性方面 的问题。 最常见的情形是在使用文档类型时也使用文字架构定义( 称为文档文字) ，以及在 沈阳工业大学硕 学位论文 使用s o a p 编码规则时使用r p c 类型( 称为r p c 编c q ) 。文档编码和i p c 文字也是可能 的，但并不常见，也没有太大意义。大多数w e bs e r v i c e 平台都集中于文档文字类型， 将其作为发展的主要用例，而且是现今m i c r o s o f t a s p n e tw e b m e t h o d 框架的默认设 置。 一 些塑! 些查望堕主兰堡堡苎 3s o a p 协议的应用环境一w e bs e r v i c e 3 1w e b s e r v i c e 的产生及作用 2 0 年前，计算机世界是大型机的世界，很少有人可以接触或者使用计算机。如果 他们要使用计算机的话也要到附近最近的计算机中心。个人计算机，图形用户界面， 互联网，这三种创新技术改变了一切。随着h t m l 和h t t p 标准的使用和推广，越 来越多的用户开始利用互联网技术。网络，也成为今天商业、雇员与客户之间日常联 系的纽带。人们迫切地需要可以把p c 机、服务器、智能设备和基于互联网的设备等 无缝地连接起来。商业用户希望可以使用户不论用什么平台，什么软件，什么计算机 设备都可以共享他们的数据，集成他们的业务流程，进一步简化网上业务的复杂程度。 从多方面讲，目前的互联网仅仅是过去的大型机时代的一种镜像。它仍然是一个 以服务器为中心的计算模型。个人或者个人的业务上所需要的数据都已经集中在数据 库中，网页仅仅是这些数据的一个“镜像”，而不是数据本身，这将迫使开发人员从 屏幕上选取需要的信息再添加到自己的程序中，这就增加了一个现存的商业系统维护 和开发的成本。如果有一种方法，可以将数据与显示的格式分离出来，数据的表示也 与平台无关，那么更多的商业程序可以利用计算机自动完成。随着x m l 技术的成熟 以及h t t p 协议的广泛使用，一种新的可以建立互操作的分布式平台产生了，它就是 w e bs e r v i c e 。 w 曲s e r v i c e 一词，首先是由微软公司提出的。目前，不同的i t 厂商由于各自利 益的需要，对于w e bs e r v i c e 的定义各不相同。但其实表述的涵义是一样的，即w e b s e r v i c e 是建立可互操作的分布式应用程序的新平台1 1 6 1 。可以看出，w e bs e r v i c e 并不 是一种新的编程语言，它是一套标准，定义了应用程序如何在i n t e r a c t 上实现互操作 性“”。人们可以用任何喜欢的语言，在任何喜欢的平台上写w e bs e r v i c e ，只要他人 呵以通过w e bs e r v i c e 标准对这些s e r v i c e 进行查询和访问。 w e bs e r v i c e 是封装成单个实体并发布到网络上供其它程序使用的功能集合【l “。 w e bs e r v i c e 是用于创建开放分布式系统的构件，可以使公司和个人迅速且廉价地向 一查型三些查兰竺主兰篁笙茎 全世界提供其数据服务。最初的w e b s 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 b 上提供服务外，还可以使用w e bs e r v i c e 检查客户 的信用、收取货款，并与货运公司办理货运手续。 w e bs e r v i c e 是下一代分布式系统的核心，它具有如下特点： ( 1 ) 互操作性：w e bs e r v i c e 允许在不同平台上、以不同语言编写的各种程序以基 于标准的方式相互通信f l 。由于有了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 ) 这个所有 主要供应商都支持的薪标准协议，因而避免了在c o m a 、d c o m 和其它协议之间 转换的麻烦。还因为可以使用任何语言来编写w e bs e r v i c e ，因此开发者无需更改其 开发环境，就可生产和使用w 曲s e r v i c e 。 ( 2 ) 通用性：w e bs e r v i c e 使用h t t p 和x m l 进行通信。因此，任何支持这些技 术的设备都可以拥有和访问w e bs e r v i c e 。而目前，不同平台不同系统大都支持h r r p 和x m l ，这使得w e bs e r v i c e 实现了跨平台技术，而且企业也可以充分利用在这些技 术上所做的投资，因此，引入w e bs e r v i c e 与引入以前的技术相比，其成本要低得多。 并且通过h t t p 协议与w e bs