安全、可靠、事务处理 Web 服务：体系结构和组合

2003 年 9 月

内容

1.0 简介
   1.1 可组合服务
   1.2 实践中的合成示例
2.0 Web 服务：Service-Oriented 体系结构
   2.1 服务由架构和协定类型描述
   2.2 服务兼容性不仅仅是类型兼容性
   2.3 服务方向假设坏事可能发生并会发生
   2.4 服务方向支持灵活绑定服务
3.0 Web 服务规范和函数
   3.1 Web 服务的可组合方法
   3.2 基础知识 - 传输和消息传送
      3.2.1 传输 – HTTP、HTTP/S、SMTP
      3.2.2 消息格式 - XSD
      3.2.3 WS-Addressing
   3.3 说明
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 获取说明
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 服务保障
   3.5 安全性
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 Reliable Messaging
      3.6.1 WS-ReliableMessaging
   3.7 事务
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 服务组合
      3.8.1 BPEL4WS
实践中的 4.0 Web 服务 - 示例
   4.1 第 1 部分：客户体验
   4.2 第 2 部分：供应商体验
5.0 结论
6.0 确认

1.0 简介

目前，Web 服务（特别是处理 XML 编码的 SOAP 消息、通过 HTTP 发送和使用 Web 服务描述语言（WSDL）描述的服务）正在广泛部署。 （术语 XML、SOAP 和 HTTP 目前常用，在许多方面，它们的使用已超出其原始首字母缩略词。为了完整起见，下面列出了这些首字母缩略词：XML（eXtensible 标记语言、SOAP、简单对象访问协议和 HTTP）超文本传输协议。Web 服务用于一系列应用程序集成方案：从简单、即席、防火墙后、数据共享到非常大的 Internet 零售和货币交易。 越来越多的 Web 服务正在移动、设备和网格方案中应用。

Web 服务提供软件组件之间的互操作性，这些组件可以在不同公司之间通信，并且可以驻留在不同的基础结构上。 这解决了客户、软件开发人员和合作伙伴面临的最关键问题之一。 HTTP 和 SOAP 提供通信和消息互操作性。 WSDL 提供服务的说明以支持开发工具之间的互操作性;它补充了通信互操作性以及交换接口定义的能力。

基本 Web 服务规范集使客户和软件供应商能够解决重要问题。 在成功的基础上，许多开发人员和公司都准备解决 Web 服务技术更困难的问题。 Web 服务的成功使开发人员希望从 Web 服务获得更多功能。 由于有意义的工具和通信互操作性一直成功，开发人员现在期望增强的功能可以互操作。

除了基本的消息互操作性和接换之外，开发人员还越来越需要更高级别的应用程序服务进行互操作。 许多商业应用程序在环境（“中间件”或“操作系统”）中执行，这些应用程序为安全和事务等功能提供支持。

IBM、Microsoft和其他业内人士经常被要求使 Web 服务更安全、更可靠且能够更好地支持事务。 此外，我们还被要求提供这些功能，同时保留目前在 Web 服务中找到的基本简单性和互操作性。

本文为满足这些需求的一组 Web 服务规范提供了简洁的概述。 有关规范的详细信息，我们提供了对实际文档的引用。 本文的主要用途是简要定义这些规范提供给我们的客户的价值。 我们还介绍了这些规范如何相互补充，为分布式应用程序组合可靠的环境。

我们面临着一个关键的工程挑战：如何为 Web 服务提供新的安全性、可靠性和事务功能，而无需增加比所需的更复杂的功能？

1.1 可组合服务

正如我们在 SOAP 和 WSDL、IBM、Microsoft 以及合作伙伴遵循了 Web 服务规范定义中 可组合性 的设计原则。 我们遵循的方法基于 Web 服务规范定义中 可组合性 的设计原则。 我们开发的每个规范都解决了一个直接的需求，并具有自己的价值。 例如，开发人员可以采用可靠的消息传送来简化解决方案开发，或采用BPEL4WS来定义其服务组合。 虽然每个规范都独立存在，但它们旨在相互组合和协作。

我们使用术语 可组合性 来描述可组合提供更强大的功能的独立规范。 操作系统和中间件提供程序可以支持组合功能，例如提供程序可以集成可靠的消息支持来通信BPEL4WS进程。 此示例结合了两个独立的规范，通过消除在流程设计过程中处理消息通信错误的需求，从而简化通信过程的开发。

可组合性使 增量消耗 或 渐进式发现 新概念、工具和服务。 开发人员只需了解并实现必要的内容，无需再学习。 解决方案的复杂性只会因为问题的需求增加而增加，而不是由于技术“膨胀”。

可组合性仍然是 Web 服务的主要设计目标之一。 在过去的几年里，我们定义了最基本的 Web 服务规范（SOAP 和 WSDL），以固有地支持组合。 Web 服务的基本特征之一是常规的多部分消息结构。 此结构可实现新功能 组合。 支持新服务的新消息元素可能以不改变现有功能处理的方式添加到消息中。 例如，可以独立添加事务标识符和可靠的消息传送序列号。 这两个扩展不会相互冲突，并且与预先存在的消息结构兼容。

图 1. 可组合性允许根据需要使用元素。

图 1 显示了一个简单的 Web 服务消息，其中包含用于 WS 寻址、WS-Security和 WS-ReliableMessaging的元素。 请注意，WS 寻址、WS-Security 和 WS-ReliableMessaging 元素是独立的，这些元素可以独立使用，而无需更改其他元素的处理。

此特征使安全性、可靠性和事务能够根据 可组合 消息元素来定义。

组合的概念还允许创建一组定义完善的可组合 Web 服务，以支持安全性、可靠性等。这些定义完善的服务指定支持更高级别的 Web 服务功能所需的服务行为。 例如，在 WS-Trust 中定义的安全令牌服务，该服务在消息中颁发并验证安全元素。

