Web 服务体系结构及其规范简介

版本 2.0

2004 年 10 月

作者

Luis Felipe Cabrera
克里斯托弗·库尔特
Don Box

总结： 本 Web 服务体系结构简介介绍了 Web 服务的体系结构和基础技术的基础设计原则。描述功能并将其链接到正式定义这些功能的规范。本文还作为体系结构中所有规范的参考指南。 ) (51 页打印页

状态

本白皮书的内容反映了截至发布日期当前修订级别的各种 Web 服务规范的功能。随着 Web 服务规范的完善和更多规范的发布，本文将更新以反映最新的更改。

简介
   Message-Orientation
   协议可组合性
   自治服务
   托管透明度
   Protocol-Based集成
Web 服务体系结构
核心消息传送
   XML 和信息集
   SOAP
   消息交换模式
   传输独立性
   寻址
Metadata
安全性
   消息完整性和机密性
   基于安全令牌的信任
   安全会话
   安全政策
   系统联合
发现
   目录
   动态发现
协议协调协议 - 可靠的消息传送和事务
   可靠消息传递
   指定协调器
枚举、传输和事件
   枚举
   传输
   事件处理
管理
结束语
致谢
附录 A：术语表
附录 B：XML 信息集信息项
附录 C：常见安全攻击
附录 D：参考
   核心规范
   Web 服务规范
   互操作性配置文件
   其他资源

简介

Web 在实现互联网规模的简单计算机/人际交互方面取得了惊人的成功。事实证明，当今 Web 浏览器使用的原始 HTTP [HTTP] 和 HTML [HTML] 协议堆栈是将用户界面投影到各种设备上的经济高效方法。 HTTP 和 HTML 成功的一个关键因素是它们的相对简单性 - HTTP 和 HTML 都主要基于文本，可以使用各种操作系统和编程环境来实现。

Web 服务采用 Web 的许多想法和原则，并将其应用于计算机/计算机交互。与万维网一样，Web 服务使用共享通用体系结构的一组基础协议进行通信，这些协议将在各种独立开发和部署的系统中实现。与万维网一样，Web 服务协议在很大程度上要归功于基于文本的 Internet 传统，并且设计为在协议堆栈中尽可能干净地分层，而不会在协议堆栈中存在不当依赖项。

Web 服务不同于万维网的一个重要领域是范围。 HTTP 和 HTML 围绕对通常静态或至少高度可缓存的内容进行“读取-大部分”交互式浏览而设计。相比之下，Web 服务体系结构专为高度动态的程序到程序交互而设计。在 Web 服务体系结构中，可以实现多种分布式系统。示例包括同步和异步消息传递系统、分布式计算群集、移动网络系统、网格系统和对等环境。程序到程序交互中的广泛要求迫使 Web 服务协议堆栈比第一个 Web 协议更通用。但是，与 Web 一样，Web 服务依赖于少量特定的协议。稍后我们将更详细地讨论这些内容。

我们设想下一代主流应用程序将基于自治 Web 服务。自治的影响对体系结构至关重要，本文将对此进行探讨。本文的技术内容介绍了定义 Web 服务体系结构的基础结构协议，以及构建自治分布式应用程序所需的关键概念，即协定的概念。

驱动 Web 服务体系结构协议设计和实现的核心原则如下：

消息方向 - 仅使用消息在服务之间进行通信，并意识到消息的生存期通常超出了给定的传输事件。
协议可组合性 - 通过使用基础结构协议构建基块（几乎可以在任何组合中使用）来避免整体式。
自治服务 - 允许独立构建、部署、管理、版本控制和保护终结点。
托管透明度 - 控制终结点的哪些方面 (且对外部服务不) 可见。
基于协议的集成 - 将跨应用程序耦合限制为仅连接项目。

本部分的其余部分详细介绍了这些原则。

Message-Orientation

Web 服务使用消息进行通信。它们重点强调各个消息的形成和处理方式。与消息严格从属于本地编程体验的 RPC 系统不同，Web 服务体系结构是使用消息作为通信的原子单元构建的。这不仅适用于用于消息交换 (SOAP [SOAP]) 的线路格式，还适用于给定 Web 服务 (WSDL [WSDL]) 的说明。允许，一些开发人员可以选择使用远程过程调用隐喻查看 Web 服务;但是，此决定是该开发人员的代码本地的，在网络上不可见。

Web 服务假定 SOAP 作为协议堆栈中的最低层，并将消息传输与传输详细信息隔离开来。理想情况下，特定于协议的绑定不会泄漏到应用程序语义中。此方法为在开发平台之间实现服务互操作性提供了良好的基础，并提供更丰富的通信模式。 Web 服务通常依赖于 HTTP 作为基础消息传输。通过利用 HTTP POST 的开放扩展性，许多 Web 服务都已使用现成的 Web 技术启动。随着 Web 服务更复杂应用程序的出现，其他传输的重要性也越来越明显。例如，在 HTTP 的严格请求/回复规则下实现全双工消息交换是繁琐的。相比之下，使用轻型成帧协议通过 TCP [TCPIP] 发送 SOAP 消息允许轻松实现任何两方消息交换模式。

Web 服务可能会跨多个网络节点分发给定消息的处理，每个节点都提供一些功能，例如访问检查、基于内容的路由或特定于应用程序的验证。此分布式处理模型意味着给定消息可能需要在到达最终接收方之前遍历两个或多个消息传输。因此，Web 服务中的早期协议工作大部分侧重于通过任意传输提供端到端安全可靠的消息传送。对于单个信任域中最简单的部署，其中提供安全可靠的传输 (例如 TCP 或 HTTP) 上的 TLS [TLS]，WS-Security [WS-Security] 或 WS-ReliableMessaging [WS-RM] 等更可靠的协议是可选的。对于更丰富的部署，这些后一种协议至关重要。

协议可组合性

当协议可以独立使用或组合使用时，据说协议会组成。许多特定于域的通信协议实际上是“孤岛”，其中协议设计人员发现自己创造了处理安全性、可靠性、错误报告等的新机制。鉴于 Web 服务的广泛适用性，这种定义每个垂直域的整个协议的方法在域重叠时会中断，而且在初始开发和持续支持成本方面都变得非常昂贵。

为了避免这些成本，Web 服务协议套件设计为一系列可组合的协议构建基块。根据设计，每个基础结构协议都定义了一个精细的功能单元。例如，对消息内容进行签名和密封的基础知识非常通用，一旦在 WS-Security) 中 (指定，然后由各种基础结构协议和应用程序级协议利用。

Web 服务协议组合基于 SOAP 的模块化体系结构。 SOAP 的体系结构通过使用灵活的标头机制来预测基础结构协议的组成。此方法的一个优点是，特定应用程序的协议外围应用基于该应用程序使用的实际功能。给定的协议不会对不使用它的应用程序施加任何成本。在各种规模的计算设备上运行的软件可以使用所需的确切协议，从而最大程度地提高体系结构的适用性。第二个优点是可以随时引入新协议，以补充现有协议并扩展功能。因此，创新能力内置于体系结构中。获取可用协议范围的一致和全面视图的挑战是真实的。解决此挑战是本文档的目标。

提供规范配置文件以定义使用约束，以及以各种组合使用这些规范的最佳做法。有关特定配置文件的详细信息，请参阅互操作性配置文件、WS-I 基本安全配置文件和 Web 服务设备配置文件部分。

自治服务

Web 服务是自治代理，其开发、部署、操作、管理和安全性都独立于服务的使用者。这种“被迫独立”在体系结构中渗透了几个重要影响。

服务自治对版本控制实现方式具有深远的影响。随着服务实现的发展，兼容的使用应用程序范围的变化是不可避免的。拥有用于管理这些更改的合理工具对于正确运行基于 Web 服务的系统至关重要。在最基本的级别，SOAP 提供基于 SOAP 标头的协议演变模型。在给定协议的生存期内，SOAP 标头应添加到给定消息格式或将其删除。引入新标头时，在标头本身中携带升级策略。可以安全忽略的标头只是插入到消息中。无法安全忽略的标头使用 mustUnderstand 属性进行批注，指示其插入是中断性变更，并且只有识别标头的收件人才能处理邮件。扩展性的基本模型在 SOAP 本身中最为明显：但是，它镜像在各种其他 Web 服务协议中，包括 WSDL。更重要的是，Web 服务使用此原则将新的协议功能 (例如安全) 添加到单个消息传送格式 (SOAP) 。最终，SOAP 的主要功能是扩展性 - 每个新协议要求都不需要新版本的 SOAP。

服务的自治性质还要求更加强调应用程序之间的显式信任管理。由于许多服务的网络地址可从公共 Internet 中可见，因此需要更加谨慎，以确保恶意代理不会损害服务的完整性。这种谨慎的一部分采用更强大的输入验证的形式，通常可以使用各种架构语言自动执行。这种更加关注系统完整性的一个更有趣的方面是使用显式信任模型。基于 WS-Security 的系统的主要功能是给定的消息可能包含多个安全令牌。其中一些令牌可能对应于用户标识或主体。其他令牌可能对应于授予特定用户或应用程序的权限，并且可以作为更广泛的授权方案的一部分进行加密验证。

自治服务还必须保持对所管理资源的控制。具体而言，他们需要回收由不再交互的服务请求创建的资源。各种资源都需要资源回收策略。一种常用的方案是使用租约，如订阅在本文后面的事件通知中所示。异步消息传送允许服务对消息处理的计划进行完全的本地控制。服务在消息传输、连接管理和独立故障模式方面也具有灵活性。

最后，Web 服务的自治性质总是需要一次集中的进程或系统才能迁移到联合模型。这不仅适用于安全标识，也适用于服务目录和系统管理。这些新系统必须能够在存在无限制的消息延迟、独立的故障模式以及服务间歇性连接到网络时正常运行。

托管透明度

所有实现详细信息都专用于服务。每个服务公开的面向消息的外观与特定服务开发人员做出的实现选择提供了足够的隔离。这种不透明性对于服务自主性至关重要，并允许灵活地编程模型、操作系统和其他实现细节。它还允许将一个服务实现替换为另一个服务实现。理想情况下，只要两个服务都响应具有相同结果的同一组请求消息，请求者就不认为使用了服务的不同实现。

鉴于强调自治服务，Web 服务非常强调特定于实现的信息的透明度，这有点具有讽刺意想。例如，如果服务完全不透明，则无法判断服务 A 接受的输入消息集是否与服务 B 接受的输入消息集相似或不同。因此，服务应使其公开可见的方面对外部世界透明。这种透明度通过使用协定、服务发送或接收的消息的计算机可读说明以及服务的抽象功能和要求来实现。

公共服务说明对于为工具和执行环境创建丰富的生态系统至关重要，在实现异类系统之间的互操作性方面发挥着重要作用。开发工具依赖于服务说明，以便为服务接受或发送的消息创建程序员友好的语言绑定。部署工具依赖于服务说明将已部署的服务连接到一个或多个公开可见的终结点地址。管理工具依赖于服务说明来跟踪给定服务是否在其预期的输入和输出消息集合中运行。最后，请求方对给定服务的运行时绑定可以利用服务说明来确保在应用程序的正常执行过程中选择兼容的服务。

托管透明度不仅适用于服务的说明，也适用于消息本身。与过去的整体协议不同，SOAP 和WS-Security共同提供了一个灵活的安全层，其中消息的不同部分可能具有不同的安全特征。这意味着发送方可以选择让邮件的某些方面对所有潜在读者完全透明且可见，同时加密邮件的其他部分，以便只有一组受信任的读者才能看到。一般情况下，每个消息部分可以加密一组不同的读取者。可以对未加密的消息部分进行签名，以防止它们被篡改。

Protocol-Based集成

当基于消息的协议用于所有通信时，应用程序集成将得到简化。通过构建一个没有编程语言或操作系统详细信息的描述和消息传送的自包含系统，Web 服务已经表明，在真正不同的环境中运行的应用程序可以安全可靠地进行通信。唯一的方法是假设没有共享的 OS、共享的虚拟机，也没有共享的编程语言或抽象。独立于基础实现技术是 Web 服务互操作性的关键。 Web 服务对软件开发的许多方面都产生了影响。 Web 服务的主要贡献是强调基于协议的软件集成。

基于协议的集成对整个行业的影响可见于越来越重视面向服务的体系结构。 Web 服务和面向服务在很大程度上都归功于组件软件、分布式对象和面向消息的中间件。从对象方向采用了信息封装和多态性，组件软件中采用了接口的强制使用和运行时元数据的使用。分布式对象提供在实体和基于代理的绑定之间流动的上下文概念。当然，面向消息的中间件带来了队列、中继的使用。和显式消息传递。

Web 服务使用基于通用体系结构（以 SOAP 为基础）的一组具体协议进行通信。相比之下，服务导向是一组抽象的想法和概念，可以在) 之前以任何方式 (非常类似于面向对象。

Web 服务可用于实现面向服务的系统，但面向服务不需要使用 Web 服务协议，也不使用 Web 服务协议可确保整个系统设计面向服务。也就是说，Microsoft 正在投入巨资，使 Web 服务和面向服务的组合成为 Windows 的重要组成部分。

由于几个基本因素，面向服务的体系结构的广泛采用正在加速。网络基础结构现已普及，可实现经济高效的计算机到计算机通信。通过 Web 服务构建的系统提供了一种软件开发方法，使旧版应用程序能够合并到增量步骤中。最后，服务自治提供了更可靠的应用程序。

此简介介绍了指导 Web 服务体系结构的main推动因素、激励因素、要求和原则。本文的其余部分介绍了体系结构的基础核心技术，然后介绍了定义 Web 服务的规范集合。

Web 服务体系结构

本文的其余部分详细介绍了 Web 服务体系结构。我们回顾了它们构建的 Web 服务组件和机制，以支持体系结构的设计。体系结构的每个功能都显示在定义它的规范的上下文中。

核心消息传送

本部分介绍用于在 Web 服务体系结构中构建消息的核心规范：XML、SOAP 和 WS-Addressing [WS-Addressing]。 Web 服务依赖于 XML 的基本基础数据模型，SOAP 用于消息处理和数据模型，WS-Addressing用于寻址服务和标识独立于传输的消息。

XML 和 Infoset

对于所有消息传送系统，选择信息传输单元是一个重要决定。简单地说，需要对消息的构成内容有一个共同的了解。在 Web 服务中，消息是由 XML 信息集或 Infoset [XML-Infoset] 定义的 XML 文档信息项。 Infoset 是一个抽象数据模型，与基于文本的 XML 1.0 [XML-10] 兼容，是所有现代 XML 规范的基础， (XML 架构 [XML-Schema]、XML 查询 [XML-Query] 和 XSLT 2.0 [XSLT-20]) 。通过将 Web 服务体系结构基于 XML 信息集而不是特定的表示格式，体系结构和核心协议组件与替代编码兼容。

Infoset 根据一组“信息项”为 XML 文档建模。一组可能的信息项通常映射到 XML 文档中的各种功能，例如元素、属性、命名空间和注释。每个信息项都有一组关联的属性，这些属性提供项的更完整说明。附录 B 中介绍了 XML 文档中的 11 种信息项。每个格式正确的 XML 文档只包含一个文档信息项和至少一个元素信息项。

除了 Infoset 的纯基于文本的编码外，Web 服务体系结构还支持 Infoset 编码，该编码允许不透明二进制数据与传统的基于文本的标记交错。 W3C XML 二进制优化打包 (或 XOP [XOP]) 格式使用多部分 MIME [MIME] 允许将原始二进制数据包含在 XML 1.0 文档中，而无需采用 base64 编码。配套规范 SOAP 消息传输优化方法或 MTOM [MTOM]，然后指定如何将此格式绑定到 SOAP。 XOP 和 MTOM 是将原始二进制文件与基于文本的 XML 混合使用的首选方法，并将现已弃用的 SOAP 替换为附件 (SwA) 和 WS-Attachments/DIME。

SOAP

SOAP 提供了一种简单而轻量的机制，用于在使用 XML 的分散式分布式环境中的对等方之间交换结构化和类型化信息。 SOAP 旨在尽可能降低集成在不同平台上构建的应用程序的工程成本，前提是成本最低的技术很有可能获得普遍接受。 SOAP 消息是包含三个元素的 XML 文档信息项： <Envelope>、 <Header> 和 <Body>。

Envelope 是 SOAP 消息的根元素，包含可选的 Header 元素和必需的 Body 元素。 Header 元素是一种通用机制，用于以分散的方式向 SOAP 消息添加功能。 Header 的每个子元素称为标头块，SOAP 定义了几个已知属性，这些属性可用于指示谁应处理标头块 (角色) ，以及处理该标头是可选还是强制 (必须了解) ，如下所述。如果存在，Header 元素始终是 Envelope 的第一个子元素。 Body 元素始终是 Envelope 的最后一个子元素，并且是“有效负载”的容器，用于邮件的最终接收者。 SOAP 本身没有定义内置标头块，并且只定义一个有效负载，这是用于报告错误的 Fault 元素。

所有 Web 服务消息都是充分利用 XML Infoset 的 SOAP 消息。消息有效负载和协议标头采用同一模型这一事实可用于确保基础结构标头和应用程序正文的完整性。应用程序可以根据标头的内容和消息内的数据来路由消息。为 XML 数据模型开发的工具可用于检查和构造完整的消息。这些优势在 DCOM、CORBA 和 RMI 等体系结构中不可用，其中协议标头对应用程序而言基础结构详细信息不透明。

SOAP 消息从发送方单向传输到接收方。可以将多个单向消息组合成更复杂的模式。例如，常用的模式是消息的同步请求/响应对。

发送或接收消息的任何软件代理称为 SOAP 节点。执行消息初始传输的节点称为原始发送方。使用和处理消息的最终节点称为最终接收方。处理原始发送方和最终接收方之间的消息的任何节点称为中间方。中介用于为单个消息的分布式处理建模。消息和最终接收方遍历的中间节点集合统称为消息路径。

为了允许识别消息路径的某些部分，每个节点都参与一个或多个角色。 SOAP 角色是一种分类方案，它将基于 URI 的 [RFC1630] 名称与抽象功能 (（例如缓存、验证、授权) ）相关联。基本 SOAP 规范定义了两个内置角色：Next 和 UltimateReceiver。 Next 是一个通用角色，即发送方以外的每个 SOAP 节点都属于“下一个”角色。 UltimateReceiver 是消息路径中的终端节点所扮演的角色。这通常是代表应用程序执行工作的应用程序，或在某些情况下，是代表应用程序执行工作的基础结构。

SOAP 信封的正文始终以最终接收方为目标。相比之下，SOAP 标头可能针对中介或最终接收方。为了提供用于处理消息的安全且可版本控制的模型，SOAP 定义了三个属性，用于控制中介和最终接收方如何处理给定标头块-角色、中继和 mustUnderstand。角色属性用于标识标头块的目标节点。 mustUnderstand 属性指示如果未识别该节点，该节点是否可以忽略标头块。标记为 mustUnderstand=“true” 的标头块称为强制标头块。标记为 mustUnderstand=“false” 或没有 mustUnderstand 属性的标头块称为可选标头块。中继属性指示该节点是应转发无法识别的可选标头还是放弃它们。

每个 SOAP 节点都必须使用这三个属性来实现 SOAP 处理模型。以下步骤定义该模型：

使用角色属性标识用于当前 SOAP 节点的 SOAP 消息的所有标头块， (缺少此属性意味着标头块用于最终接收方) 。
验证步骤 1 中标识的所有必需标头块是否可以由当前 SOAP 节点使用 SOAP mustUnderstand 属性进行处理。如果当前 SOAP 节点无法处理必需的标头块，则必须放弃该消息，并且必须生成可分辨的错误消息。
处理消息。可选的消息元素可能会被忽略。
如果 SOAP 节点不是消息的最终接收方，则会删除步骤 1 中标识的所有不可中继标头块，然后将消息中继到消息路径中的下一个 SOAP 节点。 SOAP 节点可以自由地将新的标头块插入到中继消息中。其中一些标头块可能是步骤 1 中标识的标头块的副本。

SOAP 处理模型旨在允许扩展性和版本控制。 mustUnderstand 属性控制引入新标头块是中断性变更还是非中断性变更。添加可选标头块 (例如，标记为 mustUnderstand=“false”) 的标头是非中断性变更，因为任何 SOAP 节点都可以随时忽略它。添加强制标头块 (例如，标记为 mustUnderstand=“true”) 的标头是一项中断性变更，因为只有知道标头块的语法和语义的 SOAP 节点才能处理消息。角色和中继属性使用 mustUnderstand 组合，以沿消息路径分布此处理模型。

消息交换模式

SOAP 提供的消息传送灵活性允许服务使用各种消息交换模式进行通信，从而满足分布式应用程序的要求。我们在体系结构的核心构建基块中利用了其中几个。事实证明，多种模式在分布式系统中特别有用。例如，远程过程调用的使用普及了同步请求/响应消息交换模式。当消息传送延迟不受控制时，需要异步消息传送。使用异步请求/响应模式时，显式消息关联变得是必需的。

广播传输普及了一对多消息传输。原始发送方通过仅发送收件人来将其消息强加于收件人，称为推送模型。虽然此模型在局域网中有效，但它不能很好地扩展到广域网，也不会为接收方提供调节消息流的选项。

另一个有用的模式是基于应用程序能够表达对特定类型消息的兴趣，使发布/订阅模式非常流行。通过显式订阅消息源 (或主题) ，应用程序可以更可控地控制相关信息流。

当接收方显式请求来自源的消息时，将使用拉取模型。这使得消息流成为收件人的责任。拉取模式还可以与发布/订阅结合使用。它非常适合接收者可能间歇性地与源断开连接的情况。

传输独立性

SOAP 独立于使用中的基础消息传送传输机制进行定义。它允许使用许多替代传输进行消息交换，并允许同步和异步消息传输和处理。

需要多个传输和异步消息传送的系统示例之一是在基于陆地的高速网络主干上的 Web 服务与移动电话上托管的间歇性连接 Web 服务之间进行通信的系统。此类系统要求单个消息在不同的传输中传输，具体取决于消息在哪个网络跃点之间移动。此类系统还显示了无法准确确定消息传递延迟的一个示例。 Web 服务开发人员不应尝试确定或限制消息传递延迟，而应构建系统，假定异步消息传递的全部功能。与使用远程过程调用不同，异步消息传送允许发送方在每次消息传输后继续处理，而无需强制阻止并等待响应。当然，同步请求-响应模式可以在异步消息传送的基础上构建。

由于 Web 服务协议设计为完全独立于基础传输，因此选择适当的机制可以推迟到运行时。这使 Web 服务应用程序能够灵活地在发送消息时确定适当的传输。此外，当消息在节点之间路由时，基础传输可能会更改，同样，为每个跃点选择的机制可能会根据需要变化。

尽管具有一般传输独立性，但大多数第一代 Web 服务都使用 HTTP 进行通信，因为这是 SOAP 规范中包含的主要绑定之一。 HTTP 使用 TCP 作为其基础传输协议。但是，TCP 的设计引入了处理开销，这并不总是必要的。几种应用程序协议模式更匹配用户数据报协议或 UDP [UDP] 的语义。这些模式对于设备和其他资源受限的系统特别有用。

UDP 没有 TCP 的传递保证;它提供尽最大努力的数据报消息传送。实现它所需的资源也比 TCP 少。此外，UDP 提供多强制转换功能，允许发送方同时将消息传输到多个收件人。将 SOAP 消息绑定到 UDP 的规范在 SOAP-over-UDP [SOAP-UDP] 中发布。

寻址

对于在此多传输世界中路由和寻址的消息，需要一种通用机制，以便在多个传输中传递关键消息属性。 WS-Addressing规范为此定义了三组 SOAP 标头块。

Action 标头块用于指示消息的预期处理。此标头块包含一个 URI，最终收件人通常使用该 URI 来调度消息进行处理。

MessageID 和 RelatesTo 标头块用于标识和关联消息。 MessageID 和 RelatesTo 标头使用简单的 URI 来唯一标识消息，通常这些 URI 是暂时性的 UUID。

To/ReplyTo/FaultTo 标头块用于标识要处理消息及其答复的代理。这些标头依赖于名为终结点引用的 WS-Addressing 定义的结构，该结构将正确处理 SOAP 消息所需的信息捆绑在一起。

终结点引用是 WS 寻址的最重要方面，因为它们支持更精细的寻址，而不仅仅是 URI。它们在整个 Web 服务体系结构中广泛使用。终结点引用包含三个关键信息：基址，以及可选的引用属性和引用参数集。基址是用于标识终结点的 URI，显示在针对该终结点的每个 SOAP 消息的 To 标头块中。引用属性和引用参数是任意 XML 元素的集合，用于通过为消息提供额外的路由或处理信息来补充基址。它们表示为文本标头元素。使用终结点引用为终结点构造消息时，发送方负责将所有引用属性和引用参数作为标头块包含。

引用属性和引用参数之间的区别在于它们与服务元数据的关系。 Web 服务的策略和协定仅基于其基址和引用属性。通常，基址和引用属性标识给定的已部署服务，引用参数用于标识该服务管理的特定资源。

引用属性和参数只是不透明的 XML 元素，预期仅由最终接收方处理。它们有助于确保可用于调度、路由、索引编制或其他发送方处理活动的信息包含在给定的消息中。虽然预计中介不会处理此信息，但某些中介（例如防火墙或网关服务）可能会使用某些参考属性或参数进行消息路由和/或处理。

引用属性有许多用途。两个简单的示例是服务类和专用实体标识符。在服务类示例中，参考属性可用于区分标准客户的 Web 服务和“黄金”客户的 Web 服务，这些服务提供更高质量的服务和增强的功能（可能通过额外的操作或附加绑定），从而在逻辑上形成两个不同的终结点。此类属性仅在会话中设置一次，然后在交互的其余部分重复使用。引用属性的第二种用法的一个示例是一种机制，用于以原始系统专用的方式标识客户。结合使用这两种类型的引用属性，可以有效地将消息调度到适当的服务器集合，并有效地查找与特定用户相关的应用程序状态。这些示例还演示了如何在引用属性中表示引用服务实例的数据和引用用户实例的数据。

具体而言，引用属性还有助于对共享通用 URL 和范围的 WSDL 实体集合进行寻址。 WSDL 是一种 XML 格式，用于将 Web 服务描述为对消息操作的一组终结点，它首先抽象地指定其实体，然后将其具体绑定到特定实例。具体而言，消息和操作是抽象定义的，然后绑定到具有网络传输和消息格式信息的终结点。因此，从 WSDL 的角度来看，当以不同的具体实体（如输入或输出消息、portType 绑定、端口或使用通用 URL 的 Web 服务中的服务）为目标时，相应的终结点引用的引用属性应有所不同。元数据部分更详细地介绍了 WSDL。

参考参数的两个使用示例是基础结构和应用程序级。引用参数的基础结构示例可以是发送到事务处理监视器的事务/登记 ID。在书籍购买方案中，书籍的 ISBN 编号可以是引用参数的应用程序级示例。

Metadata

所有 Web 服务交互都是通过交换 SOAP 消息来执行的，如上一部分所述。为了提供可靠的开发和操作环境，将使用计算机可读元数据描述服务。元数据可实现互操作性。 Web 服务元数据有多种用途。它用于描述服务可以支持的消息交换格式，以及服务的有效消息交换模式。元数据还用于描述服务的功能和要求。这种最后一种形式的元数据称为服务的策略。消息交换格式和消息交换模式以 WSDL 表示。策略使用 WS-Policy 表示。协定使用上述所有三种元数据表示。协定是一种抽象，可将应用程序与其所依赖的服务的内部实现细节隔离开来。

Web 服务描述语言（即 WSDL）是第一个广泛采用的用于描述 Web 服务的基本特征的机制。 WSDL 中描述的消息分组到定义基本消息模式的操作中。操作分组到接口中，称为端口，这些端口为服务指定抽象协定。最后，端口和绑定用于将 portTypes 与具体传输和物理部署信息相关联。 WSDL 说明是自动识别目标服务的所有特征并启用软件开发工具的第一步。

WSDL 指定请求消息必须包含的内容，以及响应消息在明确表示法中的外观。 WSDL 文件用于描述消息格式的表示法基于 XML 架构。这意味着它既是编程语言中性的，也是基于标准的，这使得它适合描述可从各种平台和编程语言访问的服务接口。除了描述消息内容之外，WSDL 还可以定义服务可用的位置以及用于与服务通信的通信协议。这意味着 WSDL 文件可以指定编写程序以与 Web 服务交互所需的基元素。有多种工具可用于读取 WSDL 文件并生成为 Web 服务生成语法正确的消息所需的代码。

虽然 WSDL 是一个很好的起点，但不足以描述 Web 服务的所有方面。 WSDL 只允许表示一个相当小的属性集。 Web 服务所需的更多详细信息的示例包括：

操作特征：该服务支持 SOAP 版本 1.2。
部署特征：该服务仅在上午 9 点到下午 5 点之间可用。
安全特征：访问服务需要 Kerberos [KERBEROS] 票证。

第一代 Web 服务必须使用专有协议在带外交换元数据。此问题通过 WS-Policy [WS-Policy] 得到解决。 WS-Policy提供通用模型和语法来描述和传达 Web 服务的策略。它指定一组基本构造，可供其他 Web 服务规范使用和扩展，以描述广泛的服务要求和功能。 WS-Policy引入了一种用于表达策略断言的简单且可扩展的语法，以及用于解释这些断言的处理模型。断言可以合并为逻辑替代项。

策略断言允许程序员在开发时或运行时将适当的元数据添加到服务信息。开发时间策略的示例包括允许的最大消息大小或支持的规范的确切版本。运行时策略的示例包括强制服务停机或在给定的管理过程中 Web 服务不可用，例如常规硬件维护。本文稍后会介绍与安全性相关的策略示例。

单个策略断言可以分组以形成策略替代项。策略是策略替代项的集合。为了促进互操作性，根据策略的 XML Infoset 表示形式来定义策略。定义策略的精简窗体是为了在保持互操作性的同时减小策略文档的大小。

策略用于传达两个 Web 服务终结点之间交互的条件。满足策略中的断言通常会导致反映这些条件的行为。因此，策略断言评估是识别兼容行为的核心。仅当请求者满足要求或容纳与断言对应的功能时，请求者才支持策略断言（策略的构建基块）。通常，此确定使用特定于域的知识。当且仅当请求者支持替代项中的所有断言时，请求者才支持策略替代项。这是使用策略断言的结果机械地确定的。此外，当且仅当请求者支持策略中的至少一个替代项时，请求者才支持策略。一旦评估了政策替代方案，这一决定也是机械的。请注意，尽管策略替代项是互斥的，但一般情况下无法决定是否可以同时支持多个替代项。

为了以可互操作的形式传达策略，策略表达式是策略的 XML Infoset 表示形式。普通窗体策略表达式是最直接的 Infoset;等效的备用信息集允许通过多个构造紧凑地表达策略。策略表达式是策略的基本构建基块。两个运算符用于表示其断言： All 和 ExactlyOne。 All 运算符指定必须保留策略替代项集合中的所有断言才能满足策略断言。 ExactlyOne 运算符指定必须保留策略替代项集合中存在的断言之一才能满足策略断言。

策略层位于 WSDL 说明之上，并扩充。通过使用 WS-PolicyAttachment [WS-PA] ，策略与 Web 服务元数据（例如 WSDL 定义或 UDDI [UDDI] 实体）相关联。策略可以作为其定义的固有部分与资源相关联，也可以单独关联。为上述目的定义了机制。具体而言，策略还可以与单个 SOAP 消息一起使用。为实体创建多个策略附件时，它们共同确定实体的有效策略。在 WSDL 层次结构的不同级别附加策略时必须小心，因为每个层次结构级别的净结果都是有效的策略。作为自我描述和人类可理解的清晰性的一般规则，最好是详细并重复它所应用的层次结构的每个级别的策略断言，而不是依赖于计算有效策略的机制。在 WSDL 文档中，与已部署终结点的消息交换可以同时包含所有四个主题类型中的有效策略。

WS-Policy和WS-PolicyAttachment的组合提高了以编程方式发现其他服务支持的策略和原因的能力。灵活地添加策略是对描述消息交互的 WSDL 信息的重要补充。

WSDL 和 WS-Policy都定义了元数据的格式，但没有指定获取或访问给定服务的元数据的机制。通常，可以使用各种技术发现服务元数据。为了使服务能够自描述，Web 服务体系结构在 WS-MetadataExchange [WS-MEX] 中为元数据定义了基于 SOAP 的访问协议。 GetMetadata 操作用于检索在请求的终结点引用中找到的元数据。 Get 操作类似，但旨在检索元数据节中引用的元数据，并且将在存储它的终结点引用处检索。

使用 WS-MEX 交换的元数据可以描述为资源。资源定义为终结点引用可寻址的任何实体，其中实体可以提供自身的 XML 表示形式。资源构成了在 Web 服务中构建状态管理所需的基础。

什么是 互操作性配置文件？

配置文件是一组准则，用于在核心协议之外使用 Web 服务规范。由于规范的常规用途设计，这些准则是必要的。在某些情况下，开发人员需要其他帮助来确定应使用哪些 Web 服务功能来满足特定要求。互操作性配置文件还解决了 Web 服务规范不够明确以确保所有实现以相同方式处理 SOAP 消息的领域中的歧义。

WS-I 基本配置文件

第一个 Web 服务配置文件由 Web Services-Interoperability 组织 (WS-I) [WS-I] 发布。 WS-I 已敲定其第一个配置文件，其标题为基本配置文件 1.0 [WSI-BP10]。此配置文件主要提供有关 SOAP 1.1 和 WSDL 1.0 的可互操作使用的指导。

安全性

本部分介绍 Web 服务体系结构中用于为系统内服务联合提供消息完整性、身份验证和机密性、安全令牌交换、消息会话安全性、安全策略表达式和安全性的规范。提供这些功能的规范包括 WS-Security、WS-Trust [WS_Trust]、WS-SecureConversation [WS-SecureConv]、WS-SecurityPolicy [WS-SecurityPolicy] 和 WS-Federation [WS_Federation]。

安全性是计算机系统的一个基本方面，尤其是由 Web 服务组成的系统。安全性必须可靠且有效。由于系统只能对消息格式和合法消息交换做出硬连线假设，因此必须基于明确、商定的机制和假设来构建安全性。安全基础结构还应足够灵活，以支持不同组织所需的各种安全策略。

当通信 Web 服务（例如安全套接字层 (SSL) 和传输层安全性 (TLS) ）之间提供安全传输时，可以简化安全解决方案的生成。通过安全传输，服务无需担心维护单个邮件的完整性和机密性：它们可以依赖于基础传输。但是，现有的传输级别安全性是一种仅限于点到点消息传递的解决方案。如果使用安全传输时存在中介，则初始发送方和最终接收方需要信任这些中介来帮助提供端到端安全性，因为每个跃点都是单独保护的。除了对所有中介的显式信任外，还必须考虑其他风险，例如消息的本地存储以及中介可能遭到入侵。

若要最大限度地利用 Web 服务，当通信终结点不信任中介时，必须提供端到端安全性。这需要更高级别的安全协议。端到端消息安全性是点到点传输级别安全性的更丰富的替代方法，因为它支持基于 SOAP 的 Web 服务所需的松散耦合、联合、多传输和可扩展环境。这种强大而灵活的基础结构可以结合现有技术和 Web 服务协议进行开发，同时缓解与点到点消息传递相关的许多安全风险。

尽管 Web 服务的安全要求很复杂，但没有发明新的安全机制来满足基于 SOAP 的消息传送的需求。分布式系统安全的现有方法，如 Kerberos 票证、公钥加密技术、X.509 [X509] 证书等已证明已足够。只有将这些现有安全方法应用于 SOAP 才需要新机制。这些新的安全协议在设计时考虑到了扩展性，以便将来能够合并新方法。主要设计目标是为为 SOAP 和 Web 服务体系结构的其余部分设计的自描述安全属性提供机制。

Web 服务安全性基于以下要求：传入消息证明有关发件人、服务或其他资源的一组断言。我们称这些声明或安全断言。安全声明的示例包括标识、属性、密钥所有权、权限或功能。这些断言以 XML 包装的二进制安全令牌进行编码。在传统安全术语中，这些安全令牌表示功能和访问控制的组合。

使用各种方法来创建安全令牌。 Web 服务可能基于本地信息生成自定义安全令牌。或者，可以从专用服务（如 X.509 证书颁发机构或 Kerberos 域控制器）检索安全令牌。若要自动执行服务之间的通信，需要一种表达安全要求的机制。

服务可以使用 WS-SecurityPolicy 中指定的策略断言来表达其安全要求。此规范将在本文的后续小节中介绍。通过检索这些策略断言，应用程序可以生成符合目标服务要求的消息。声明、安全令牌和策略提供的功能以及从 Web 服务检索这些功能的这种组合非常强大。

常规 Web 服务安全模型支持多种更具体的安全模型，例如基于标识的授权、访问控制列表和基于功能的授权。它允许使用现有技术，例如 X.509 公钥证书、基于 XML 的令牌、Kerberos 共享机密票证和密码摘要。常规模型足以构建使用更复杂的方法进行更高级密钥交换、身份验证、基于策略的访问控制、审核和复杂信任关系的系统。也可以使用代理和中继服务。例如，可以生成中继服务以在信任边界强制实施安全策略;超出边界的消息将加密，而保留在边界内的消息则未加密。以前的解决方案中不存在这种灵活性和复杂程度。

附录 C 中所述的常见安全攻击包括系统威胁的基本分类，在选择 Web 服务安全功能时应仔细考虑这些威胁。

本部分的其余部分将探讨 Web 服务安全模型的应用。两个关键主题是保护通信和保护应用程序。不假定使用安全消息传输，也不需要安全 Web 服务。

消息完整性和机密性

消息级安全性是实现端到端安全性的关键构建基块。使用消息级安全性时，不需要传输级别安全性。消息级别安全性的要求包括消息完整性、消息身份验证和机密性。消息完整性可确保在没有检测的情况下无法更改消息。使用 XML 签名 [XMLSIG] 可确保可以检测到消息修改。

消息身份验证标识发送消息的主体。如果使用公钥加密，则可以确定主体的唯一标识。将公钥加密与受信任的源认证的密钥结合使用可提供此身份验证。但是，如果使用对称密钥加密，则情况并非如此 - 只能识别知道共享机密的主体组。

消息保密性可确保未经授权的第三方在传输过程中无法读取消息。 SOAP 消息通过结合使用 XML 加密 [XMLENC] 与安全令牌来保密。

完整性、身份验证和保密性机制将原始消息 (或消息) 的一部分作为输入，并将与产品相关的数据 (（如校验和) ）作为输出。例如，在简单情况下，XML 元素的签名可以实现为 XML 元素所有字符的哈希的非对称加密。然后，可以在消息中存储并传输此加密哈希。

XML 文档可以视为字符串字符。逐字符比较是关键的安全操作，例如 XML 签名。一个字符的差异是不同的结果。序列化是用于表示“网络上”对象的方法。例如，序列化用于创建 SOAP 消息的 XML 表示形式。消息处理软件会忽略不同序列化软件产生的任何 inessential typographical 变体，但会对安全软件产生重大影响。 XML 消息的 Infoset 表示形式可改善此问题。若要使 XML 签名正常工作，必须将消息转换为所有各方一致的 XML 表单。规范化是一个术语，用于描述用于生成非关键信息（例如换行符、制表符空格、属性顺序和结束标记样式）的一致视图的方法。签名包括规范化方法，用于使邮件收件人能够以与发件人一致的方式处理安全信息。服务使用的特定规范化方法是放置在 WSDL portType 绑定或 WSDL 端口上的有用策略断言。

WS-Security指定消息完整性和机密性以及单条消息身份验证的机制。对于消息完整性，规范详细说明了加密签名的表示方式，以及如何与 SOAP 消息的特定部分相关联。方法允许消息的任意格式正确的片段具有单独的签名。同样，保密性是通过对消息格式正确的片段进行加密来实现的。身份验证是使用数字签名实现的。

WS-Security规范描述了目前使用的常见安全机制，但不排除将来添加新的安全机制。由于 SOAP 处理模型使用标头元素来做出处理决策，因此在确定要加密 SOAP 消息中的哪些元素时，必须非常小心。

Web 服务设计人员必须了解消息的处理方式，才能确定要加密哪些元素以及要使用哪些加密算法。当特定标头元素需要由第三方或中介处理时，这些决策更为重要。如果这些参与方不了解相应的解密数据或加密 XML 元素时使用的约定，则它们将无法正常运行。此外，每个处理节点必须对消息中包含的安全信息有一个共同的了解。

加密标头中的 XML 元素的一个自然选择是将其完全加密，将原始元素替换为加密数据类型的元素。这种简单方法存在缺点。例如，中介很难确定哪些元素必须处理 (使用 mustUnderstand=“1” 属性) 修饰的元素。此外，由于元素类型发生更改，因此很难确定其原始类型。

另一种方法是将元素转换为一个元素，其中保留正确 SOAP 处理所需的所有密钥属性，并将原始元素加密并放置在可分辨的子元素中。此方法的优点是即使不知道如何解密元素的中介也能实现正确的处理。此方法的缺点是，它要求各方都理解用于表示原始元素的约定。虽然 WS-Security 目前没有提供有关此方法的指导，但我们预计将来的工作会这样做。首选备用方法，因为它允许正确处理所有 SOAP 标头元素。

WS-Security 的配置文件规范中介绍了多种安全令牌。配置文件是为表示用户名、X.509 证书和基于 XML 的安全令牌的令牌开发的。基于 XML 的安全令牌包括安全断言标记语言 (SAML) [SAML] 和 eXtensible rights Markup Language/Rights Expression Language (REL) [REL]。 Kerberos 票证的使用规范也在开发中。

WS-I 基本安全配置文件

WS-I 发布的最新互操作性配置文件之一是基本安全配置文件 (BSP) [WSI-BSP10]。此配置文件提供WS-Security和各种安全令牌的实现指南，例如用户名 [WS-SecUsername] 和 X.509 证书令牌 [WS-SecX509]。它旨在与 WS-I 基本配置文件进行补充和撰写。

基于安全令牌的信任

需要安全令牌才能提供端到端安全解决方案。这些安全令牌必须直接或间接地在消息处理参与方之间共享。每个参与方还必须确定是否可以信任断言凭据。这些信任关系基于安全令牌的交换和中转以及已建立的支持性信任策略。例如，中转令牌的受信任程度取决于系统管理员及其建立的信任关系。

提供安全令牌的服务可能非常多样化。这是 Web 服务首先使用每个基础安全技术的位置。为了提供统一的解决方案而不考虑安全技术，新协议设计用于信任域之间的安全令牌交换。

WS-Trust [WS-Trust] 通过用于请求、颁发和中转安全令牌的协议补充WS-Security。具体而言，定义了用于获取、颁发、续订和验证安全令牌的操作。该规范的另一个功能是中转新信任关系的机制。网络和传输保护机制（如 IPsec 或 TLS/SSL）可与WS-Trust结合使用，以满足不同的安全要求和方案。

可以通过向适当的颁发者显式请求安全令牌获取，或通过将获取委托给受信任的第三方间接完成安全令牌获取。还可以在带外获取令牌。例如，令牌可以从安全机构发送到一方，而无需显式请求令牌。为了完成此图，系统管理员确定初始信任关系，例如，将给定服务指定为受信任的根服务。此方法类似于目前用于在 Web 上启动安全性的方法。从此服务获取的所有令牌都受到与受信任的根本身相同的信任程度。例如，如果根仅对声明 A 和 B 受信任，而消息包含声明 A、B 和 C，则仅信任消息中的声明 A 和 B。通过信任关系委派提供配置灵活性。

为了解决在返回或颁发安全令牌之前需要双方之间进行一组交换的情况，为验证、协商和交换指定了机制。一种称为“质询”的特定交换形式为一方提供了一种机制，以证明其拥有与令牌关联的机密。其他类型的交换包括旧协议隧道。 WS-Trust定义如何在这两个示例之外扩展其他令牌交换协议的规范。

表示安全声明的安全令牌由受信任的根或通过委派链颁发。这些安全声明用于验证消息是否符合到位的安全策略。它们还核实了索赔者的属性是否得到签名的证实。在中转信任模型中，即受信任的中间人分发安全令牌的模型，签名不能验证申请人的身份，而是可以验证中间人的身份。该中间人可能只是断言索赔者的身份。

安全会话

某些消息身份验证和保密机制在计算上可能很昂贵。特别是，许多加密技术消耗大量处理能力。当单独保护消息时，这些成本通常是不可避免的。但是，当两个 Web 服务交换多条消息时，可以使用比WS-Security中定义的方法更高效、更可靠的消息机密性方法。保护消息会话时，应使用这些基于对称加密的机制。

WS-SecureConversation [WS-SecConv] 基于共享机密（例如对称加密）定义两个通信方之间的安全上下文。安全上下文在会话的生存期内在各方之间共享。会话密钥派生自共享机密，用于解密会话中发送的各个消息。安全上下文在网络上表示为新的安全令牌类型 (安全上下文令牌或 SCT) 。

定义了在安全会话的各方之间建立安全上下文的三种不同方法。首先，安全令牌服务可能会创建它们，发起方必须提取它才能传播它。其次，其中一个通信方创建安全上下文，并在消息中将其传播给另一方。第三，安全环境是通过协商和交换建立的。 Web 服务选择最适合其需求的方法。

必要时可以修改安全上下文。更新安全上下文的一个要求示例是需要延长上下文的过期时间。

安全上下文令牌表示或包含共享机密。此机密用于对消息进行签名和/或加密。使用共享机密时，参与方可能会选择要使用的不同密钥派生模式。例如，可以派生四个密钥，以便双方可以使用单独的密钥进行签名和加密。若要使密钥保持最新状态并保持高级别的安全性，应使用后续派生。最好使用此方法保护会话。 WS-SecureConversation规范定义了一种机制，用于指示在给定消息中使用哪个派生。每个派生算法都使用 URI 进行标识。

安全政策

WS-SecurityPolicy [WS-SecurityPolicy] 通过指定符合 WS-Policy 的语言的安全策略断言来补充WS-Security。它的六个断言与安全令牌、消息完整性、消息机密性、对 SOAP 中介的消息可见性、对安全标头的约束以及消息的期限相关。例如，策略断言可能要求使用给定颁发机构的公钥对所有消息进行签名，或者要求基于 Kerberos 票证进行身份验证。

系统联合

应用程序安全性需要除我们目前介绍的机制之外的其他机制。例如，标识在信任域中有效，但在其他信任域中很可能毫无意义。要使不同信任域中的服务能够验证标识，需要适当的机制。 WS-Federation定义了跨信任域启用标识、帐户、属性、身份验证和授权信息共享的机制。通过使用这些机制，多个安全域可以通过允许和代理参与的 Web 服务之间的标识、属性和身份验证信任来联合。该规范扩展了WS-Trust模型，允许将属性和假名集成到令牌颁发机制中，从而形成多域标识映射机制。这些机制支持单一登录、注销和假名，并描述属性和假名专用服务的角色。

可以通过联合身份验证解决各种要求。一个示例是将员工与其雇主相关联。在本例中，公司 A 的 Jane 从 OfficeSupplyStore.com 进行购买。公司 A 和 OfficeSupplyStore.com 有采购合同。由于 Jane 的身份与 CompanyA 相关联，因此可以根据合同授权她进行购买。

第二个示例是将一个人映射到多个假名。 Joe 在工作中可能被称为 joe@companya.com。他可能还具有其他身份，例如 joe_bloggs@hotmail.com 和 josephb@cornell.edu。通过联合身份验证，系统可以确定其中每个标识都是相同的 Joe。

Web 服务联合安全体系结构中定义了两大类请求程序 (消息发送方) ：被动和智能 (主动) 。被动请求程序 [WS-FedPassive] 是仅使用 HTTP 且从不颁发安全令牌的服务。智能请求程序是一种能够发出包含安全令牌的消息的服务，如 WS-Security 和 WS-Trust 中所述的消息。传统的基于 HTTP 的 Web 浏览器是被动请求者的一个示例。已开发配置文件规范来定义这两种请求程序的行为。

对于智能请求者，活动请求者配置文件 [WS-FedActive] 指定如何使用 SOAP 消息将单一登录、注销和假名集成到 Web 服务安全模型中。实际上，配置文件描述如何在智能请求者的上下文中实现WS-Federation中所述的模型。它指定了对各种安全令牌的要求。作为这些安全令牌要求之一的示例，如果不使用安全通道，X.509 证书的令牌必须包含颁发机构的名称和整个令牌上的签名。配置文件还要求 X.509 令牌包含唯一标识向其授予令牌的主题的使用者标识符。

发现

本部分介绍用于在网络上查找 Web 服务并确定服务可用性的 Web 服务体系结构的功能组件：UDDI 和 WS-Discovery [WS-Discovery]。

Web 服务发现是无需人工干预即可自动连接到服务的关键启用程序。 Web 服务发现方法反映了在计算机系统中查找信息的两种最常见方法：查找已知位置，或将请求广播到所有可用的侦听器。 UDDI 注册表充当目录，发现协议用于广播请求。

Web 服务提供商提供了各种选项来部署 UDDI 注册表。部署方案分为三类：公共、企业外和企业内部。为了支持公共部署，由 Microsoft、IBM 和 SAP 领导的一组供应商托管了 UDDI 业务注册表 [UBR]。 UBR 是跨多个托管组织复制的公共 UDDI 注册表，既充当基于 Internet 的 Web 服务的资源，也充当 Web 服务开发人员的测试台。虽然迄今为止，公共 UDDI 实现受到最多的关注，但早期采用者更频繁地使用企业外和企业内部方法。在这两个部署方案中，专用注册表由组织部署，并且可以更严格地控制注册的信息类型。这些专用注册表可能只专用于一个组织或业务合作伙伴组。 UDDI 还为注册表之间的复制和跨部署的信任联合定义了协议。使用这些协议会进一步增加可供实现者使用的部署方案的数量。

对于所有部署方案，UDDI 目录包含有关 Web 服务及其托管位置的详细信息。 UDDI 目录条目有三个主要部分：服务提供商、提供的 Web 服务和与实现的绑定。其中每个部分都逐步提供有关 Web 服务的详细信息。

最一般的信息描述了服务提供程序。此信息不是针对 Web 服务软件，而是针对需要直接与服务负责人联系的开发人员或实施者。服务提供商信息包括姓名、地址、联系人和其他管理详细信息。所有 UDDI 条目都有多个用于多语言说明的元素。

可用 Web 服务的列表存储在服务提供程序条目中。这些服务可能会根据其预期用途进行组织：它们可分组到应用程序区域、地理位置或任何其他适当的方案中。存储在 UDDI 注册表中的服务信息仅包括服务的说明和指向它包含的 Web 服务实现的指针。也可以注册由其他提供程序托管的服务（称为“服务投影”）的链接。

UDDI 服务提供程序条目的最后一部分是绑定到实现。此绑定将 Web 服务条目关联到确切的 URI () ，以标识服务的部署位置，指定要用于访问的协议，并包含对实现的确切协议的引用。

这些详细信息足以让开发人员编写调用 Web 服务的应用程序。详细协议定义通过名为类型模型 (或 tModel) 的 UDDI 实体提供。在许多情况下，tModel 引用描述 SOAP Web 服务接口的 WSDL 文件，但 tModels 也足够灵活，可以描述几乎任何类型的资源。

对于在 UDDI 中注册的每个提供程序或服务，标准分类 (（例如 NAICS [NAICS] 和较旧的 SIC 行业代码 [SIC]) 或其他标识方案 (（如 Edgar Central Index Key) ）可用于对信息进行分类并提高搜索准确性。作为任何实现的一部分，可用的分类和标识符方案集很容易扩展，因此可以对其进行自定义以支持任何特定的地理、行业或公司要求。

动态发现

动态 Web 服务发现以不同的方式提供。动态发现的 Web 服务除了将信息存储在已知注册表中，还可以显式地宣布其到达和离开网络。 WS-Discovery定义通过多播消息通知和发现 Web 服务的协议。

当 Web 服务连接到网络时，它会通过发送 Hello 消息来宣布其到达。在最简单的情况下，这些公告是使用多播协议通过网络发送的，我们称之为临时网络。此方法还可以最大程度地减少在网络上轮询的需求。为了限制网络流量并优化发现过程，系统可能包含发现代理。发现代理取代了使用已知服务位置发送多播消息的需要，将即席网络转换为托管网络。使用配置信息，可将代理服务的集合链接在一起，以便将发现服务扩展到服务器组，从一台计算机扩展到多台计算机。

由于发现代理本身是 Web 服务，因此它们可能会使用自己的特殊 Hello 消息来宣布其存在。然后，接收此消息的 Web 服务可以利用代理的服务，并且不再需要使用更嘈杂的一对多发现协议。

当服务离开网络时，WS-Discovery指定要发送到网络或发现代理的 Bye 消息。此消息通知网络上的其他服务离开的 Web 服务不再可用。

为了补充此服务公告和离开的基本方法，WS-Discovery定义了两个操作：探测和解析，用于在网络上查找 Web 服务。对于即席网络，探测消息将发送到多播组，与请求匹配的目标服务会将响应直接返回给请求者。对于使用发现代理的托管网络，探测消息改为单播到发现代理。当要按名称定位 Web 服务时，将使用 Resolve 消息。解析消息仅在多播模式下发送。解析类似于地址解析协议或 ARP [ARP]，后者将 IP 地址转换为其相应的物理网络地址。

WS-Discovery规范还允许系统配置，在这些配置中，探测消息被发送到通过某些其他管理方式（例如，通过使用已知的 DHCP 记录）建立的发现代理。

动态查找服务的功能可启用 Web 服务管理引导。结合 WS-Eventing [WS-Eventing] 和其他协议，可以使用此动态发现基础结构生成更复杂的管理服务。

动态发现还会将 Web 服务体系结构扩展到设备，例如那些可能实现通用即插即用 & (UPnP) 协议的设备。这是使体系结构真正通用的重要一步。例如，借助WS-Discovery和 WS-Eventing，打印机或存储介质等设备可以作为 Web 服务合并到系统中，而无需专门的工具或协议。

Web 服务的设备配置文件规范

Web 服务设备配置文件 [WS-DP] 规范提供有关应在资源受限的设备上实现 Web 服务体系结构规范系列的子集的指导。此配置文件尝试在可用的丰富功能与因资源限制而做出权衡时最重要的功能之间找到平衡。

协议协调协议 - 可靠的消息传送和事务

本部分介绍 Web 服务体系结构的组件，这些组件提供可靠的消息传递、事务行为，以及提供 Web 服务集合之间的显式协调的功能。定义此功能的规范包括 WS-ReliableMessaging、WS-Coordination [WS-Coord]、WS-AtomicTransaction [WS-AT] 和 WS-BusinessActivity。

当多个 Web 服务必须完成一个联合工作单元或在共同行为下运行时，必须就要使用的协议达成一致。 Web 服务之间的这种最小协调是不可避免的。还需要协调协议，以便能够确定并同意已达到共同目标。 Web 服务之间的每次交互都可以被视为一种协调。协议协调协议使体系结构更有可能让参与者服务成功完成他们共同设置的操作。 Web 服务体系结构设计为在遇到丢失消息的传输和服务发生故障时正常运行。

任何多方协调都可以通过根据需要连续加入更多参与者，从两方协调中建立起来。两方协调可能是自发的，也可能需要指定的协调人。常见的自发协调协议的一个示例是同步请求-响应消息传送模式。这是最简单的协议协调形式之一：对于每个工作请求，收件人 Web 服务必须先完成所有预期的工作，然后才能将任何数据返回给请求者。双方都遵循这种严格的模式，无需显式协调服务。 “Three-Leg握手”部分提供了自发协调的第二个示例。 WS-ReliableMessaging是一个非常通用的多消息自发协调的示例，将在下一部分中介绍。

可靠消息传递

许多条件可能会中断两个服务之间的消息交换。当使用 HTTP 1.0 和 SMTP [SMTP] 等不可靠的传输协议进行传输或邮件交换跨越多个传输层连接时，尤其会出现此问题。消息可能会丢失、重复或重新排序，Web 服务可能会失败并丢失易失状态。 WS-ReliableMessaging是一种协议，可根据特定的传递保证特征实现消息的可靠传递。该规范定义了三种可以组合使用的不同保证：

至少传递一次：每条消息至少传递一次。
最多一次传递：不会传递重复邮件。
In-Order传递：邮件的传递顺序与发送顺序相同。

至少一次和最多一次保证的组合可生成精确一次交付保证。由于 Web 服务体系结构采用与传输无关的设计，因此无论使用的通信传输或传输组合如何，都保证所有交付保证。使用 WS-ReliableMessaging 简化了系统开发，因为开发人员必须预见的潜在交付失败模式数量较少。

可靠消息传送不需要显式协调器。使用 WS-ReliableMessaging 时，参与者必须基于 SOAP 消息标头中发送的信息识别协议。作为组传输的消息集称为消息序列。消息序列可由发起方/发送方或 Web 服务建立，在建立双工关联时通常由两者建立。使用 CreateSequence 和 CreateSequenceResponse 消息显式建立序列。当所需的最终结果是将两个单向序列用作双工序列时，发起程序将提供 Web 服务要使用的序列。此序列的 ID 由发起程序包含在 CreateSequence 消息中。

WS-ReliableMessaging 中定义了多个策略断言。这些策略断言是使用 WS-Policy 中定义的机制表示的。

可靠的消息传送协议简化了开发人员在各种传输保证下传输消息时必须编写的代码。相反，底层基础结构会验证消息是否已在终结点之间正确传输、重新传输消息并在必要时检测重复。应用程序不需要任何其他逻辑来处理消息重新传输、重复消息消除、消息重新排序或消息确认，可能需要这些逻辑才能提供传递保证。 WS-ReliableMessaging的实现分布在发起方和服务之间。那些不可见的“在线”特征（如消息传递顺序）由WS-ReliableMessaging规范的实现提供。虽然由于传输丢失而导致的消息重新传输等特征由应用程序不为人知道的消息传送层处理，但其他端到端特征（如按顺序传递）需要消息传递基础结构和接收方应用程序进行协作。值得注意的是，当发送方预期“作为已发送”时，在接收方上提供消息排序“as received”是按顺序进行的错误实现。当发送方预期为“接收”时，在接收方上提供“作为已发送”的订单是按顺序正确实现的。

指定协调器

一些 N 向协调协议的家庭需要指定的协调人通过一些合作服务来引导一个工作单位。一个示例是，活动必须在并非所有预期同时连接的服务之间进行协调。只要每个参与者和协调者在某个时间进行沟通，就可能发生协调，并就结果达成一致。 Web 服务体系结构为指定的协调器定义了一些简单操作。

WS-Coordination规范定义了一个可扩展的协调框架，以支持需要显式协调器的方案。此协议引入了一个名为“协调上下文”的 SOAP 标头块，用于唯一标识要执行的联合工作。为了启动联合工作，Web 服务将协调上下文发送到一个或多个目标服务。收到协调上下文会提醒收件人服务请求联合协作。协调上下文包含足够的信息，供请求收件人确定是否参与工作。协调上下文中包含的确切信息因请求的工作类型而异。

协调类型集是开放式的。只要参与联合工作的每个服务对所需行为有共同的了解，新类型就可以由实现定义。例如，原子事务是在 Web 服务体系结构中定义的几个初始基石协调类型之一。

如果理解并接受请求的协调类型，Web 服务将使用WS-Coordination注册协议通知协调器并参与联合工作。协调上下文包括协调器终结点引用，以及可能选择的可能行为的标识符。注册操作指定参与的 Web 服务支持的行为。将注册消息发送到协调器后，Web 服务将根据其订阅的协议参与工作。注册是协调框架中的关键操作。它允许不同 Web 服务的“连接在一起”，这些服务需要协调以执行联合工作单元。

WS-AtomicTransaction指定 Web 服务的传统 ACID 事务 [Gray & Reuter]。在原子事务协调类型的上下文中，定义了三个协议：完成协议和两个Two-Phase提交协议的变体。完成协议用于启动提交处理。注册完成的 Web 服务能够在提交处理开始时告知指定的协调器。此协议还定义消息，用于将事务的最终结果传达给发起方。但是，该协议不要求协调器确保发起程序处理结果。相比之下，WS-AtomicTransaction中的其他行为需要协调器确保参与者处理协调消息。

Two-Phase提交 (2PC) 协议使所有已注册的参与者都做出共同的提交或中止决定，并确保所有参与者都被告知最终结果。如其名称所示，它使用两轮通知来完成事务。定义了此协议的两个变体：Volatile 2PC 和 Durable 2PC。这两个协议在网络上使用相同的消息， (对应于准备、提交和中止) 的操作，但 Volatile 2PC 没有持久性要求。易失性 2PC 协议将由管理易失资源的参与者使用，例如缓存管理器或窗口管理器。协调器在第一轮通知中联系这些参与者，不需要第二轮通知。

持久 2PC 协议将由管理持久资源（如数据库和文件）的参与者使用。启动提交处理后，在联系所有可变 2PC 参与者后，将首次联系这些参与者。例如，这样就可以刷新缓存。 Durable 2PC 参与者需要整整两轮通知才能实现协调器施加的全有或全无行为并完成事务。这些行为最适合在事务期间保留资源的场景，而事务的生存期通常非常短。此协议保证在正常处理下，协调器将与第一阶段的结果联系所有参与者。对于预期需要更多时间才能完成的事务，或者当无法保留锁等资源时，备用行为由其他协调协议定义。

WS-AtomicTransaction 中定义了多个策略断言。这些策略断言是使用 WS-Policy 中定义的机制表示的。

排队系统

已证明在构建分布式系统时非常有用的一种模式是，使用事务持久队列提供存储和转发异步消息传送。在此模式中，在每个传输终结点上利用原子事务。在发送方，发送应用程序以原子事务方式将消息传送到持久队列，应用程序和队列管理器都使用WS-AtomicTransaction进行协调。仅当处理消息时没有错误时，它才会被视为已成功传递到队列。

然后，队列子系统接管原始队列和接收方队列之间的消息传送。此传输步骤可以在以后的消息放置在发起队列中的某个时间完成。此外，发起队列的位置不必与发出消息的应用程序的位置一致。

类似地，从收件人队列中检索消息的应用程序使用原子事务执行此操作。这样，仅当没有处理错误时，才能从队列中删除消息。

长时间活动

WS-BusinessActivity [WS-BA] 为长时间运行的事务指定两个协议。 WS-BusinessActivity规范基于补偿操作，而不是在提交事务之前对资源保持锁定。基础事务模型是所谓的开放式嵌套事务 [Gray & Reuter]。这些协议编纂了松散耦合服务对如何达成它们已结束联合任务的协议。在一个协议中，协调器明确告知参与者，不再代表联合任务请求更多的工作。第二个协议中，参与者是通知协调人代表联合任务的工作已完成的参与者。使用补偿性操作提供了一种在不保留锁定的情况下完成暂定操作的机制。如果系统出于任何原因想要撤消已完成的试探操作的效果，则发出补偿操作。

WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination来管理 Web 服务之间的协作。

Three-Leg握手

三条腿握手连接建立和拆解协议是不需要指定协调器服务的协调协议的一个示例。为了建立连接，发送方会向接收方发送请求。此请求建立会话。如果接受，接收方会通过确认消息积极响应此请求。发送方将第三条消息作为对确认的确认进行传输，验证双方是否知道另一方已建立会话。

拆解协议是类似的。其中一方向另一方发送会话拆解请求。收件人以对拆解邮件的确认进行响应。收到此确认后，发出拆解消息的一方将通过向确认发送确认来完成消息交换。

枚举、传输和事件

本部分介绍在 Web 服务体系结构中提供服务资源的枚举、其状态管理和事件通知的规范。它们基于 WS-Enumeration [WS-Enum]、WS-Transfer [WS-Transfer] 和 WS-Eventing。

枚举

许多方案要求使用不止一个请求/响应消息对进行数据交换。需要这些较长数据交换的应用程序类型包括数据库查询、数据流式处理、信息遍历（如命名空间）和枚举列表。具体而言，枚举是通过在数据源和请求者之间建立会话来实现的。会话中的连续消息传输要检索的元素的集合。未对服务用于组织将生成的项的方法做出任何假设。预期在正常处理情况下，枚举将在会话结束前生成所有基础数据。

WS-Enumeration指定用于建立枚举会话和检索数据序列的协议。枚举协议允许数据源向使用服务提供会话抽象（称为枚举上下文）。此枚举上下文表示通过一系列数据项的逻辑游标。然后，请求者在一个或多个 SOAP 消息的跨度内使用此枚举上下文来请求数据。枚举的数据表示为 XML Infosets。该规范还允许数据源提供用于启动新枚举的自定义机制。由于枚举会话可能需要多个消息交换，因此必须保留会话状态。

有关迭代进度的状态信息可由数据源或使用服务在请求之间维护。 WS-Enumeration允许数据源根据请求决定哪一方将负责维护下一个请求的状态。这种灵活性可实现多种优化。一个优化示例是允许服务器避免在调用之间保存任何游标状态。由于对于支持多个同时枚举的服务来说，消息延迟可能很大，因此不保留状态可能会显著节省必须维护的信息总量。资源受限的设备（如手机）上的服务实现可能根本无法维护任何状态信息。

传输

WS-Transfer [WS-Transfer] 中定义了管理通过 Web 服务访问的数据实体所需的基本操作。要了解WS-Transfer，需要引入两个新术语：工厂和资源。工厂是一种 Web 服务，可以从其 XML 表示形式创建资源。 WS-Transfer引入了创建、更新、检索和删除资源的操作。应注意的是，资源的状态维护最多取决于宿主服务器的“最大努力”。当客户端收到服务器接受创建或更新资源的请求时，可以合理地期望该资源现在存在于确认的位置并具有已确认的表示形式，但这是不能保证的，即使在没有任何第三方的情况下也是如此。服务器可以更改资源的表示形式，可以完全删除资源，也可以恢复已删除的资源。这种缺乏保证与 Web 带来的松散耦合模型是一致的。如果需要，服务可能会提供 Web 服务体系结构不需要的其他保证。

WS-Transfer 的创建、更新和删除操作扩展了 WS-MetadataExchange 中只读操作的功能。检索操作与 WS-MetadataExchange 中的 Get 操作完全相同。创建请求将发送到工厂。然后，工厂创建请求的资源并确定其初始表示形式。假定工厂不同于正在创建的资源。将为新资源分配一个服务确定的终结点引用，该引用在响应消息中返回。

Put 操作通过提供替换表示形式来更新资源。可以使用 WS-Transfer 中的 Get 操作检索资源表示形式的一次性快照（与 WS-MetadataExchange 中的 Get 操作相同）。成功执行删除操作后，资源不再可通过终结点引用使用。这四个元数据管理操作构成了在 Web 服务中构建状态管理所需的基础。

事件处理

在由相互通信的服务组成的系统中（可能使用异步消息传送），许多情况下，一个服务生成的信息对另一个服务感兴趣。由于缩放特性差，轮询通常不是获取此类信息的适当机制：通过网络发送的不必要的消息过多。相反，体系结构需要一种在事件发生时进行显式通知的机制。更重要的是要求在运行时动态完成源服务和使用者服务的绑定。 Web 服务体系结构通过轻型事件协议支持此功能。

WS-Eventing指定使以下四个实体能够交互的机制：订阅者、订阅管理器、事件源和事件接收器。这允许 Web 服务在充当订阅者时，注册对另一个 Web 服务提供的特定事件的兴趣，这些事件 (事件源) 。此注册称为订阅。 WS-Eventing定义服务可以提供的操作，这些操作允许创建和管理订阅。当事件源确定某个事件已发生时，它将向订阅管理器提供该信息。然后，订阅管理器可以将事件传达给所有匹配的订阅。这类似于在传统的发布/订阅事件通知系统中发布主题。 Web 服务体系结构在定义、组织和发现主题的方式上提供了完全的灵活性;它提供一个通用基础结构，用于管理可在许多不同的应用程序领域利用的订阅。

必须最终恢复的订阅租用资源。用于回收资源的主要机制是每个订阅的过期时间。还有一种用于查询订阅状态的机制。还定义了帮助订阅者管理其订阅集合的其他操作，包括续订、通知和取消订阅请求。当然，任何服务都可以随时免费结束订阅，这符合所有 Web 服务的自治原则。事件源可以使用订阅结束消息来通知订阅者订阅过早终止。

尽管基于事件的异步消息的一般模式很常见，但不同的应用程序通常需要备用事件传递机制。例如，在某些情况下，简单的异步消息可能是最佳的，而如果事件接收器可以通过轮询控制消息到达的流和时间，则其他情况可能效果更好。当无法从源访问接收器时（例如，当接收器位于防火墙后面时），轮询也是必要的。 WS-Eventing中引入了交付模式的概念，以支持这些要求。传递模式用作扩展点，为订阅者、事件接收器和事件源提供建立定制传递机制的方法。下面所述的管理规范使用此机制。

事件代理可用于通过不同的源聚合或重新分发通知。代理还可以用作独立的订阅管理器。 WS-Eventing 支持这两种方法。代理可以在系统中扮演多个重要角色。可以组织主题以供某些类的应用程序使用。中转站可以充当通知聚合器，合并来自多个源的事件信息。它们还可以充当筛选器，接收的消息数超过了用于自身通知的消息数。部署可靠且可缩放的通知系统需要这种灵活性。

管理

管理功能是要讨论的 Web 服务体系结构的最后一个方面。这些功能在 WS-Management [WS-Management] 规范中定义。

WS-Management基于体系结构的多个组件构建，提供所有系统管理解决方案所需的一组通用操作。这包括发现管理资源是否存在以及其中导航的功能。可以检索、设置、创建和删除单个管理资源，例如设置和动态值。可以枚举容器和集合的内容，例如大型表和日志。最后，定义事件订阅和特定的管理操作。在每个领域，WS-Management仅定义最低实现要求。

已采取谨慎措施，以便将一致的WS-Management实现部署到小型设备。同时，它已设计为纵向扩展到大型数据中心和分布式安装。此外，机制的定义独立于任何隐含的数据模型或系统运行状况模型。这种独立性支持将其应用于各种 Web 服务。

WS-Management要求使用带有特定附加信息的终结点引用托管资源。此信息包括提供资源访问权限的代理的 URL、资源所属的资源类型的唯一标识符 URI 以及标识资源的零个或多个密钥。这些键假定为名称/值对。此信息到WS-Addressing终结点引用的映射如下所示：资源的 URL 映射到 address 属性，资源类型标识符映射到相应的 XML 命名空间) 中名为 ResourceURI 的特定引用属性 (，每个键映射到名为 Key 的引用参数，其属性名为 Name。

为了满足管理服务的消息传送需求，为操作定义了三个限定符。这些限定符的 SOAP 表示形式位于标头元素中。 操作超时指定一个截止时间，在该截止时间之后无需为操作提供服务。需要或预期基础信息的转换时，使用区域设置元素。最后，提供 新鲜度 限定符来请求最新值，并禁止返回过时数据。

对于使用WS-Transfer操作的数据访问，WS-Management指定另外三个限定符。可以使用 SummaryPermitted 标头和 NoCache 标头限定 Get 操作。 SummaryPermitted 限定符允许传输缩写表示形式（如果可用）。 NoCache 限定符需要传输新数据，不允许缓存信息。对于 Put 和 Create 操作， ReturnResource 限定符要求服务返回资源的新表示形式。 ReturnResource 允许资源受限的 Web 服务在更新资源时不保留任何状态。

WS-Management为事件通知定义了三种自定义传递模式：批处理、拉取和捕获。这些模式中的每一种都由 URI 标识。建立订阅时使用这些 URI。批处理传递模式使订阅服务器能够接收捆绑在单个 SOAP 消息中的多个事件消息。订阅者还可以请求捆绑包中包含最大事件数、服务应采用累积事件的最大时间量以及应返回的最大数据量。拉取传递模式允许数据生成服务维护事件的逻辑队列，以便订阅者可以按需轮询通知。此轮询使用 WS-Enumeration 完成，其中包含随订阅响应消息一起返回的枚举上下文。最后，当 UDP 多播是适当的消息传送机制时，陷阱传递模式允许事件源使用它。在陷阱模式下，事件源可以将其通知发送到预先确定的 UDP 多播地址。

结束语

本文介绍 Web 服务体系结构的功能构建基块及其基本原则。每个构建基块都是根据协议规范定义的。我们期望本文中所述的功能范围和指导原则保持不变。但是，我们确实希望体系结构能够扩展以支持其他方案。能够适应创新是体系结构的基本优势。

已非常小心地确保各种 Web 服务协议可以完全相互组合：虽然它们是一起设计的，但它们可用于各种组合。作为功能构建基块，它们的行为类似于传统的开发框架。如果需要（例如 SOAP 附件），我们开发了完全适合体系结构的新解决方案。对组合的关注不是对丰富功能的威慑。

体系结构的 SOAP 消息传送基础可确保广泛的覆盖范围。 SOAP 消息传送以独立于传输的方式支持异步和同步模式。没有更灵活的基础结构。为了加速 Web 服务体系结构的广泛采用，这些规范已与广泛的技术合作伙伴集合一起编写。与这些关键技术提供商合作可加快设备和支持在线协议的编程环境的部署。实现广泛覆盖、广泛采用和独立于规模的结构是我们三个核心目标。

我们努力确保体系结构可以在任何平台上以任何编程语言实现。体系结构的基于消息和基于协议的性质促进了这一点。如有必要，例如仅使用WS-Security实现消息完整性、保密性和身份验证，以及仅使用 WS-Policy 表达元数据，我们已限制各种技术方法以提高互操作性级别。理想情况下，只要实现忠实地遵循体系结构的协议规范，它们就能够与任何其他 Web 服务通信。真相在铁丝上。

致谢

特别感谢奥米利·加齐特的持续支持和多项建议，感谢艾伦·盖勒、吉姆·约翰逊和罗德尼·林普雷希特的深入评论和出色的见解，感谢 Dan Simon 对常见安全攻击的描述，以及克里斯·卡勒的指导和对安全部分的多次修订。 John Shewchuk 对体系结构部分的贡献也是一个很大的帮助。感谢菲尔·伯恩斯坦、害羞的科恩、保罗·科顿、大卫·兰沃西、安德鲁·莱曼、布拉德·洛夫林、杰弗里·施利默、斯科特·西利、萨蒂什·萨特、马文·泰默、乔根·泰林和赫维·威尔逊的评论和鼓励。

最后但并非最不重要的一点，以下个人参与了 Web 服务体系结构的定义： (按字母顺序) Tony Andrews， Bob Atkinson、Keith Ballinger、Don Box、John Brezak、Allen Brown、Luis Felipe Cabrera、Erik Christensen、George Copeland、Michael Coulson、Giovanni Della-Libera、Brendan Dixon、Mike Dusche、Colleen Evans、Max Feingold、Henrik Frystyk Nielsen、Praerit Garg，奥米米·加齐特、艾伦·盖勒、乔希·格雷、马丁·古金、德斯特里·胡德、埃菲姆·胡迪斯、托马斯·扬丘克 Jim Johnson、Ryan Johnson、John Justice、Gopal Kakivaya、Chris Kaler、Johannes Klein、Scott Konersmann、Brian LaMacchia、Dave Langworthy、Andrew Layman、Paul Leach、Al Lee、Rodney Limprecht、Joe Long、Steve Lucco、John Manferdelli、Ashok Malhotra、Jonathan Marsh、Steve Millet、Angela Mills、Stefan Pharies、斯科特·罗宾逊、约丹·罗斯科夫、苏杰伊·萨尼、杰夫·施利默、奥利弗·夏普、约翰·休克、亚瑟·肖胡德、丹·西蒙、杰夫·斯佩尔曼、基思·斯托比、萨蒂什·萨特、罗伯特·瓦贝、艾略特·温戈尔德、理查德·沃德、赫维·威尔逊、肯尼·沃尔夫和埃里克·辛达。

附录 A：术语表

活动请求者 - 活动请求者是一个应用程序， (可能是 Web 浏览器) ，能够发出 Web 服务消息，如 WS-Security 和 WS-Trust 中所述的消息。

身份验证 - 验证安全凭据的过程。

授权 - 根据提供的安全凭据授予对安全资源的访问权限的过程。

规范化 - 将 XML 文档转换为与各方一致的表单的过程。在对文档进行签名和解释签名时使用。

声明 - 声明是关于发件人、服务或其他资源 (（例如名称、标识、密钥、组、特权、功能等）) 的语句。

协调上下文 - 一组协调服务要执行的工作集的唯一标识符。

反序列化 - 从八进制流构造 XML Infoset 的过程。它是用于从消息的线路格式创建消息的 Infoset 表示形式的方法。

摘要 - 摘要是八进制流的加密校验和。

域 - 安全域表示单个安全管理或信任单元。

持久两阶段提交 - 用于持久资源（如文件或数据库）上的事务的协议。

有效策略 - 对于给定策略主体，有效的策略是附加到包含策略主体的策略范围的策略的结果组合。

Exchange 模式 - 用于服务之间的消息交换的模型。

工厂 - 工厂是一种 Web 服务，可以从 XML 表示形式创建资源。

联合 - 联合身份验证是已建立相互配对信任的信任域的集合。信任级别可能会有所不同，但通常包括身份验证，并且可能包括授权。

标识映射 - 标识映射是一种在标识属性之间创建关系的方法。某些标识提供者可能会使用标识映射。

标识提供者 (IP) — 标识提供者是充当最终请求者的身份验证服务的实体。标识提供者还充当服务提供商的数据源身份验证服务， (这通常是安全令牌服务) 的扩展。

消息 - 消息是可供服务发送或接收的完整数据单元。它是信息交换的自包含单元。消息始终包含 SOAP 信封，并且可能包含 MTOM 和/或传输协议标头中指定的其他 MIME 部分。

消息路径 - 在原始源和最终接收方之间遍历的 SOAP 节点集。

被动请求程序 - 被动请求程序是能够广泛支持的 HTTP (（例如 HTTP/1.1) ）的 HTTP 浏览器。

策略 - 策略是策略替代项的集合。

策略替代项 - 策略替代项是策略断言的集合。

策略断言 - 策略断言表示特定于域的单个要求、功能、其他属性或行为。

策略表达式 - 策略表达式是策略的 XML Infoset 表示形式，采用普通形式或等效的压缩形式。

主体 - 可以授予安全权限或对安全性或标识进行断言的任何系统实体。

协议组合 - 协议组合是能够组合协议，同时保持技术一致性，并且没有任何意外的功能副作用。

资源 - 资源定义为可由终结点引用寻址的任何实体，其中实体可以提供自身的 XML 表示形式。

安全上下文 - 安全上下文是一个抽象的概念，它是指已建立的身份验证状态和协商密钥 (可能具有其他安全相关属性的) 。

安全上下文令牌 - 安全上下文令牌 (SCT) 是安全上下文抽象概念的线路表示形式，它允许上下文按 URI 命名并与 [WS-Security] 一起使用。

安全令牌 - 安全令牌 表示声明的集合。

安全令牌服务 - STS) (安全令牌服务是颁发安全令牌的 Web 服务， (请参阅 [WS-Security] ) 。也就是说，它根据它信任的证据、信任它 (的人或) 的特定接收者进行断言。为了传达信任，服务需要证明，例如签名来证明对安全令牌或安全令牌集的了解。服务本身可以生成令牌，也可以依赖于单独的 STS 来颁发具有其自己的信任声明的安全令牌 (请注意，对于某些安全令牌格式，这可以是重新颁发或共同签名) 。这是信任中介的基础。

序列化 - 将 XML Infoset 表示为八进制流的过程。它是用于为消息创建线路格式的方法。

服务 - 通过消息与其他实体交互的软件实体。请注意，服务不需要连接到网络。

签名 - 签名是使用加密算法计算并绑定到数据的值，以便数据的预期接收者可以使用签名来验证数据是否尚未更改并且源自消息的签名者，从而提供消息完整性和身份验证。可以使用对称或非对称密钥算法计算和验证签名。

注销- 注销是主体指示他们不再使用其令牌的过程，域中的服务可以销毁主体的令牌缓存。

单一登录 (SSO) — 单一登录是身份验证序列的优化，可消除对请求者执行的重复操作的负担。为了便于 SSO，名为 标识提供者 的元素可以代表请求者充当代理，向请求请求者相关信息的第三方提供身份验证事件的证据。这些标识提供者 (IP) 是受信任的第三方，需要由请求者 (信任，以维护请求者的标识信息，因为丢失此信息可能会导致请求者标识) 和 Web 服务泄露，这些服务可能会根据 IP 提供的标识信息的完整性授予对宝贵资源和信息的访问权限。

SOAP 中介 - SOAP 中间体 是 SOAP 处理节点，既不是原始消息发送方，也不是最终接收方。

对称密钥算法 - 一种加密算法，其中同一密钥用于加密和解密消息。

系统 - 实现特定功能的服务的集合。与分布式应用程序同义。

信任 - 信任表示一个实体愿意依赖第二个实体来执行一组操作和/或对一组主题和/或范围进行断言。

信任域 - 信任域是一个管理的安全空间，请求的源和目标可在其中确定和同意来自源的特定凭据集是否满足目标的相关安全策略。如果已将信任决定作为协议的一部分建立) 从而在信任域中包括受信任的第三方，则目标可能会将信任决定推迟到第三方 (。

可变两阶段提交 - 用于易失性资源（如缓存或窗口管理器）上的事务的协议。

Web 服务 - Web 服务是一种可重用的软件，它通过 XML、SOAP 和其他行业公认的标准通过网络交换消息。

附录 B：XML 信息集信息项

XML 文档可能包含 11 种类型的信息项。下面我们列出并定义 SOAP 允许提及其他项。 SOAP 允许的六个信息项是：

文档： 每个信息集中都有一个文档信息项。它用于引用所有其他信息项。
元素： 文档中每个 XML 元素的信息集中包含一个元素信息项。通过递归地跟随 Child 属性提供对所有元素的访问权限。
属性： 文档中每个属性的信息集中包含一个属性信息项。命名空间存在其他属性信息项。
命名空间： 一个命名空间信息项包含在其父元素范围内的每个命名空间的信息集中。
字符： 文档中每个数据字符的信息集中包含一个字符信息项。
评论： 文档中每个批注的信息集中包含一个批注信息项，DTD 中显示的批注信息项除外。

SOAP 不允许但存在于 XML 信息集的原始定义中的五个信息项是：处理指令、文档类型声明、未扩展的实体引用、未解析的实体和表示法。

附录 C：常见安全攻击

针对分布式系统的攻击可以沿多个轴进行划分。它们可以针对系统中的一个或多个主机，或针对它们之间的通信。攻击可能旨在中断操作、获取机密信息或在系统中执行未经授权的操作。它们可能会攻击系统中使用的加密和其他以安全为中心的技术，或者尝试通过攻击下面的系统和网络层或上面的应用程序层来绕过这些技术。

以下是根据这些轴组织的安全攻击类的简短非详尽列表，以及每个类的标准对策：

对主机的攻击：
- 拒绝服务 (DoS) 攻击会破坏主机操作，使其无法响应。
  
  当指向加密层时，DoS 通常会尝试强制主机重复执行某些身份验证或密钥交换协议所需的计算成本高昂的公钥操作。针对此类攻击的典型防御措施是延迟公钥操作，直到可以通过更便宜的方法（如对称加密或“谜题”）来验证对话者的合法性。
  
  底层网络层或总体应用层上的 DoS 攻击很难防止，尤其是在攻击者拥有大量资源的情况下，并且流量无法与合法流量的“快速人群”区分开来。网络基础结构通常必须以将流量输送到可管理级别的方式进行部署。
- 主机机密性或授权攻击试图破坏隐私或标识。
  
  这些攻击可能会利用主机软件中的漏洞来获取对主机的控制。适当的安全管理（例如安装修补程序、防火墙配置以及降低已公开应用程序的权限）是通常的对策。
  
  另一种类型的攻击利用系统或应用程序中的弱点，例如错误设置策略或应用程序逻辑错误，允许机密性或授权泄露，而一般主机泄漏。适当的安全策略管理和谨慎的应用程序编程是抵御此类攻击的唯一防御措施。
  
  “欺骗”攻击是攻击者尝试通过假定另一个授权方的身份来获取各种操作的授权，并采取相应的行动。安全身份验证协议（正确使用）可以防止欺骗，只要主机和授权方都仔细保护用于身份验证的加密机密。
对通信的攻击：
- 网络上的 DoS 攻击试图中断与服务的通信。与主机网络层上的网络层一样，只能使用网络基础结构手段解决这些问题。
- 对网络通信机密性的攻击试图损害网络上的隐私。
  
  通过使用加密，可以阻止直接监视明文通信。
  
  具有足够强密钥大小的加密算法可能使加密分析攻击变得不可行。
- 对网络通信授权的攻击试图入侵标识。
  
  可以使用包含消息身份验证的消息安全协议来防止消息伪造攻击（攻击者尝试将消息注入会话）和消息更改攻击（攻击者修改会话中发送的消息）。
  
  可以通过序列号或时间戳和消息缓存的组合来检测和解决攻击者之前发送 (，从而正确验证) 消息到会话中的消息重播攻击。

附录 D：参考

核心规范

[ARP]

以太网地址解析协议 [RFC826]。大卫·普卢默 1982年11月。 Internet 工程任务组。

[HTML]

HTML 4.01 规范。 Ed. 戴夫·拉格特等人，1999年12月24日。 W3C.org。

[HTTP]

超文本传输协议 - HTTP/1.1 (RFC 2616) 。 Ed. R. Fielding等人，1999年6月。互联网协会。

[KERBEROS]

Kerberos 网络身份验证服务 (V5) 。 J. 科尔和C.诺伊曼 1993年9月。 Internet 工程任务组。

[MIME]

多用途 Internet 邮件扩展 (MIME) 第一部分：Internet 邮件正文的格式。 Ed. N. 释放，等人，1996年11月。 Internet 工程任务组。

[REL]

信息技术 - 多媒体框架 (MPEG-21) - 第 5 部分：权限表达语言。国际标准化组织 (ISO/IEC 21000-5：2004) 。

[RFC1630]

WWW (RFC 1630) 中的通用资源标识符。 Ed. T. 伯纳斯-李 1994年6月。 Internet 工程任务组。

[SAML]

OASIS 安全断言标记语言的断言和协议 (SAML) V1.1。 Ed. 伊芙·马勒等人，2003年9月2日。 OASIS-Open.org。

[SMTP]

简单邮件传输协议。 Ed. J. 克伦辛 2001年4月。 Internet 工程任务组。

[TCPIP]

传输控制协议。 Ed. 乔恩·波斯特尔 1981年9月。国防高级研究项目局。

Internet 协议。 Ed. 乔恩·波斯特尔 1981年9月。国防高级研究项目局。

[TLS]

TLS 协议。 T. 迪克斯，等人，1999年1月。互联网协会。

[UDP]

用户数据报协议。 J. Postel。 1980年8月。 Internet 工程任务组。

[X509]

Data Networks and Open System Communications Directory (ITU-T 建议 X.509) 。 1997年6月。国际电信联盟。

[XSLT-20]

XSL 转换 (XSLT) 版本 2.0。 Ed. 迈克尔·凯 2004年11月12日。 W3C.org

[XML-Infoset]

XML Information Set (Second Edition) 。 Ed. 约翰·考恩等人，2004年2月4日。 W3C.org。

[XML-10]

可扩展标记语言 (XML) 1.0 (第三版) 。 Ed. 蒂姆·布雷等人，2004年2月4日。 W3C.org

[XMLENC]

XML 加密语法和处理。 Ed. Imamura，等人，2002年12月10日。 W3C.org。

[XML-Query]

XQuery 1.0：XML 查询语言。 Ed. 斯科特·博格等人，2004年7月23日。 W3C.org

[XML-Schema]

XML 架构第 0 部分：入门。 Ed. 大卫·法赛德 2001年5月2日。 W3C.org。

XML 架构第 1 部分：结构。 Ed. 亨利·汤姆森等人，2001年5月2日。 W3C.org。

XML 架构第 2 部分：数据类型。 Ed. 保罗·比伦等人，2001年5月2日。 W3C.org。

[XMLSIG]

XML 签名语法和处理。 Ed. 唐纳德·伊斯特莱克等人，2004年2月12日。 W3C.org。

Web 服务规范

[SOAP]

简单对象访问协议 (SOAP) 1.1。 Ed. 唐·Box等人，2000年5月8日。 W3C.org。

[SOAP-UDP]

SOAP-over-UDP。哈罗德·康布斯等人，2004年9月。 BEA、Lexmark、Microsoft 和 Ricoh。

[MTOM]

SOAP 消息传输优化机制。 Ed. 诺亚·门德尔松等人，2004年7月8日。 W3C.org。

[UDDI]

UDDI 版本 2.04 API 规范。 Ed. 汤姆·贝尔伍德 2004年7月19日。 OASIS-Open.org。

[WSDL]

Web 服务描述语言 (WSDL) 1.1。 Ed. 埃里克·克里斯滕森等人，2001年3月15日。 W3C.org。

[WS-Addressing]

Web 服务寻址 (WS 寻址) 。唐·Box等人，2004年8月。 BEA、IBM 和 Microsoft。

[WS-AT]

Web 服务原子事务 (WS-AtomicTransaction) 。路易斯·费利佩·卡布雷拉，等人，2003年9月。 BEA、IBM 和 Microsoft。

[WS-BA]

Web Services Business Activity Framework (WS-BusinessActivity) 。路易斯·费利佩·卡布雷拉，等人，2004年1月。 BEA、IBM 和 Microsoft。

[WS-Coord]

Web 服务协调 (WS-Coordination) 。路易斯·费利佩·卡布雷拉，等人，2003年9月。 BEA、IBM 和 Microsoft。

[WS-Discovery]

Web 服务动态发现 (WS-Discovery) 。约翰·比蒂，等人，2004年2月。 Microsoft Corporation。

[WS-Enum]

Web 服务枚举 (WS 枚举) 。唐·Box等人，2004年9月。 Microsoft Corporation。

[WS-Eventing]

Web 服务事件 (WS 事件) 。路易斯·费利佩·卡布雷拉，等人，2004年9月。 BEA、Microsoft 和 TIBCO。

[WS-Federation]

Web 服务联合身份验证语言 (WS 联合身份验证) 。西达斯·巴贾伊等人，2003年7月8日。 IBM、Microsoft、BEA、RSA Security 和 VeriSign。

[WS-FedActive]

WS 联合身份验证：活动请求者配置文件。西达斯·巴贾伊等人，2003年7月8日。 IBM、Microsoft、BEA、RSA Security 和 VeriSign。

[WS-FedPassive]

WS 联合身份验证：被动请求者配置文件。西达斯·巴贾伊等人，2003年7月8日。 IBM、Microsoft、BEA、RSA Security 和 VeriSign。

[WS-MEX]

Web 服务元数据交换 (WS-MetadataExchange) 。基思·巴灵格，等人，2004年3月。 BEA、IBM、Microsoft 和 SAP。

[WS-Policy]

Web 服务策略框架 (WS-Policy) 。唐·Box等人，2004年9月3日。 BEA、IBM、Microsoft 和 SAP。

[WS-PA]

Web 服务策略附件 (WS-PolicyAttachment) 。 Don Box， et al3 2004 年 9 月。 BEA、IBM、Microsoft 和 SAP。

[WS-RM]

Web Services Reliable Messaging (WS-ReliableMessaging) 。 Ruslan Bilorusets等人，2004年3月。 BEA、IBM、Microsoft 和 TIBCO。

[WS-SecureConv]

Web 服务安全对话语言 (WS-SecureConversation) 。史蒂夫·安德森，等人，2004年5月。 BEA Systems， Inc.、Computer Associates International， Inc.、International Business Machines Corporation、Layer 7 Technologies、Microsoft Corporation、Netegrity， Inc.、Oblix Inc.、OpenNetwork Technologies Inc.、Ping Identity Corporation、Reactivity Inc.、RSA Security Inc.、VeriSign Inc.和 Westbridge Technology。

[WS-Security]

Web 服务安全性：SOAP 消息安全 (WS-Security) 。 Ed. 安东尼·纳达林，等人，2004年3月。 OASIS-Open.org。

[WS-SecurityPolicy]

Web 服务安全策略语言 (WS-SecurityPolicy) 。乔瓦尼·德拉-利贝拉等人，2002年12月18日。 IBM、Microsoft 和 VeriSign。

[WS-SecUsername]

Web 服务安全性：用户名令牌配置文件 V1.0。 Ed. 安东尼·纳达林，等人，2004年3月。 OASIS-Open.org。

[WS-SecX509]

Web 服务安全性：X.509 令牌配置文件 V1.0。 Ed. 菲利普·哈勒姆-贝克等人，2004年3月。 OASIS-Open.org。

[WS-Transfer]

Web 服务传输 (WS-transfer) 。 Ed. 唐·Box等人，2004年9月。 Microsoft Corporation。

[WS-Trust]

Web 服务信任语言 (WS-Trust) 。史蒂夫·安德森，等人，2004年5月。 BEA Systems， Inc.、Computer Associates International， Inc.、International Business Machines Corporation、Layer 7 Technologies、Microsoft Corporation、Netegrity， Inc.、Oblix Inc.、OpenNetwork Technologies Inc.、Ping Identity Corporation、Reactivity Inc.、RSA Security Inc.、VeriSign Inc.和 Westbridge Technology， Inc.

[XOP]

XML-binary 优化打包 (XOP) 。 Ed. 诺亚·门德尔松等人，2004年6月8日。 W3C.org。

互操作性配置文件

[WSI-BP10]

基本配置文件版本 1.0。 Ed. 基思·巴灵格等人，2004年4月16日。 Web Services-Interoperability组织。

[WSI-BSP10]

基本安全配置文件版本 1.0 (工作组草稿) 。 Ed. 艾比·巴比尔等人，2004年5月12日。 Web Services-Interoperability组织。

[WS-DP]

Web 服务的设备配置文件。香农陈，等人，2004年5月。 Microsoft Corporation。

其他资源

[NAICS]

北美工业分类系统 (NAICS) 。 NAICS 协会。

[SIC]

标准工业分类 (SIC) 。

[UBR]

UDDI 业务注册表。

[WS-I]

Web Services-Interoperability 组织 (WS-I) 。

[灰色 & 路透社]

事务处理：概念和技术。吉姆·格雷和安德里亚斯·路透摩根-考夫曼，1993年。

Last updated on 2007-04-03