（计算机软件与理论专业论文）基于soa的soap消息交互安全机制的研究与实现.pdf

摘要 目前，s o a ( s 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 ，面向服务的构架) 和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 ，简单对象访问协议) 消息进行交互，现 有的s o a p 消息交互安全机制主要是基于传输层。但是传输层安全机制由于技术 上的局限性存在种种缺陷，这就需要建立面向服务的消息层s o a p 消息交互安全 机制。 本文主要研究面向服务的消息层s o a p 消息交互安全机制。首先，作者介绍 了s o a 、w e b 服务和s o a p 的相关技术，并在此基础上研究了传输层消息传递安 全机制，分析了它的缺陷，引出建立面向服务的消息层安全机制的必要性：接 着，又对目前基于w s * 标准的消息层w e b 服务安全体系结构进行研究，指出其弊 端，提出用在s o a p 消息中添加s o a pa c c o u n t 信息的方法以改进现有机制；然 后，设计与实现了一个在现有w 曲服务安全体系结构中添加s o a p a c c o u n t 处理模 块的新的消息交互安全机制，并说明了其工作流程；最后，用一个具体的实例验 证和分析了s o a p a c c o u n t 技术的可行性和执行性能。 关键字：s o a s o a pw e b 服务s 0 a pa c c o u n t 消息层安全机制 a b s t r a c t a tp r e s e n t ，t e c h n o l o g i e so fs 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 ) a n dw e bs e r v i c e s h a sb e e nw i d e l yu s e di ne n t e r p r i s e c l a s sc o m m e r c i a ld e v e l o p m e n t a n do n eo ft h ef o c u s p r o b l e m sw h i c hh i n d e rt h ed e v e l o p m e n ta n ds p r e a do fs o a a n dw e bs e r v i c e si sh o wt o g u a r a n t e et h es e c u r i t yo fm e s s a g ec o m m u n i c a t i o nb e t w e e nd i f f e r e n tw e bs e r v i c e s 溉6 s e r v i c e sc o m m u n i c a t ew i t he a c ho t h e rt h r o u g hs 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 ) m e s s a g e s n o w a d a y s ，t h es e c u r i t ym e c h a n i s m so fs o a pm e s s a g e se x c h a n g em o s t l y b a s e do nt r a n s p o r tl a y e r d u et ot e c h n i c a ll i m i t a t i o n s ，t h e r ea r ev a r i o u sd r a w b a c k si n t r a n s p o r tl a y e rm e c h a n i s m s s oi t n e e d st oe s t a b l i s has e r v i c e o r i e n t e ds e c u r i t y m e c h a n i s mo fs o a p m e s s a g ee x c h a n g eb a s e do nm e s s a g el e v e l t l l i sp a p e rm a i n l yf o c u s e so ns e r v i c e - o r i e n t e dm e s s a g el e v e ls e c u r i t ym e c h a n i s mo f s o a pm e s s a g ee x c h a n g e f i r s t l y , t h ea u t h o ri n t r o d u c e ss o m et e c h n i q u e sr e l a t e dt os o a ， w e bs e r v i c e sa n ds o a p , a n do nt h i sb a s i s ，s t u d i e so ns e c u r i t ym e c h a n i s mo fm e s s a g e e x c h a n g eb a s e do nt r a n s p o r tl a y e ra n da n a l y s e si t sd r a w b a c k s ，t h e nr a i s e st h en e c e s s i t y o fe s t a b l i s h i n gs e r v i c e - o r i e n t e dm e s s a g el e v e ls e c u r i t ym e c h a n i s mo fs o a pm e s s a g e e x c h a n g e s e c o n d l y s t u d i e so nc u r r e n tm e s s a g el e v e ls e c u r i t ya r c h i t e c t u r e o fw e b s e r v i c e sb a s e do nw s * s t a n d a r d sa n dp o i n t so u ti t sd e f e c t s ，t h e nam e t h o dt h a ta d d i n g a l ls o a pa c c o u n ti n f o r m a t i o nt os o a pm e s s a g ei sp r o p o s e dt oi m p r o v ec u r r e n t m e c h a n i s m t h e n ，t h ea u t h o rd e s i g n sa n di m p l e m e n t san e ws e c u r i t ym e c h a n i s mo f m e s s a g ee x c h a n g et h a ta d d i n gs o a pa c c o u n tp r o c e s s i n gm o d u l e st oe x i s t e ds e c u r i t y a r c h i t e c t u r eo fw e bs e r v i c e s ，a n de x p l a i n si t sw o r k f l o w f i n a l l y , f e a s i b i l i t ya n d e x e c u t i v ep e r f o r m a n c eo fs o a pa c c o u n tt e c h n i q u em e n t i o n e di nt h i sp a p e ri sv a l i d a t e d a n da n a l y z e db yac o n c r e t ee x p e r i m e n t k e y w o r d ：s o a s o a pw e bs e r v i c es o a pa e e o u n t m e s s a g el e v e ls e c u r i t ym e c h a n i s m 创新性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或 其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做 的任何贡献均已在论文中做了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：墼墨 日期塑盟：王j 3 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕 业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。 学校有权保留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全 部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。( 保密的论 文在解密后遵守此规定) 本学位论文属于保密在一年解密后适用本授权书。 本人签名：墼乐 导师签名：兰￥l 日期望塑：! ：芝 日期趔盘：! ：墨 第一章绪论 第一章绪论 1 1 研究背景 很久以来，“服务”一词频繁出现在商业计算领域中，并以多种方式使用着。 进入新世纪以来，“w e b 服务”变得炙手可热，有人用“w e b 服务”指代通过w e b 交 付给用户的应用服务，如流行的s a l e s f o r c e t o m 应用程序；也有人用“w e b 服务”指 代应用模块，其他应用程序可利用基于x m l 的协议，通过i n t e m e t 访问这些模 块。 面向服务的架构( s o a 1 】) 的提出，从技术角度，更正式、更准确地定义了“服 务”的概念。s o a 是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒 度应用组件进行分布式部署、组合和使用。服务层是s o a 的基础，可以直接被应 用调用，从而有效控制系统中与软件代理交互的人为依赖性。 s o a 的基础是w e b 服务( w e bs e r v i c e s 2 j ) 。然而，w e b 服务也引出了一系列 的新问题，其中，服务间通信的安全性问题是一个亟待解决的问题，因为它一定 程序地阻碍了s o a 技术及w e b 服务的推广。w e b 服务间主要通过s o a p 消息进行 通信。w e b 服务安全在面向传统的网络应用安全性的基础上又提出了一些新的安 全性需求。可从两方面理解w ，e b 服务的安全性需求： 一方面，w e b 服务安全不但应满足完整性、机密性、用户验证、授权、不可 否认性等网络应用安全的基本要求，而且要求满足一些额外条件： 互操作性。具有互操作性是w e b 服务安全策略的一个基本条件，因为数 据传输经常跨越多种平台进行，而它们的安全性在整个过程中都必须得 到保证。 端到端安全。在w e b 服务的交互过程中，s o a p 消息可能要经过一个或多 个中介体，并且在不同的传输阶段，一条s o a p 消息可能绑定于多种不同 的传输协议。因此，应保证s o a p 消息在整个传输过程的安全性，即端到 端的安全性。 选择性保护。即保护消息的部分内容。例如，在一个特定的x m l 文档 中，可以选择只对一个指定的x m l 文档元素进行加密，而文档的剩下部 分将保持原状。因为用于在请求方与提供方代理程序间通讯的s o a p 消息 可能要经过一个或多个中间节点，而中间节点可能有权限访问消息中的 某些信息，而无权访问其他信息。 另一方面，在w e b 服务体系结构中，服务提供方掌管着外界对w e b 服务的 2 基于s o a 的s o a p 消息交互安全机制的研究与实现 访问，是一切交互活动的核心。对外部而言，服务提供方必须为服务请求方提供 可进行信息存取的接口，并且基于分布式环境实现开放的、标准的商务逻辑；对 内部而言，为了便于创建、部署及管理w e b 服务，服务提供方需构建一个环境， 其中应包括一系列与w e b 服务存储、分发、调用以及基础管理相关的部件( 如系 统工具、安全基础设施等) ，用于容纳并管理w e b 服务，这个环境即w e b 服务平 台。因此，对于提高w e b 服务的安全性而言，保证服务提供方的数据安全是至关 重要的。 在本文中，我们主要研究如何保证s o a p 消息在传输过程中的安全性。 1 2 研究目标 本课题的研究目标是：基于对面向服务的软件体系架构和w e b 服务安全体系 结构的研究，提出一种面向服务的消息层s o a p 消息交互安全机制。并在此基础 上，研究和设计一个消息层s o a p 消息传输安全框架，以保证s o a p 消息的完整 性和机密性。 根据研究目标，本课题将主要解决如下问题： 1 如何将现有的基于x m l 的安全标准和技术与消息层安全性相结合； 2 分析现有的消息交互安全机制存在的各种缺陷； 3 如何对现有的存在缺陷的消息交互安全机制做出改进； 4 如何用基于面向服务的思想用改进后的技术设计新的消息层s o a p 消息交 互安全框架。 1 3 本课题的主要工作 本论文主要研究了消息层的s o a p 消息交互安全机制，该课题的主要工作如 下： 1 对面向服务架构的软件体系结构、w e b 服务以及s o a p 的相关技术进行了 研究，分析了现有w e b 服务传输层消息交互安全机制的缺陷，从而得出了研究新 的消息层交互安全机制的重要性。 2 对基于w s * 标准的现有消息层w e b 服务安全体系进行研究，分析了其在防 止针对s o a p 消息的篡改攻击方面存在的弊端。 3 提出了用以保存s o a p 消息的结构信息的s o a p a c c o u n t 信息这一概念，指 出可以用在s o a p 消息中添加s o a p a c c o u n t 信息的方法有效地检测针对s o a p 消 息的篡改攻击。 4 设计并实现了一个采用s o a pa c c o u n t 方法的消息层s o a p 消息交互安全框 第一章绪论 3 架，并详细阐述了用s o a p a c c o u n t 信息检测攻击的过程。 5 通过一个具体的实例验证和分析了本文设计的s o a p a c c o u n t 消息层安全机 制的可行性和执行性能。 1 4 本论文的章节安排 本论文共有六章，各章的主要内容如下： 第一章，绪论。首先介绍了s o a 和w e b 服务技术发展的基本情况，指出了保 证w e b 服务间消息交互安全的重要性。而w e b 服务间主要是通过s o a p 消息进行 通信，于是引出了本论文的研究目标研究和设计一个消息层s o a p 消息传输 安全框架；接着，介绍了作者在课题的研究过程中所做的主要工作；最后介绍了 本论文的章节安排。 第二章，面向服务架构( s o a ) 和s o a p 概述。首先，介绍了s o a 和w e b 服 务技术的概念和相关技术( u d d i 、s o a p 、w s d l ) ；然后，介绍了用于服务间通 信的s o a p 协议的相关概念。 第三章，s o a p 消息交互安全机制的研究。首先，介绍了s o a p 消息安全性要 求与安全的消息调用模式；接着，介绍了现有的传输层消息安全机制及其缺陷； 然后，引出建立面向服务的消息层安全机制的重要性以及目前技术上存在的弊 端；最后，提出用在s o a p 消息中添加s o a pa c c o u n t 信息的方法解决上述的问 题。 第四章，s o a pa c c o u n t 消息交互安全机制的设计。首先，设计并实现了在现 有的w r e b 服务安全体系中添加了s o a p a c c o u n t 信息处理模块的改进后的安全体系 结构；然后，详细说明了如何在s o a p 消息中添加s o a p a c c o u n t 信息以及如何用 s o a pa c c o u n t 信息检测x m l 篡改攻击；最后，分析了采用s o a pa c c o u n t 的优 势。 第五章，s o a pa c c o u n t 技术性能分析。本章通过一个具体的实例验证和分析 了s o a pa c c o u n t 实现技术的可行性和执行性能。首先，通过实例分析了s o a p a c c o u n t 实现技术检测x m l 篡改攻击的情况，验证了该技术的可行性；然后，将 本文的实现技术与现有的一种策略驱动w s 安全框架进行比较，分析了s o a p a c c o u n t 技术的执行效率。 第六章，结束语。总结本论文的研究工作，并对今后的研究工作进行了展 望。 第二章面向服务架构( s o a ) 和s o a p 概述 第二章面向服务架构( s o a ) 和s o a p 概述 2 1s o a 概述 2 1 1s 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 1 j ) 是指为了解决在i n t e m e t 环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软 件系统架构。s o a 是一个组件模型，它将应用程序的不同功能单元( 称为服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行 定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建 在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 对于面向同步和异步应用的，基于请求响应模式的分布式计算来说，s o a 是 一场革命。一个应用程序的业务逻辑或某些单独的功能被模块化并作为服务呈现 给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和 实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建 应用，而无须理解服务的底层实现。举例来说，一个服务可以用n e t 或j 2 e e 来 实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不 同。 2 1 2s o a 的组成 如图2 1 所示，s o a 包含三个角色：服务请求者( s e r v i c er e q u e s t e r ) 、服务提供 者( s e r v i c ep r o v i d e r ) 服务注册处( s e r v i c er e g i s t r y ) 。每个角色具体描述如下： 1 服务提供者负责创建服务描述，将服务描述发布到一个或者多个服务注册 处，并接收来自一个或者多个服务请求者的w e b 服务调用消息。 2 服务请求者负责查找发布在一个或者多个服务注册处的服务描述，并负责 利用服务描述，绑定或者调用由服务提供者提供的w e b 服务。w e b 服务的任何消 费者都可以被认为是服务请求者。服务请求者有时候也叫服务使用者、服务消费 者。 3 服务注册处。服务提供者可以在服务注册处发布服务描述，服务注册处负 责为其宣传，并允许服务请求者搜索服务注册处所包含的服务描述集合。服务注 册处的作用就是服务请求者和服务提供者之间的中介。一旦服务注册处完成了匹 配，它也就完成了任务，其余的交互也就是在服务请求者和服务提供者之间的直 6 基于s o a 的s o a p 消息交互安全机制的研究与实现 接服务调用。 图2 1s o a 的体系架构 s o a 也包含三个操作：发布( p u b l i s h ) 、发现( f i n d ) 和绑定调用( b i n d i n v o k e ) 这些操作定义了s o a 角色之间的约定关系： 1 发布操作是一种服务注册或者服务宣传的行为。它起着服务注册处与服 务提供者之间的连接作用。当服务提供者在服务注册处发布其w e b 服务描述后， 服务注册处就将此w e b 服务的细节通知给w e b 服务请求者。发布a p i 的实际细节 取决于服务注册处的实现。简单的发布是将服务描述发布到w e b 应用服务器的目 录结构中；复杂的发布操作则通过独立的单元来管理服务描述。 2 发现操作是获得w e b 服务的调用细节信息，起着服务注册处和服务请求 者之间的连接作用。在进行发现操作时，服务请求者向服务注册处发送如服务类 型、服务质量保证、安全验证等等。服务注册处根据查找条件在所发布的w e b 服 务描述集合中进行搜索，查找与查找标准匹配的服务描述。 3 绑定操作体现了服务请求者与服务提供者之间的“客户一服务器”关系。绑 定操作可以是十分复杂和动态的，如基于服务描述，动态生成客户方代理，用于 调用w e b 服务；也可以是静态模型，开发者对客户应用程序采取调用w e b 服务 的方式，进行手工编码。 2 1 3s o a 的优势 s o a 技术相对于传统的软件开发技术有以下的优势： 1 、松散耦合 松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性 以及高可用性而言，每个系统都可以实现独立管理。松散耦合给服务提供者和服 务请求者提供了独立性，但要求基于标准的接口和中间件来积极地管理和代理终 第二章面向服务架构( s o a ) 和s o a p 概述 端系统之间的请求。 2 、基于行业标准 行业标准是由技术领先的b e a ，i b m ，m i c r o s o f t ，s u n ，o r a c l e ，w 3 c 以及o a s i s 所认可的。s o a 由于其可以用基于标准的技术来实现，所以它被广泛接受。采用 行业标准就意味着互操作的简化与容易实现。 3 、协议无关性 通过底层的适配器可以完成消息在多种协议上的传输，以及在多种协议上的 协调管理。 4 、快速开发能力 通过w e b 服务组合可以快速的完成某项具体的业务操作：通过服务提供者与 服务请求者之间的无干扰的开发，可以使得两者之间并行开发。 2 2w e b 服务与基本s o a 2 2 1w e b 服务概念 w e b 服务是可通过标准的i n t e m e t 协议( 如h t t p ) 可编程访问的、自适应、自 描述的w e b 组件。简单来说，w e b 服务是松散耦合的、可重用的软件模块，它封 装了离散的功能，在i n t e m e t 上发布后能通过标准的i n t e m e t 协议( 如h t t p ) 在程序 中访问。w e b 服务具有以下的特征【3 j ： 1 模块化：保证了服务组件( c o m p o n e n t ) 的重用、组合； 2 可访问性：保证服务对于那些需要该服务的系统是可见的； 3 良好描述：服务通过一种机器能识别的服务描述来描述服务是什么类型以 及在什么地方； 4 实现独立：服务的接口与服务的实现完全隔离开来； 5 互操作：通过定义标准的数据传输协议来实现不同系统之间的互操作； 6 自治性：每个w e b 服务在其作用范围内完成某个特定的功能。w e b 服务之 间以提供的接口访问，通过w e b 服务的组合来完成更复杂的功能。 点： 2 2 2s o a 和w e b 服务的根本区别 很多开发人员都搞不清楚s o a 和w e b 服务的区别，因为它们有如下的共同 都提供服务。 服务接口都是基于开发的。 基于s o a 的s o a p 消息交互安全机制的研究与实现 服务接口和服务的具体实现都是分离的。 其实，w e b 服务是构建s o a 的核心组件，下面进一步从技术的角度来说明两 者的根本区别1 4 j 。 w e b 服务接口需要绑定具体实现服务的服务组件来实现服务，它对具体的服 务实现完成了封装，如图2 2 所示，实现了服务的透明化，客户端不需要知道服 务是如何实现的，但是w e b 服务组件本身是知道服务是如何实现的，另外客户端 调用w e b 服务组件时，需要知道w e b 服务的具体位置和传输协议，这些都会造成 一定的不灵活性，它只是实现了一定程度上的抽象。 图2 2w e bs e r v i c e 服务接口绑定服务实现组件 s o a 构架平台只和服务接口进行绑定，对服务接口实现了封装，如图2 3 所 示，实现了服务接口的透明化，服务位置的透明化，服务传输协议的透明化。 s o a 本身也不知道服务具体是如何实现的。当客户端通过s o a 调用服务时，不需 要知道真正的服务提供者是谁，具体的服务位置在哪里和具体的传输协议是什 么。s o a 实现了最高程度上的抽象化，为实现具有最高灵活性的服务建立了架构 基础。 图2 3s o a 架构平台和服务接口进行绑定 2 2 3u d d i 、w s d l 和s o a p u d d i ( u n i v e r s a ld e s c r i p t i o nd i s c o v e r ya n di n t e g r a t i o n ，统一描述、发现和集成 协议) 、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 服务描述语言) 和 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 ，简单对象访问协议) 是s o a 的基础部件。 w s d l 用来描述服务；u d d i 用来注册和查找服务；而s o a p ，作为传输层，用 来在消费者和服务提供者之间传送消息。s o a p 是w e b 服务的默认机制。一个消 费者可以在u d d i 注册表( r e g i s t r y ) 查找服务，取得服务的w s d l 描述，然后通 过s o a p 来调用服务。 u d d i 、w s d l 和s o a p 这三个结构单元也是构建w e b 服务的核心与基础，下 第二章面向服务架构( s o a ) 和s o a p 概述 9 面对这三个部分进行简单的介绍。 一u d d i u d d i 是一套基于w e b 的、分布式的、为w e b 服务提供信息注册的实现规 范，同时也包含一组使企业能将自身提供的w e b 服务注册以使得别的企业能够发 现的访问协议的实现规范。u d d i 建立了一个平台独立、开放的框架，通过因特 网来描述服务，发现业务，并且整合服务。 1 u d d i 基本概念 u d d i 规范【5 】 6 i ：u d d i 规范v l 版包括两个规范文本，u d d i 程序员a p i 规范 1 0 ( u d d ip r o g r a m m e r sa p iv 1 o ) 和u d d i 数据结构参考1 0 ( u d d id a t as t r u c t u r e r e f e r e n c ev 1 0 ) 前者定义了u d d i 操作站点能够支持的a p i 接1 3 ，而后者则描述 了在a p i 中具体x m l 描述的数据结构的定义。u d d i 规范是u d d i 操作站点的实 现蓝本，也是需要访问u d d i 注册中心的w e b 服务的参考规范。目前u d d i 己经 发展到v 3 版本，由最初的平行结构向层次性结构发展，并在进一步的发展中。 u d d i 注册中一l 、( u d d ir e g i s t r y ) ：u d d i 注册中心是所有提供公共u d d i 注册服 务的站点的通称。u d d i 注册中心是一个逻辑上的统一体，在物理上则是以分布 式系统的架构实施的，而不同站点之间采用数据同步机制来同步数据，因此访问 其中任意一个站点就基本等于访问了u d d i 注册中心( 数据同步可能有延迟) u d d i 注册中心可以是公用的商业注册中心，也可是私营的注册中心。 u d d i 注册中心操作站点，简称u d d i 操作站点( u d d io p e r a t o rs i t e ) ：u d d i 操 作站点是u d d i 注册中心中每一个对等结点，对于u d d i 操作站点的查询所获得 的结果是覆盖整个u d d i 注册中心中的信息的。操作站点用于查询与发布w e b 服 务。 2 u d d i 信息类型 u d d ix m ls c h e m a 7 】定义了四种主要信息类型，它们是技术人员在需要使用 合作伙伴所提供的w e b 服务时必须了解的技术信息，这些元素构成u d d i 信息结 构。它们是：业务实体( b u s i n e s s e n t r y ) 信息、业务服务( b u s i n e s s s e r v i c e ) 信息、绑定 模板( b i n d i n g t e m p l a t e ) 信息、技术规范( t m o d e l ) 信息。 3 u d d ia p i u d d i 规范提供了两个主要类型的a p i 操作：发布a p i 和查询a p i 。发布a p i 是一组需要进行认证的操作，实体可以使用这些操作在u d d i 注册处发布信息， 除了需要认证标识号( a u t h e n t i c a t i o n t o k e n ) 以及这类操作应使用的协议外，u d d i 并 没有指定认证方法；查询a p i 是一组不需要认证的公共操作，用户可以使用这些 操作从u d d i 注册处查询信息。查询的方式有两种：浏览方式和细节查找方式。浏 览方式用于查找一般信息( f i n d 操作) ；细节查找用于获取特定的细节信息 ( g e t操作)。detail 1 0 基于s o a 的s o a p 消息交互安全机制的研究与实现 与u d d i 的四个信息类型相对应。u d d i 提供了四个s a v e 操作、四个d e l e t e 操 作、四个f i n d 操作、四个g e t _ d e t a i l 操作。如表2 1 所示： 表2 1u d d i 规范定义的a p i b u s i n e s s s e r v i c e b i n d i n g t m o d e l ， s a v e：，s a v eb u s i n e s s s a v es e n ，i c es a v eb i n d i n gs a v et m o d e l d e l e t e d e l e t e _ b u s i n e s sd e l e t e s e r v i c e d e l e t eb i n d i n g d e l e t e t m o d e l f i n d f i n d b u s i n e s sf i n d s e r v i c e f i n db i n d i n gf i n dt m o d e l g e t d e t a i i g e t _ b u s i n e s s d e t a i lg e t _ s e r v i c e d e t a i lg e tb i n d i n g d e t a i lg e tt m o d e l d e t a i l 另外，规范提供了一个附加的g e t _ d e t a i l 操作，即g e t _ b u s i n e s s d e t a i l e x t ，用于 在实现了u d d i 扩展的非运营节点处检索扩充的商务信息；针对注册的安全性要 求，规范提供了g e t _ a u t h t o k e n 、d i s c a r d a u t h t o k e n 和g e t r e g i s t r e d l n f o 三个a p i 满足基于认证标识号的要求。 二、w s d l w s d l 是基于x m l 格式的文档，用于将w e b 服务描述为一组端点( e n d p o i n t ) ， 这些端点对包含面向文档的消息进行操作。它首先对操作和消息进行抽象描述， 然后将其绑定到具体的网络协议和消息格式上以定义端点。相关的具体端点组合 成为抽象端点( 服务) 。w s d l 是可扩展的，使得在通信时可以使用多样的消息格 式或网络协议。w s d l 文档在w e b 服务的定义中使用以下主要的元素【8 1 ： 1 p o r t t y p e ：p o r t t y p e 描述了w e b 服务的接口，它对w e b 服务完成什么功 能做最简洁的描述。 2 t y p e s ：t y p e s 元素包含与交换的消息相关的数据类型定义。 3 m e s s a g e ：代表所传输数据的抽象定义。 4 o p e r a t i o n ：对服务所支持的操作的抽象描述。 5 b i n d i n g ：为p o r t t y p e 所定义的操作和消息指定消息格式和协议细节。 6 p o r t ：p o r t ( 端口) 的目的是指定端点的网络地址，该端点是w e b 服务的宿主， 也就是说p o r t 元素把特定协议形式的地址联系到某个b i n d i n g 元素。w s d l 文档 中的所有p o r t 中，每个p o r t 的名称应该是唯一的。 7 s e r v i c e ：用于包含一组相关的p o r t 元素。 在w s d l 中，对w e b 服务的定义使用的元素可以分为两类，一类是服务接口 定义，定义了服务的调用接口、调用方式、传输协议等。包括t y p e s ，m e s s a g e ， p o r t t y p e ，b i n d i n g 。一类是服务实现定义，它对服务具体完成某项功能进行定义。 包含s e r v i c e 和p o r t 。这两个部分可以在w s d l 文件中合在一起，也可以分开部 署。 = 、s o a p 第二章面向服务架构( s o a ) 和s o a p 概述 l l s o a p 是一个基于y a v i l 的，在松散分布式环境中交换结构化信息的轻量级协 议，包括四个部分【9 】： 1 s o a p 信封： 2 s o a p 编码规则； 3 s o a pr p c 表示： 4 s o a p 绑定。 s o a p 的基本概念和相关技术将在本章下一部分中进行详细介绍。 2 3s o a p 概述 2 3 1s 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 用x m l 语言表示消息，一般用h t t p 作为传输协议。s o a p 以x m l 形式 提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型化信息的机 制。 2 3 2s o a p 消息结构 s o a p 消息是基于x m l 的，它具有统一的结构格式，根据s o a p 规范1 2 p j ， 其结构格式通常包含下列元素：信封( e n v e l o p e ) 、消息头( h e a d e r ) 、主体( b o d y ) 和附 件( a t t a c h m e n t ) 。其中，附件是可选的，即可带有o 到多个附件。e n v e l o p e 是 x m l 文档形式的s o a p 消息中的顶级元素；h e a d e r 则是在松散环境下在通信双方 之间尚未预先达成一致的情况下为s o a p 消息增加特性的通用机制；b o d y 定义了 很少的一些属性来指明谁可以处理以及它是可选处理还是强制处理，为该消息的 最终接收者想要得到的信息提供了一个容器。此外，s o a p 定义了f a u l t 用于报告 错误。图2 4 显示了一个带附件的s o a p 消息的结构。如图所示，s o a p 消息的信 封包含消息的消息头和主体，而附件则可使消息包含数据，且这些数据既可以是 x m l 数据，也可以是非x m l 数据( 如文本文件和二进制文件) 。 1 2 基于s o a 的s o a p 消息交互安全机制的研究与实现 图2 4 s o a p 消息结构图 2 3 3s o a p 规范 s o a p 规范【9 】主要由以下四部分组成： 1 s o a p 信封( e n v e l o p ) ：它构造定义了一个整体的s o a p 消息表示框架，可 用于表示消息中的内容是什么、是谁发送的、谁应当接受并处理它、以及这些处 理操作是可选的还是必须的等等。 2 s o a p 编码规贝, l j ( e n c o d i n gr u l e s ) ：定义了一个数据的编码机制，通过这样一 个编码机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程 序定义的数据类型所衍生的实例。例如可能应订单服务的需要，使用s o a p 编码 规则定义了订单的数据类型，并可以在订单生成的客户端与订单服务之间交换 订单实例。 3 s o a pr p c 表示( r p cr e p r e s e n t a t i o n ) ：定义了一个用于表示远端过程调用和 响应的约定，例如如何使用h t t p 或s m t p 协议与s o a p 绑定，如何传输过程调 用等。 4 s o a p 绑定( b i n d i n g ) ：定义了一个使用底层传输协议来完成在节点间交换 s o a p 消息的约定。 一、s o a p 信封 该信封是一个x m l 文档。信封包含了s o a p 消息头部( 可选) 和s o a p 消息 体( 必须) 。信封中的消息体部分总是存放最终接收到的消息的内容，而头部项 目可以确定执行中间处理的节点。附件、二进制数字及其他项目可以附加到消息 体上。图2 5 为s o a p 信封的结构图。而图2 6 是一个包含了s o a p 消息头部和 s o a p 消息体的s o a p 信封实例。 第二章面向服务架构( s o a ) 和s o a p 概述 1 3 图2 5s o a p 信封 图2 6 s o a p 信封实例 二、s o a p 编码规则 s o a p 规范中还定义了数据编码规则。s o a p 编码可以简短地描述成简单值或 者复合值的集合。简单值可以是简单类型，如整型、浮点型和字符型，或者是 x m l 架构规范中定义的内置类型，包括各种数据类型，如字节型数组和枚举。复 合值包括结构、数组和x m l 架构制定组定义的复杂类型。最后，s o a p 数据编码 指定了对象序列化规则，即通过网络排列和分散数据流的机制。 三、s o a p r p c 1 4 基于s o a 的s o a p 消息交互安全机制的研究与实现 s o a p 消息本质上是一种从发送方到接收方的单向传输，但是s o a p 经常组 合到实现请求响应机制中。其实设计s o a p 目的之一就是利用x m l 的扩展性和 灵活性来封装和交换r p c 。图2 7 和图2 8 表示的是s o a p 请求与响应信封。 s o a p 请求： s o a p 响应： 图2 7s o a p 请求信封图 图2 8s o a p 响应信封图 四、s o a p 绑定 目前s o a p 协议中定义了与h t t p 的绑定。利用h t t p 来传送s o a p 消息，主 要是利用h t t p 的请求响应消息模型，将s o a p 请求的参数放在h t t p 请求里， 将s o a p 响应的参数放在h t t p 响应里。当需要将s o a p 消息体包含在h t t p 消 息中时，h t t p 应用程序必须指明使用t c x t x m l 作为媒体类型。 尽管s o a p l 。0 规范强制要求使用h t t p 作为传输协议，但s o a p l 。1 之后的规 第二章面向服务架构( s o a ) 和s o a p 概述 1 5 范也允许使用f t p 、s m t p 作为传输协议。 2 3 4s o a p 消息交换模型 从本质上说，s o a p 消息交换是从发送方到接收方的一种传输方法，但是 s o a p 消息一般会和现实模式相结合，例如请求响应等【l o 】。 一、s o a p 节点 s o a p 节点既可以是s o a p 消息的发送者，也可以是s o a p 消息的接收者，也 可以是s o a p 消息发送者和接收者的s o a p 消息中介。s o a p 并不提供一个路由机 制，因此s o a p 需要识别发送者发送的s o a p 消息应当通过哪些s o a p 中介才能 到达接收者处。另外，接收到s o a p 消息的s o a p 节点必须能够实时处理并产生 必要的s o a p 错误和s o a p 响应，如果合适的话，还应当根据s o a p 规范的后续 描述生成额外的s o a p 消息。 当处理一个s o a p 消息的时候，s o a p 节点将被告知应当以一个或多个s o a p 处理角色来处理，这些s o a p 角色由s o a pa c t o r 名来标识。s o a pa c t o r 的内容是 一个u r i ，每个s o a p 节点都必须以一个指定的角色来处理s o a p 消息，这个角 色用命名为“h t t p ：w w w w 3 o r g 2 0 0 i 0 6 s o a p e n v e l o p e a c t o r n e x t