此外，服务使用者必须能够确定支持的和必需的服务保证。 这些服务必须记录它们对事务、安全性、可靠消息传送等的要求和支持。WS-Policy 使 Web 服务能够以增量方式扩充其 WSDL，以记录他们支持或需要哪些事务、安全性和可靠性功能。 WSDL 和 WS-Policy 启用服务说明的组合。 这样，其他方就可以了解与服务交互时要使用的消息元素和更高级别的服务。

1.2 实践中的合成示例

图 2 提供了一个概述，其中显示了实际组合。 客户和供应商使用 Web 服务来处理订单。

图 2. 订单处理系统中的合成

在生成这些 Web 服务时，开发人员使用 WSDL 和相关文档来描述其业务界面。 这些 WSDL 文档描述了客户和供应商 Web 服务将处理的消息集，例如从客户流向供应商的 SubmitPurchaseOrder （SubmitPO） 消息。 如图 2 顶部所示。 应用程序的核心部分到位后，开发人员就可以决定支持附加功能，例如，在这里，他们决定进行订单处理。 为此，将以下元素组合到现有结构：

• 这些服务将 WS-Policy 文档，这些文档描述其对事务的支持与其服务的 WSDL 说明相关联。 请注意，这些策略声明会扩充，但不从根本上改变现有业务功能。
• 为了支持事务处理，服务会添加一个附加消息元素，用于描述与现有应用程序消息组合但不从根本上改变的事务。
• 当供应商服务收到包含事务元素的消息时，它使用此信息与名为支持事务函数的协调器的指定 Web 服务通信。 同样，此附加的 Web 服务只是添加到解决方案中，不需要修改现有业务功能的说明。
• 最后，服务可以实现其他操作以支持与事务协调器服务的集成。

在上图中，这些附加元素突出显示。

模型是增量的且可组合，因为：

• 可以独立于添加其他函数来添加新函数。
• 添加函数不会中断现有消息、消息处理逻辑或 WSDL。

可组合性是一个日益重要的设计原则，但这种方法并不总是被充分理解。 虽然各个 Web 服务规范定义了各个元素和服务如何互操作，但本白皮书旨在概述如何组合规范集合以提供更复杂的可互操作 Web 服务。

2.0 Web 服务：Service-Oriented 体系结构

近年来，我们目睹了以 Web 服务开发为中心的一系列活动。 有了所有这些活动，必须退后一步，问一个问题，“为什么？当然，Web 服务不会启用新类型的计算功能，毕竟所有 Web 服务仍在现有计算机上运行，执行相同的指令集并访问相同的数据。 此外，在许多情况下，Web 服务协议实际上会增加给定任务的协议开销。

我们看到对 Web 服务如此感兴趣的一个关键原因是 Web 服务非常适合启用 Service-Oriented 体系结构（SOA）。 使用 Web 服务生成 SOA 时，解决方案由自治服务集合组成，这些服务由 URL 标识、使用 WSDL 记录的接口以及处理定义完善的 XML 消息。 SOA 是对面向对象的（OO）、过程和数据为中心的解决方案实现方法的自然补充。 事实上，在创建 SOA 系统时，通常使用一个或多个这些技术来构造各个服务。

Service-Oriented 体系结构在一个关键方面不同于 OO 和过程系统：绑定。 服务根据它们提供的 功能 交互，并 它们交付 的方式。 OO 和过程系统基于类型或名称将元素链接在一起。 以下部分提供了更多详细信息。

2.1 服务由架构和协定类型描述

与以前的系统不同，Web 服务模型不对需要通用实现的共享类型的概念进行操作。 相反，服务仅基于协定（用于消息处理行为的 WSDL/BPEL4WS）和架构（用于消息结构的 WSDL/XSD）进行交互。 这使服务能够描述它可以对这些消息发送和接收和/或排序约束的消息的结构。 结构与行为之间的分离以及这些特征的显式计算机可验证说明简化了异类环境中的集成。

此外，此信息足以描述服务接口的特征，以便应用程序集成不需要共享执行环境来创建消息结构或行为。

面向服务的模型假设一个完全分布式的环境，如果不是不可能，则很难将架构和/或协定中的更改传播到遇到服务的所有方。 服务方向意味着协定和架构应保持向后兼容，并且可能包含特定处理系统无法完全理解的信息。

因此，设计用于面向服务的设计的协定和架构技术比传统的面向对象的接口更具灵活性。 具体而言，服务使用 XML 元素通配符（例如 xsd：any）等功能，架构扩展和可选的 SOAP 标头块，以不破坏已部署的应用程序的方式发展服务。 这些特征是 Web 服务的可组合性的关键。

2.2 服务兼容性不仅仅是类型兼容性

过程和面向对象的设计通常等同于类型兼容性与语义兼容性。 服务方向为确定兼容性提供了更丰富的模型。 结构兼容性基于协定（WSDL 和可选BPEL4WS）和架构（XSD），可以验证。 此外，WS-Policy 的出现为服务之间的服务保证兼容性提供了额外的自动分析。 这基于 WS-Policy 语句形式的功能和要求的显式断言来完成。

使用 WS-Policy，服务以包含断言组合的计算机可读策略表达式的形式描述其服务保障功能和要求。 这样，服务就可以根据他们交付合同的“如何”或“质量”相互选择，

策略断言由稳定且全局唯一的名称标识，无论应用于哪个服务，其含义在时间和空间中都是一致的。 策略断言也可能具有符合断言确切解释的参数。

2.3 服务方向假设坏事可能发生并会发生

一些以前用于分布式应用程序的方法显式假定有一个常见的类型空间、执行模型和过程/对象引用模型。 从本质上讲，“内存中”编程模型定义了分布式系统模型。

服务方向只是假设服务自主执行，并且没有本地执行或常见操作环境的概念。 因此，SOA 显式假定通信、可用性和类型错误是常见的。

为了保持系统完整性，面向服务的设计显式依赖于各种技术来处理异步和部分故障模式。 异步消息传送、事务、可靠消息传送和冗余部署等技术是面向服务的系统中的规范。

此外，与内存中模型不同，服务方向假定不仅传入消息的格式不正确，而且可能已出于恶意或完全意外目的传输它。 因此，面向服务的系统通过要求应用程序证明已向发件人授予所需权限，从而减轻 所有 邮件发件人的证明负担，从而保护自己。 与服务自治的概念一致，面向服务的体系结构通常依赖于管理管理的信任关系，以避免经典 Web 应用程序中常见的按服务身份验证机制。

2.4 服务方向支持灵活绑定服务

面向服务的体系结构（SOA）的核心概念之一是灵活的服务绑定。 更传统的过程、组件和对象模型通过引用（指针）或名称将组件绑定在一起。 SOA 支持更动态地发现服务实例，这些实例提供请求者所需的接口、语义和服务保证。

在过程或面向对象的系统中，调用方通常根据服务器导出的类型或共享名称空间查找服务器。 在 SOA 系统中，调用方可以搜索注册表，例如 UDDI 以获取服务。

1. 这是与调用方要求兼容的消息。 可以通过 WSDL 或来自已知 XML 架构的匹配消息实现兼容性。
2. 该文档支持调用方所需的服务保证。 例如，调用方可能需要某些安全或事务方法。

与服务实现相关的松散绑定，该服务可实现行为的替代实现，可用于满足一系列业务要求。 例如，替代实现可能与供应链中的替代供应商相对应，从而对不断变化的市场状况做出更快速的响应。 同样，替代实现可能是地理分布的数据中心，可实现灾难恢复。

3.0 Web 服务规范和函数

本部分概述了 Web 服务规范。

3.1 Web 服务的可组合方法

本部分简要介绍了可用的 Web 服务规范。 我们将他们的价值解释给解决方案提供商，他们在更广泛的体系结构中的角色，以及它们如何相互赞美。

下图提供 IBM、Microsoft 等发布的 Web 服务规范的高级分组。 请注意，此图并不意味着组之间的严格分层;相反，它旨在提供关于功能区域之间的关系的直觉。 例如，消息安全性不需要说明，类似地说明是消息传送的有用开发时间概念。

图 3. 可互操作的 Web 服务协议体系结构

3.2 基础知识 - 传输和消息传送

如果我寄给你一封用法语写的信，但你期望用英语打电话，我们不会沟通。 Web 服务的互操作性面临相同的问题;我们通过提供一组常见的传输和消息传递技术来解决这一问题。

此外，为了确保这些技术在实践中有效，IBM、Microsoft和其他技术创建了 Web 服务互操作性组织（WS-I）。 最近，WS-I 发布了一个基本配置文件，该配置文件正式记录了可互操作的 Web 服务传输和消息传递机制。

3.2.1 传输 - HTTP、HTTP/S、SMTP

这组规范定义了用于在 Web 服务之间移动原始数据的核心通信机制。

HTTP、HTTP/S 和简单邮件传输协议（SMTP）是此组中的示例。 Web 服务实现可能还支持其他传输，但对标准互操作协议的支持至关重要。

3.2.2 消息格式 - XSD

下一组规范定义用于编码用于传输的 Web 服务消息的可互操作机制。 传输在服务之间移动“字节”块。 仅当参与者可以将字节转换为其应用程序处理的有用数据结构时，这才有用。

消息规范组定义如何正确设置消息的格式。 XML 和 XML 架构定义提供了用于抽象地就消息（数据）结构达成一致的机制。 SOAP 定义用于表示服务通过传输交换的字节信息中的 XML 消息的标准编码。

3.2.3 WS-Addressing

消息和响应都去某个地方，来自某个地方。 WS 寻址 提供了一种可互操作的传输独立方法来识别消息发送者和接收方。 WS-Addressing 还提供了更精细的方法，用于识别发送或应接收消息的服务中的特定元素。

如今，大多数使用 Web 服务的系统使用 HTTP 传输中放置的 URL 对 Web 服务消息的目标进行编码。 响应的目标由返回传输地址确定。 此方法基于 HTTP 的基本浏览器-服务器模型构建。

使用今天的方法时，源和目标信息不是消息本身的一部分。 这可能会导致几个问题。 如果传输连接终止（例如，响应需要很长时间且连接超时），或者消息由防火墙等中介转发，则信息可能会丢失。

WS-Addressing 提供了一种机制，用于将目标、源和其他重要地址信息直接放置在 Web 服务消息中。 简言之，WS-Addressing 将地址信息与任何特定传输模型分离。

在许多情况下，消息直接面向服务，并且只需使用 URL 即可描述消息中的寻址信息。 但在实践中，我们经常发现消息针对服务中的特定元素或资源。 例如，协调服务可能正在协调许多不同的任务。 协调器需要将大多数传入消息与它管理的特定任务实例相关联，而不是协调服务本身。 

WS-Addressing 提供了一种简单而强大的机制，称为 终结点引用，用于解决服务管理的实体问题。 虽然这些信息可以在服务的 URL 中以即席方式进行编码，但终结点引用提供了一个标准 XML 元素，使结构化方法能够对这种细粒度的寻址进行编码。

通过对寻址的精细控制与消息源和目标的传输中性编码相结合，Web 服务消息可以通过中介在一系列传输之间发送，并启用异步和延长的持续时间通信模式。

WS-Addressing 还使发送方能够指示响应应以独立于传输的方式在何处进行。 对邮件的响应不一定会转到发件人。 例如，在 HTTP 中，如果没有 WS-Addressing 则无法指定应在其他位置发送响应。

这些消息模型的增强功能使 Web 服务能够用于支持许多业务方案。 例如，某些银行任务需要人工审查以供某些步骤审批。 任务在任何时间点通常都有许多活动实例。 WS-Addressing 提供了一种通用机制，用于将传入或传出消息与特定任务相关联。 服务使用的机制对于通过终结点引用使用服务的机制是透明的。

3.3 说明

传输和消息规范允许 Web 服务使用消息进行通信。 但是参与者如何知道消息是什么？ Web 服务如何记录或描述它发送和接收的消息？ 使用 Web 服务需要了解 Web 服务将使用和生成的消息—Web 服务的 接口。 规范的说明组使 Web 服务能够表达其接口和功能。

除了消息互操作性;这些规范还支持 开发工具互操作性。 说明规范提供了一个标准模型，允许来自不同供应商的不同工具协作支持开发人员。 与 Web 服务将合作伙伴与实现和基础结构选择隔离的方式相同，说明规范将合作伙伴与开发工具选项隔离开来。

3.3.1 WSDL

Web 服务描述语言（WSDL） 和 XML 架构（XSD） 是此组中的基本规范。 XML 架构允许开发人员和服务提供商为数据结构定义 XML 类型，例如采购订单和消息，例如 CreatePO 消息。 WSDL 允许 Web 服务记录它接收和发送的消息。 换句话说，服务在接收和发送的消息方面执行什么“操作”或“函数”。

WSDL 支持一系列消息交互模式。 它支持无响应、请求/响应的单向输入消息，以及使用或不使用响应发送单向输入消息。 最后两种模式使服务能够指定它所需的其他服务。

建议的 WSDL 增强功能支持记录服务支持的协议和消息格式以及服务的地址。

3.3.2 WS-Policy

WSDL 和 XSD 定义通常不提供足够的信息来调用 Web 服务。 WSDL 和 XSD 定义服务的接口语法，但它们并不表示有关服务如何传送其接口或服务期望调用方的信息。 例如，服务是否需要安全或实现事务？

WS-Policy 使服务能够指定调用方期望的内容及其实现接口的方式。 WS-Policy 对于实现服务更高级别的功能操作的互操作性至关重要。 安全、事务、可靠消息传送和其他规范需要具体的 WS-Policy 架构。 这些允许服务描述他们期望的功能保证，并提供给调用方。

WS-Policy 框架提供了用于定义策略表达式的基础模型。

WS-Policy 支持用于聚合策略语句的语法，并允许构建更灵活和完整的策略集。

WS-PolicyAttachment 指定如何将策略集与 XML 消息和 WSDL 元素（操作和 portTypes）相关联。

WS-Policy 和 WS-PolicyAttachment 一起提供框架。 各个规范定义其特定于域的策略语句和架构。

最后，@PageWS-PolicyAssertions 提供了一组可用于实现互操作性的基本通用策略语句。

3.3.3 获取说明

XML、XSD、WSDL 和 WS-Policy 支持描述服务的接口和服务保证。 但是，服务的潜在用户如何找到此信息？

目前，最常见的方法是通过电子邮件交换或口碑。 需要更常规的可缩放模型。 有两个选项，服务可以直接转到服务，以使用 WS-MetadataExchange 获取信息，或者可以选择使用聚合多个目标服务的此信息的 UDDI 服务。

开发人员在引用服务时使用 WS-MetadataExchange，并且需要了解该服务的作用。 开发人员想要查找对支持特定函数集的服务的引用时，请使用 UDDI。

3.3.4 WS-MetadataExchange

如上所述，服务通常提供描述服务本身的信息，例如 WSDL、WS-Policy 和 XSD。 我们将有关服务的信息称为元数据的收集。 WS-MetadataExchange 规范使服务能够通过 Web 服务接口向其他人提供元数据。 仅给定对 Web 服务的引用，潜在用户可以访问一组 WSDL/SOAP 操作来检索描述服务的元数据。 客户端可以在设计时、生成客户端时或在运行时使用 WS-MetadataExchange。

3.3.5 UDDI

通常，收集有关服务集合的元数据以及使信息以可搜索的形式提供非常有用。 此类元数据聚合服务是一个有用的存储库，组织可在其中发布其提供的服务、描述其服务的接口，以及启用特定于域的服务分类。 通用说明和发现接口（UDDI） 规范定义元数据聚合服务。

解决方案可以在设计时查询 UDDI，以查找与其要求兼容的服务。 例如，开发人员可以在BPEL4WS工作流的定义中使用这些服务。 解决方案还可以在运行时查询 UDDI。 在此方案中，调用方“知道”它所需的接口，并搜索满足其功能要求的服务，或由已知合作伙伴提供。

请注意，可用于使用元数据填充 UDDI 服务的机制之一是使用 WS-MetadataExchange 从服务获取元数据。

3.4 服务保障

Web 服务产生了如此多的热情，部分原因是它们能够弥合不同的系统。 开发人员使用传输、消息传递和说明的基本功能生成了许多功能齐全的解决方案。 但是，为了接受开发人员创建更强大的集成解决方案，Web 服务必须提供功能，以确保更传统的中间件解决方案 相同的 服务保证级别。 仅仅交换消息是不够的。 应用程序和服务驻留在中间件和系统中，这些中间件和系统提供有价值的更高级别的功能，例如安全性、可靠性和事务操作。 Web 服务必须提供一种机制，用于在这些函数之间实现互操作性。

3.5 安全性

此 @Page系列规范对于跨组织 Web 服务至关重要。 这些规范支持身份验证和消息完整性、机密性、信任和隐私。 他们还支持不同组织之间的安全联合。

3.5.1 WS-Security

WS-Security 是安全 Web 服务的基本构建基块。 如今，大多数分布式 Web 服务依赖于对安全功能的传输级别支持。 示例包括 HTTP/S 和 BASIC-Auth 身份验证。 这些安全方法提供了安全通信所需的最低要求。 但是，它们提供的函数级别明显小于现有中间件和分布式环境提供的函数级别。

两个示例突出了 BASIC-Auth 和 HTTP/S 的缺陷。

• 向服务 B 发送消息。B 部分处理消息并将其转发到服务 C。HTTP/S 允许 A-B 和 B-C 之间的身份验证、机密性和完整性。 但是，C 和 A 无法相互进行身份验证，也不能隐藏 B 中的信息。
• 对于 A、B 和 C，请使用 BASIC-Auth 进行身份验证。 他们必须共享相同的复制用户和密码信息。 在许多情况下，这是不能接受的。

WS-Security 解决这些问题。 它支持：

• 已签名的加密安全令牌。 A 可以生成一个令牌，C 可以验证其是否来自 A。B 无法伪造令牌。
• A 可以对所选元素或整个消息进行签名。 这允许 B 和 C 确认消息自 A 发送后尚未更改。
• A 可以密封消息或所选元素。 这可确保只有这些元素的预期服务才能使用该信息。 这可以防止 B 查看适用于 C 的信息，反之亦然。

WS-Security 使用现有的安全模型（Kerberos、X509 等）。 这些规范具体定义了如何以可互操作的方式使用现有模型。 如果没有 WS-Security，多跃点、多方 Web 服务计算将无法安全。

3.5.2 WS-Trust

安全性依赖于预定义的信任关系。 Kerberos 的工作原理是因为参与者“信任”Kerberos 密钥分发中心。 PKI 的工作原理是因为参与者信任根证书颁发机构。 WS-Trust 定义用于设置和验证信任关系的可扩展模型。

WS-Trust 中的关键概念是 安全令牌服务（STS）。 STS 是一种可区分的 Web 服务，可颁发、交换和验证安全令牌。 WS-Trust 允许 Web 服务设置并同意它们“信任”的安全服务器，并依赖于这些服务器。

STS 具有广泛的适用性，可用于颁发发出各种断言的安全令牌。 在许多情况下，它将用于发出相同的断言，但采用不同的格式。 例如，STS 可能会发出 Kerberos 令牌，该令牌断言密钥持有者为 Susan，并且可能会基于受信任的证书颁发机构颁发的 X.509 证书执行此操作。 这使组织能够使用不同的安全技术进行联合。 STS 可能还会发出安全令牌，断言密钥持有者是基于断言标识声明的传入安全令牌的组 BankTellers 的成员。

3.5.3 WS-SecureConversation

某些 Web 服务方案仅涉及少量消息的短暂交换。 WS-Security 随时支持此模型。 其他方案涉及 Web 服务之间的长时间多消息对话。 WS-Security 还支持此模型，但解决方案不是最佳的。

在这些方案中，WS-Security 有两种亚最佳用法：

• 重复使用计算成本高昂的加密操作，例如公钥验证。
• 使用同一加密密钥发送和接收许多消息，提供更多信息，允许暴力攻击“破坏代码”。

出于这些原因，HTTP/S 等协议使用公钥来执行简单的协商，该协商定义 特定于聊天的密钥。 此密钥交换允许更高效的安全实现，并减少使用一组特定密钥加密的信息量。

WS-SecureConversation 为 WS-Security 提供类似的支持。 参与者通常使用公钥 WS-Security 来启动“对话”或“会话”，并使用 WS-SecureConversation 就会话特定密钥达成一致，以便签名和加密信息。

3.5.4 WS-Federation

WS 联合身份验证 允许一组组织建立单个虚拟安全域。 例如，旅行社、航空公司和酒店连锁店可能会建立这样的联合身份验证。 “登录”联合身份验证的任何成员的最终用户已有效地登录到所有成员。 WS-Federation 定义了多个模型，用于通过 WS-Trust 和 WS-SecureConversation 拓扑之间的协议提供联合安全性。

此外，客户在处理企业时通常具有“属性”。 例如，首选窗口或过道座椅，或中型汽车。 WS-Federation 允许成员设置联合属性空间。 这样，每个参与者就可以安全地控制每个成员对最终用户的属性信息的访问权限。

有关个人的属性和信息可能会因隐私保护而密切保留，或者因为该信息为特定成员提供竞争优势。 为了支持这些要求，WS-Federation 支持 假名模型。 向旅行社进行身份验证的用户在与航空公司或酒店交互时生成了“别名”。 这可以保护最终用户的隐私，以及旅行社可以通过了解用户属性而获得的竞争优势。

3.6 Reliable Messaging

在互联网世界中，几乎所有的信道都是不可靠的。 消息消失。 连接中断。

如果没有可靠的消息传送标准，Web 服务应用程序开发人员必须将这些功能构建到其应用程序中。 基本方法和技术已得到充分理解，例如许多操作和中间件系统确保消息具有唯一标识符、提供序列号，以及在消息丢失时使用重新传输。 如果应用程序 Web 服务开发人员在其应用程序中实现这些模型。 它们可能会做出不同的假设或设计选择，因此，如果有任何可靠的消息传送，则很少。

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging 定义机制，使 Web 服务能够确保通过不可靠的通信网络传递消息。

WS-ReliableMessaging 确保服务实现可互操作的方法，并使运行时供应商能够通过提供实现协议的服务来简化应用程序开发。 这显著 简化了应用程序开发任务的。 然后，业务逻辑的错误条件要少得多。

最后，该行业有一组丰富的面向消息的中间件，用于可靠地路由和分发消息。 每个实现都使用专有协议。 WS-Reliable 消息传送协议允许不同的操作和中间件系统可靠地交换消息。 因此，它支持将两个不同的基础结构桥接到一个逻辑上完整的端到端模型。

3.7 事务

复杂的业务方案可能需要多个参与方来交换多组消息。 例如，一组金融机构建立了涉及保险单、年金、支票账户和经纪账户的金融服务。 参与者之间交换的多个消息构成逻辑“任务”或“目标”。

为取得成功，各方必须能够：

1. 启动新的协调任务。
2. 将操作与其逻辑任务相关联。 双方可能会同时为不同的客户设置多个帐户。
3. 就计算结果达成一致。 例如，每个人都同意设置财务套餐吗？

WS 协调、WS-AtomicTransaction 和 WS-BusinessActivity 支持这些要求。

3.7.1 WS-Coordination

WS 协调@Page是启动和同意多方多消息 Web 服务任务结果的一般机制。 WS-Coordination 有三个关键元素：

1. 一个称为协调上下文的消息元素，该上下文在计算期间 Web 服务交换的所有消息上流动。 协调上下文包含对协调服务的 WS-Addressing 终结点引用，而协调上下文又包含用于标识正在协调的特定任务的信息。
2. 协调器服务。 协调器服务提供服务（使用 WSDL 描述）提供启动协调任务、终止协调任务、允许参与者在任务中注册以及生成属于组内所有消息的协调上下文。
3. 协调服务还包括在 WSDL中定义的接口，参与服务使用该接口，以便了解协调任务的结果。

接收具有新协调上下文的消息的 Web 服务在上下文中向协调器服务注册，以便接收结果信息。 其他规范可能会增加此框架，以满足域和保证特定要求。

WS-Coordination 是一种常规框架和功能。 WS-AtomicTransaction 和 WS-BusinessActivity 扩展此框架，使分布式计算中的参与者能够可靠地确定结果。

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction 定义了一组特定的协议，这些协议插入 WS-Coordination 模型以实现传统的两阶段原子事务协议。 请务必注意，原子的双相模型仅适用于所涉及的服务。 网站或基础结构产品/服务可能会播发两阶段提交，但使用一些其他企业内模型，例如补偿或版本控制。 这种自由使简单的两阶段提交模型更适用于长时间运行的 Internet 计算。

3.7.3 WS-BusinessActivity

WS-BusinessActivity 定义了一组特定的协议，这些协议插入 WS-Coordination 模型以实现长时间运行的基于补偿的事务协议。 虽然BPEL4WS定义业务流程的事务模型，但它 WS-BusinessActivity 指定相应的协议呈现。 这同样是 Web 服务规范的可组合性示例。

3.8 服务组合

Web 服务分层中最上面的元素是 服务组合。 服务组合允许开发人员“撰写”服务，这些服务交换 SOAP 消息并在 WSDL 中定义其接口，并将 WS-Policy 集成到聚合解决方案中。 聚合是一个组合的 Web 服务。

3.8.1 BPEL4WS

Web 服务（BPEL4WS） 规范 业务流程执行语言支持服务组合。 它使开发人员能够定义一组共同实现共享业务解决方案的 Web 服务的结构和行为。 服务集的每个元素都使用 WSDL 和 WS-Policy 定义其接口。 组合解决方案本身是一个 Web 服务，它支持 HTTP/SOAP 消息，并使用 WSDL 和 WS-Policy 定义其接口。

合成具有三个方面：结构、信息 和 行为。 BPEL4WS 引入了三个支持每个组合方面的构造。

partnerLink 定义复合服务和参与整体解决方案的 Web 服务之间的命名关联。 复合服务和参与服务使用 WSDL 和 WS-Policy 定义彼此的接口。 例如，制造公司和供应商之间的关联。

composition 与合作伙伴之间的 partnerLink 概念和 WSDL/WS-Policy 接口定义服务组合 结构。 它们定义协作形成构成的服务类型，以及它们与哪些保证级别交换的消息（安全、事务等）

BPEL4WS还支持定义服务组合 信息。 BPEL4WS定义变量的概念。 复合服务定义一组变量，每个变量都有一个 XSD 定义。 特定服务的当前状态是其变量的状态。 这定义接收或发送的消息。

最后，BPEL4WS支持通过 活动的概念来定义复合服务的行为。 BPEL4WS定义的服务是一组活动或“步骤”，用于定义服务的行为。 最基本的活动是向合作伙伴发送消息或从合作伙伴接收消息。 每个消息对应于一个变量。 BPEL4WS支持在变量之间移动数据。

BPEL4WS活动的一个关键方面是，BPEL4WS通过允许控制使用非确定性行为，为定义服务的外部可见（公共）行为提供特殊支持。 例如，在接受 PO 的决策过程中以特定方式执行信用检查可能是供应商的私人事项。 BPEL4WS允许通过从流程说明中删除信用检查行为来隐藏决策过程，但显示对 PO 的响应可能是接受或拒绝。 这种类型的 抽象 流程可与 WSDL 结合使用，以定义业务合作伙伴与垂直行业域（如供应链）之间的可互操作业务协议。

BPEL4WS还支持多种控制活动执行流的方法。 其中包括排序和基于图形的流。 BPEL4WS支持变量的谓词，以确定复合服务遵循哪些控制路径。

总之，BPEL4WS对以前定义的 Web 服务规范进行了两个补充。

1. BPEL4WS扩展了 WSDL 和描述服务的 WS-Policy 支持。 BPEL4WS支持将 Web 服务合并为聚合服务，以及记录服务之间的关联，例如信息流和行为。 这为支持 Web 服务协作设计的高级层工具之间的互操作性提供支持。
2. BPEL4WS是一种 执行语言。 BPEL4WS 允许开发人员完全指定复合 Web 服务的行为。 IBM、Microsoft和其他合作伙伴将提供执行BPEL4WS文档的环境，并支持与合作伙伴绑定的设计和执行时间。

实践中的 4.0 Web 服务 - 示例

以下方案演示如何结合使用 WS 规范来创建解决实际需求的 Web 服务。 此方案提供了一个示例，说明由于不同 WS 规范的可组合性，开发人员可以使用强大的功能。

本方案中介绍的 Web 服务是为 2003 年 9 月 17 日举行的技术联合 IBM-Microsoft 演示而创建的。 它们用于创建可互操作、安全、可靠且事务处理的应用程序;这跨越了组织边界。

该演示演示了一个运行的示例，演示了汽车经销商从汽车制造商订购部件的联合订单处理和供应商托管库存（VMI）系统：制造商反过来又从经营多个仓库的供应商处获取部件。 系统中的所有应用程序到应用程序通信都是使用前面描述的 Web 服务协议构建的，并在具有 IBM 和Microsoft软件的一组计算机上运行。

此方案涉及一些最常见的业务方面，即零售业务、批发商和批发商之间的互动。 此方案演示了如何组合不同的 WS 规范，以自动执行业务流程要点，例如：

1. 强制实施安全性的身份验证（WS-Security）
2. 不同组织之间的信任联合（WS-Trust 和 WS 联合身份验证）
3. 交换数据以完成事务（WS-AtomicTransaction）
4. 保证已通过可靠消息传送提交订单（WS-ReliableMessaging）

4.1 第 1 部分：客户体验

此示例始于希瑟，一家名为汽车经销商的公司的员工，登录到她的经销商的安全 Intranet 网站。 此网站是使用标准现成的 Web 技术构建的。 Heather 使用她的浏览器进入该网站。 对站点的访问受密码保护。

图 4. Heather 登录到公司的安全 Intranet 网站，并导航到她自定义的“我的页面”。

希瑟单击“我的页面”。 在后台，应用程序从汽车经销商的库存数据库中收集信息。 如果项的库存级别低于定义的阈值，则会生成一份报告，并将其列在希瑟页面的“警报”显示中。

希瑟看到，她的公司在 WindshieldPro 刮刀刀片上库存较低。

Heather 单击链接，并无缝重定向到 Auto Manufacturer Extranet 上的安全网页，希瑟可以在那里下订单。 体验是无缝的，因为汽车经销商软件基于 Web 服务。 将汽车经销商的 Intranet 与汽车制造商 Extranet 链接的 Web 服务是使用 WS 联合身份验证编写的。 WS-Federation 确保一个站点授予的安全凭据由第二个站点遵守。

下面是其工作原理。 汽车经销商和汽车制造商已同意联合其站点。 WS-Federation 协调一系列服务器到服务器通信。 当希瑟单击 WindshieldPro 链接以转到汽车制造商的网页后，汽车制造商的网页服务器就查询了其授权服务，后者又查询了汽车经销商的授权服务。 汽车经销商授权服务确认希瑟是授权用户，传输凭据以及希瑟经销商的名称，回到汽车制造商的授权服务，该服务授予希瑟访问权限。 这种情况如此无缝地发生，以至于希瑟指出，她已经从一个网页到另一个网页。

Web 服务还会查询汽车制造商客户数据库，以获取链接到 Heather 帐户的信息。 此信息显示在个性化“我的页面”汽车制造商网页中。

图 5：使用 WS-Federated 编写 Web 服务，使 Heather 能够从汽车经销商的个性化页面无缝移动到汽车制造商的个性化页面。

希瑟在汽车制造商 Extranet 上的个性化网页允许她看到她目前没有未结订单：她有一个订单（50个超级Tires）在过境：她的已完成订单列表包括20个单位的CDPlus和50个单位的皮革清洁工。

Heather 单击“创建新订单”，此时会打开一个新页面，并预先填充她想要的部分—WindshieldPro 擦除器边栏选项卡和订购日期。 她需要输入的只是数量。 完成订单所需的所有其他信息都从自动制造商数据库填充。

图 6. 订单很容易放置，因为大部分订购数据已经从热瑟的文件导入了汽车制造商客户数据库。

Heather 提交订单，并搜索要购买的其他项目，或单击“注销”结束会话，并阻止其他人从无人参与的计算机下订单。

请注意，使用 WS-Federation 撰写 Web 服务时，汽车经销商和汽车制造商都提供较低的管理成本和端到端安全性。 如果没有这种技术，汽车制造商必须维护所有授权经销商员工及其密码的列表。 这成本高昂，容易出错，并降低应用程序的安全性。

例如，如果 Heather 退出了她的工作，她的用户帐户将在汽车经销商处删除。 但是，如果经销商的管理员忘记联系汽车制造商，她将继续有权访问购买网站。 对于 WS 联合身份验证，这不是一个问题，因为唯一必须更改的系统是汽车经销商的标识提供者服务。 汽车制造商的系统（应用程序和授权服务）对 Heather、她的用户名或密码没有天生的了解。

4.2 第 2 部分：供应商体验

虽然希瑟从汽车制造商订购了 WindshieldPro 刮刀刀片，但自该公司实际制造自己的刀片以来，已经半个世纪了。 WindshieldPro 刮刀刀片来自供应商供应商。

Tony 是供应商的销售代表，他首先登录到供应商的 Intranet，就像希瑟登录到汽车经销商 Intranet 一样。 但是，Tony 没有使用标准 Web 浏览器，而是适用于内置支持 Web 服务的 Windows 应用程序。

图 7. Tony 在供应商 Intranet 上的个人页面提醒他检查其主要客户之一汽车制造商的订单和库存。

当 Tony 单击以检查订单和库存时，他的应用程序使用 Web 服务来请求允许 Tony 访问的库存数据。

此应用程序级别的 Web 服务请求数据的一个关键方面是，它由 WS-Federation 组成，用于验证他对汽车制造商 Extranet 的访问权限。

Web 服务将结果返回给供应商的页面，其中按产品类型和当前库存计数显示。

图 8. Web 服务使用来自汽车制造商库存数据库的库存数据填充 Tony 的供应商页面。 该请求是使用 WS-Security 和 WS 联合身份验证撰写请求的安全。

供应商已与汽车制造商签订了实时购买协议。 一旦库存低于 20，Tony 有权作为供应商托管库存（VMI）的一部分提供自动再供应订单。 Tony 单击 WindshieldPro 以下订单。 Tony 和 Auto Manufacturer 之间的所有消息都受到保护，因为应用程序受由由 WS-Security 保护组成的 Web 服务支持。

图 9. 与汽车制造商的实时协议允许 Tony 代表公司输入订单。

Tony 的应用程序为他提供了一个屏幕，用于通过汽车制造商采购订单向供应商创建请求。 Tony 订购了 50 个 WindishieldPros 擦除器，直接寄送到汽车制造商。

当 Tony 单击“确定”时，仓库服务（一个包含 WS-AtomicTransactions、WS-Security 和 WS-ReliableMessaging）的 Web 服务尝试将订单与另一个 Web 服务（从属仓库服务）一起下订单。 如果未立即从仓库服务返回响应（由于临时网络中断），WS-ReliableMessaging 继续重新发送查询，直到收到响应。

当仓库服务收到订单时，它会将其内部中继到公司的两个物理仓库。 由于这涉及到两个仓库之间的数据库，因此 WS-AtomicTransaction 用于确保数据库之间的事务行为。

仓库应用程序将订单划分为从属仓库服务，以确保库存覆盖率，70 个订单% 转到仓库 1，其余 30 个% 转到仓库 2。 主仓库中的根协调器向仓库 2 的根协调器发送一条消息，请求订单的 30%。 仓库 2 的根协调器会检查库存，并向主仓库的根协调器发送一条消息，指出库存不足。

主根协调器知道没有足够的库存取消整个事务，并向 Tony 的 Web 服务应用程序发送一条消息，指示状态、库存级别以及该事务已取消。 根协调器开始回退事务，完成后返回到仓库，表示该事务已取消。

Tony 使用当前的库存知识，向仓库发送另一个请求。 根协调器与其他事务实体（其他事务的控制器）协调，并将此请求提交到 2 个仓库，执行与之前相同的过程。 我们使用 WS-Security 对整个邮件正文进行签名，因此无论你在哪个域中都知道你安全。

现在，根协调器提交事务、锁定资源并完成事务。 发送回 Tony 的消息，指示事务已成功完成。

WS-AtomicTransaction 包含这些消息中的 WS-ReliableMessaging 和 WS-Security，以提供完整的企业就绪分布式系统。

5.0 结论

IBM、Microsoft和我们的合作伙伴正在开发 Web 服务规范，这些规范可用作新一代强大、安全、可靠、交易的 Web 服务的构建基块。

这些规范以模块化和可组合的方式设计，使开发人员能够仅利用所需的功能。 这种“类似组件”的可组合性将允许开发人员以简单灵活的方式创建功能强大的 Web 服务，同时仅引入特定应用程序所规定的复杂性级别。

这项技术将使组织能够使用 Service-Oriented 体系结构（SOA）轻松创建应用程序。 此外，IBM 和 Microsoft 还演示了安全、可靠、交易的 SOA 应用程序，这些应用程序说明了可以使用此方法创建的业务流程的丰富性。 此外，这些演示已在由 IBM WebSphere 和 Microsoft .NET 软件组成的异类环境中在联合安全环境中运行。

我们预计这些 Web 服务技术将在操作系统、中间件中提供，这些工具将使开发人员能够更轻松地使用这些技术。 看到开发人员和组织使用这些系统创建下一代基于 Web 服务的解决方案的应用程序将令人振奋。

6.0 确认

我们希望承认以下为这些想法做出贡献的个人：（字母）托尼·安德鲁斯、鲍勃·阿特金森、基思·巴林格、 Don Box、John Brezak、Allen Brown、Felipe Cabrera、Erik Christensen、George Copeland、Michael Coulson、Giovanni Della-Libera、Brendan Dixon、Mike Dusche、Colleen Evans、Max Feingold、Jeff Frey、Henrik Frystyk Nielsen、Praerit Garg、Gari Gazitt、Scot Gellock、Josh Gray、 马丁·古金、玛丽安·洪多、德斯特里·胡德、埃菲姆·胡迪斯、托马斯·詹丘克、吉姆·约翰逊、瑞安·约翰逊、戈帕尔·卡基瓦亚、 Chris Kaler、Johannes Klein、Scott Konersmann、Brian LaMacchia、Dave Langworthy、Andrew Layman、Paul Leach、Al Lee、Frank Leymann、Rodney Limprecht、Joe Long、Steve Lucco、John Manferdelli、Ashok Malhotra、Jonathan Marsh、Steve Millet、Angela Mills、Tony Nadalin、Martin Nally、Kara Norsworthy、 斯特凡·法尔斯、斯科特·罗宾逊、约尔丹·鲁斯科夫、苏贾伊·萨尼、杰夫·施利默、奥利弗·夏普、亚瑟·肖胡德、丹·西蒙、杰夫·斯佩尔曼、基思·斯托比、萨蒂什·撒特、罗伯特·瓦比、艾略特·瓦古德、理查德·沃德、桑吉瓦瓦纳、赫维·威尔逊、埃里克·齐达。