级别： 初级 Donald F. Ferguson, IBM 名士和 IBM Software Group Architecture Board 主席, IBM Corporation
Tony Storey, IBM 名士, IBM Corporation
Brad Lovering, 杰出工程师, Microsoft Corporation
John Shewchuk, Web 服务架构师, Microsoft Corporation
2003 年 11 月 01 日 本文扼要地概述了一组 Web 服务规范，这些规范解决了安全性、可靠性和事务性方面的问题。本文提供了指向实际文档的链接，您可以通过阅读实际文档来更详细地了解这些规范。本文的主要目的是简要地诠释这些规范对我们的顾客提供的价值。本文还描述了这些规范如何相互协作来为分布式应用程序组合稳固的环境。
引言
今天，Web
服务——特指用 Web 服务描述语言（Web Services Description Language，WSDL）描述的、通过
HTTP 发送的、处理 XML 编码的 SOAP
消息的分布式服务——正得到广泛的部署（请参见“XML、SOAP
和 HTTP”补充说明）。Web
服务可用在各种各样的应用程序集成环境中：从简单的（特别是防火墙后面的）数据共享到大规模的 Internet
零售和货币交易。
Web
提供了软件组件之间的互操作性，这些软件组件可以在不同的企业之间进行通信，并且可以驻留在不同的基础架构中。这解决了顾客、软件开发人员和合作伙伴所面临一个最重要的问题。HTTP 和 SOAP
提供了通信和消息的互操作性。WSDL
提供了消息的描述，以支持开发工具之间的互操作性；它凭借交换接口定义的能力来完成通信互操作性。
一组基本的 Web 服务规范使顾客和软件厂商能够解决一些重要的问题。在这些规范成功的基础上，许多开发人员和公司准备解决 Web
服务方面更难的问题。Web 服务的巨大成功使开发人员想要从
Web
服务获得更多的能力。由于重要的工具和通信互操作已经成功了，所以开发人员现在期望增强互操作的功能。
除了基本的消息互操作性和接口交换之外，开发人员越来越需要更高级别的应用程序服务互操作。许多商业应用程序运行在这样一种环境中（“中间件”或“操作系统”），这种环境为一些功能（比如安全性和事务处理）提供支持。
IBM、Microsoft
和业界其他一些公司常常需要使 Web
更安全、更可靠且更好地支持事务处理。另外，我们在提供这些能力的同时，还需要保持现在 Web
服务中必不可少的简单性和互操作性。
本文扼要地概述了一组满足这些需要的 Web
服务规范。我们提供了指向实际文档的链接，您可以查阅这些规范，以了解更详细的信息。本文的主要目的是简要地诠释这些规范给我们的顾客提供的价值。我们还描述了这些规范如何相互协作，以组成分布式计算的稳固环境。
我们面临一个关键的设计挑战：我们如何才能够赋予 Web
服务新的安全性、可靠性和事务处理能力而又不增加更多不必要的复杂性。
 |
XML、SOAP 和 HTTP
现在，XML、SOAP 和 HTTP
是通用的术语，但是在许多方面，它们的用法已经超出了其最初的缩写词的含义。为了完整起见，在此列出这些缩写词：XML -
eXtensible Markup Language（可扩展标记语言）、SOAP - Simple Object Access
Protocol（简单对象访问语言）和 HTTP - HyperText
Transfer Protocol（超文本传输协仪）。
|
|
可组合的服务
正如我们在制订 SOAP
和 WSDL 规范时所做的那样，IBM、Microsoft
和我们的合作伙伴在定义 Web 规范的过程中遵循了
可组合性（composability）的设计原则。我们所采用的方法基于在定义 Web
服务规范 Web 服务规范过程中遵循的
可组合性设计原则。我们制订的每个规范都满足某个方面的直接需要，而且它本身是有价值的。例如，开发人员可以采用可靠的消息传递来简化他们的解决方案的开发，也可以采用 BPEL4WS
来定义他们的服务组成。而当每个规范都各司其职时，它们就设计成能相互组合和协同使用。
我们用术语
可组合性来描述那些可以进行组合以提供更强大的功能的独立规范。操作系统和中间件厂商可以支持组合的功能，例如，这些厂商可以为传输
BPEL4WS
流程集成可靠消息传递的支持。这个例子组合了两个独立的规范，使得不需要在流程设计的过程中处理消息传输错误，从而简化了传输流程的开发。
可组合性使得能够
逐渐增加使用或
循序渐进发现新概念、工具和服务。开发人员需要做的仅仅是学习和实现一些必要的东西。解决方案的复杂性的增加只是因为问题的需求增加，而不是由所谓的技术“膨胀”导致的。
可组合性已经并且将继续是 Web
服务的主要设计目标之一。在过去几年中，我们已经制订了大多数基本 Web
服务规范（SOAP 和 WSDL）以从内在支持组合。Web
服务的基本特征之一就是规则的、多部分的消息结构。这种结构使新功能的
组合成为可能。可以以不改变现有功能的处理的方式将支持新服务的新消息元素添加到消息中。例如，单独添加事务处理标识符和可靠消息传递的顺序号是可能的。两个扩展不会彼此冲突，并且与现存的消息结构兼容。
图
图1展示了一个简单的 Web 服务消息，它包含 WS-Addressing、WS-Security 和 WS-ReliableMessaging
元素。请注意， WS-Addressing、WS-Security 和 WS-ReliableMessaging
元素是独立的，并且这些元素可以单独使用而不改变其他元素的处理。
这种特征使得安全性、可靠性和事务处理能够根据
可组合
的消息元素进行定义。
组合的观念还便于创建一组定义明确的特定可组合 Web
服务来支持安全性、可靠性等等。这些定义明确的服务指定支持更高级的 Web
服务功能所需的服务的行为。在 WS-Trust
中定义的安全令牌服务（Secure Token Service）就是这样的一个例子，它签发和验证消息中的安全性元素。
此外，让服务消费者能够决定支持和需要的服务保证是非常重要的。服务必须文档化它们的需求并支持事务处理、安全性、可靠消息传递等等。WS-Policy
使 Web 服务能够逐渐增加 WSDL
来记录它们支持或需要的事务处理、安全性和可靠性功能。WSDL
和 WS-Policy
使得能够组合服务的描述。这同样使得其他方能够理解在与服务交互时需要部署什么消息元素和更高级的服务。
实践中的组合的示例
图2展示了实践中的组合。在这个概览中，顾客和提供商使用
Web 服务处理订单。
在构建这些 Web
服务的过程中，开发人员使用 WSDL
和相关的文档来描述它们的业务接口。这些 WSDL
文档描述顾客 Web 服务和提供商 Web
服务将处理的一组消息，例如从顾客传递到提供商的SubmitPurchaseOrder（SubmitPO）消息。这显示在图2的顶部。一旦应用程序的核心部分就位了，开发人员就可以支持附加的能力，这里他们决定使订单处理事务化。为达此目的，他们把下列元素组合成现有的结构：
- 服务将描述它们对事务处理的支持的 WS-Policy
文档与它们的服务的 WSDL
描述相关联。请注意，虽然这些策略语句增加了，但是并没有从根本上改变现有的业务功能。
- 为了支持事务化处理，服务添加了一个附加的元素来描述组合在一起的事务，而没有从根本上改变现有的应用程序消息。
- 当提供商服务接收包含事务元素的消息时，它使用此信息与称为协调器的
Web 服务进行通信，后者支持事务处理功能。另外，附加的 Web
服务只添加到解决方案，而不需要修改对现有业务功能的描述。
- 最后，服务可以实现附加的操作来支持与事务协调器服务的集成。
在前面的图中，突出显示了这些附加的元素。
该模型是递增的和可组合的，因为：
- 添加新的功能可以独立于添加其他的功能进行。
- 添加功能并没有干扰现有的消息、消息处理逻辑或
WSDL。
可组合性是一个越来越重要的设计原则，不过这种方法一直没有得到很好的理解。虽然各个 WS
规范定义了单个元素和服务如何进行互操作，但是本文打算概述如何把一些规范组合起来以提供更复杂的可互操作 Web
服务。
Web 服务：面向服务的体系结构
在最近几年中，我们目睹了一阵以 Web
服务为中心的活动。对于所有这样的活动，回过头来问一问“为什么”是非常重要的。当然，Web
服务并没有提供新的计算能力——毕竟，Web
服务仍然运行在现有的计算机上，执行一组相同的指令，并且访问相同的数据。而且，Web
服务协议在许多情况下事实上增加了特定任务的协议开销。我们之所以看重 Web
服务的主要原因在于，Web
服务非常适于启用面向服务的体系结构（Service-Oriented Architecture，SOA）。在使用 Web
服务构建解决方案时，解决方案由一些自治的服务组成，这些自治的服务通过
URL 进行标识，带有使用 WSDL 文档化的接口，处理定义明确的 XML
消息。SOA 是对实现解决方案的面向对象（ object-oriented，OO）、过程性和以数据为中心的方法的自然补充。实际上，在创建 SOA
系统时，一般使用这些技术中的一种或多种来构造单个服务。
面向服务的体系结构不同于面向对象和过程性系统的一个关键方面是：
绑定（binding）。服务根据它们提供
什么功能和他们
如何提供这些功能来进行交互。而面向对象和过程性系统根据类性或名称把元素链接在一起。以下几节将更详细地对此进行讨论。
通过
Schema 和合同而非类型描述服务
与以前的系统不同，Web
服务模型没有使用共享类型（需要通用的实现）的概念。相反，服务的交互是完全根据合同（用于消息处理行为的
WSDL/BPEL4WS）和 Schema（用于消息结构的 WSDL/XSD）。这使得服务能够描述它可以发送和/或接收的消息的结构以及对这些消息的顺序约束。结构和行为之间的分离以及对这些特征进行的显式和机器可验证的描述，可以简化异质环境中的集成。
此外，这种信息充分地描述了服务接口的特征，这样应用程序集成就不需要共享的执行环境来创建消息结构或行为。
面项服务的模型假定一个完全分布式的环境，在这种环境中，将
Schema 和/或合同中的改变传送到与服务交互的所有各方是非常困难的，如果不是不可能的话。面向服务意味着
Schema
和合同应该保持向后兼容，并且可以包含不完全为特定处理系统理解的信息。
由于这个原因，为用在面向服务的设计中而设计的合同和
Schema 能够比面向对象的接口更灵活。特别是，服务可使用像 XML
元素通配符（例如，xsd:any）、Schema 扩展和可选的 SOAP
头部来以不中断部署的应用程序的方式发展服务。这些特征对于
Web 服务的可组合形式非常关键的。
服务兼容性多于类型兼容性
过程性设计和面向对象设计一般把类型兼容与语义兼容等同起来。面向服务为决定兼容性提供了更加丰富的模型。结构兼容性是基于合同（WSDL
和 BPEL4WS（可选））和 Schema（XSD）的，并且可以进行验证。此外，WS-Policy
的出现使得可以对服务之间服务保证的兼容性进行附加的自动分析。这是根据 WS-Policy
语句形式的能力和需求显式断言完成的。
使用 WS-Policy，服务可以以机器可读的策略表达式（包含断言组合）的形式描述它们的服务保证能力和需求。这允许服务根据它们“如何”或“以什么样的质量”提供它们的合同来相互选择。
策略断言通过稳定的且全局惟一的名称进行标识，不管把策略断言应用到哪一种服务，这种名称的含义在时间和空间上都是一致的。策略断言也可以带有参数来限定断言的确切解释。
面向服务假定坏的事情可以并且必将发生
以前的一些用于分布式应用程序的方法显式地假定通用的类型空间、执行模型和过程/对象引用模型。其实，“记忆中”的编程模型都可称为分布式系统模型。
面向服务仅仅假定服务自动执行，而没有本地执行或通用的操作环境的观念。由于这个原因，SOA
显式地假定通信、可用性和类型错误都是共同的。
为了维护系统的完整性，面向服务的设计显式地依赖于各种技术来处理异步和部分失败模式。诸如异步消息传递、事务处理、可靠消息传递和冗余部署都是面向服务的系统中的标准。
此外，与以前的模型不同的是，面向服务假定传入消息不仅可以是结构不良的，而且它可以出于恶意或完全意想不到的目的进行传递。所以面向服务的系统通过把提供证据的责任放到
所有的消息发送者身上来保护自己，它们需要应用程序证明已经授予发送者所需的权限。与服务自治的观念相一致，面向服务的体系结构一般依赖于行政管理的信任关系，从而避免了使用传统的
Web 应用程序中常见的通过服务验证的机制。
面向服务使得能够灵活地绑定服务
面向服务的体系结构（SOA）的核心概念之一就是灵活地帮定服务。更传统的过程性模型、组件模型和对象模型通过引用（指针）或名称绑定组件。SOA支持更动态地发现服务实例来提供请求者所期望的接口、语义和服务保证。
在过程性系统或面向对象的系统中，调用者一般根据它导出的类型或共享的名称空间来查找服务器。而在 SOA
系统中，调用者可以搜索注册中心（比如 UDDI）来查找服务。
- 该文档是与调用者的需求兼容的消息。兼容性可以通过 WSDL
出现，也可以通过来自知名的 XML Schema 的匹配消息出现。
- 该文档支持调用者所需的服务保证。例如，调用者可能需要某种安全性或事务处理方法。
服务实现的松散绑定使选择行为的实现成为可能，这可以用于解决各种各样的需求问题。例如，可供选择的实现可能对应于供应链上可供选择的厂商，这些厂商使得服务能够更快地响应改变的市场条件。同样，从地理上讲，可供选择的实现可能是分布式数据中心，这些数据中心使得服务能够容许灾难的出现。
Web 服务规范和功能
这一节概述 Web
服务规范。
Web
服务的可组合方法
这一部分简要地描述可用的 Web
服务规范。我们将阐述它们对解决方案提供商的价值、它们在更大的体系结构中的角色、以及它们如何互为补充。
下图提供了由 IBM、Microsoft 和其他公司发布的 Web
服务规范的分组。请注意，该图并没有表示组与组之间严格的分层；相反，它的目的是直观地展示各个功能区之间的关系。例如，消息
Security 不需要 Description，而同样地，对于 Messaging，Description
是有用的开发时概念。
图3. Web 服务 —— 安全、可靠、事务化
基础
—— 传输协议和消息传递
如果我发给您一封用法语写的信，而您希望用英语进行电话交谈，那么我们将无法沟通。Web
服务的互操作性面临着同样的问题；我们可以通过提供一组通用的传输协议和消息传递技术来解决这个问题。
另外，为了确保这些技术在实践中是有效的，IBM、Microsoft
和其他公司创立了 Web 服务互操作性组织（Web Services Interoperability Organization，WS-I）。最近，WS-I
发布了基本概要，正式文档化了可互操作的 Web
服务传输协议和消息传递机制。
3.2.1 传输协议 —— HTTP、 HTTP/S,、SMTP
这一组规范定义了在 Web
服务之间传送原始数据的核心通信机制。
其中包括HTTP、 HTTP/S, 和简单邮件传输协议（Simple Mail Transport Protocol，SMTP）。Web
服务实现可以另外支持其他的传输协议，但是支持标准的、可互操作的协议是非常重要的。
3.2.2 消息格式 —— XSD
下一组规范为编码传输的
Web
服务消息定义了可互操作的机制。传输在服务之间传送“字节”块。只有当参与者能够把字节转换成它们的应用程序可以处理的有效数据结构时，这才是有用的。
消息传递规范组定义了如何正确地安排消息的格式。XML
and XML Schema 定义提供了抽象约定消息（数据）结构的机制。SOAP
定义了表示 XML 消息的标准编码方法，其中，XML
消息用服务通过传输交换的字节信息进行表示。
3.2.3 WS-Addressing
消息和响应都发送到某处和来自于某处。WS-Addressing
提供了一种可互操作的、传输独立的方法来标识消息发送者和接收者。WS-Addressing
还提供了一种更细粒度的方法来标识应该发送和接收消息的服务中的特定元素。
现在，大多数使用 Web 服务的系统可以编码 Web
服务的目的地（带有一个放在 HTTP 传输协议中的 URL）。响应的目的地是由返回的传输地址确定的。这种方法建立在
HTTP 的基本浏览器-服务器模型的基础上。
使用现在的方法，源信息和目的信息都不是消息本身的一部分。这可能会产生几个问题。如果传输连接终止（例如，在响应要等很长的时间而连接超时的情况下）或消息是由中介（比如，防火墙）发送的，那么信息可能会丢失。
WS-Addressing
提供了一种机制来把目标信息、源信息和其他重要的地址信息都直接放在 Web
服务消息中。简而言之，WS-Addressing
将地址信息从任何特定的传输模型中分离出来。
在许多情况下，消息把目标直接对准服务，而消息中的地址信息可以用
URL
简单地进行描述。但是在实践中，我们常常发现，消息把目标对准了服务中的特定元素或资源。例如，协调服务可能正协调许多任务。协调器需要把大多数传入消息与它管理的任务实例而非协调服务本身关联起来。
WS-Addressing
为寻址服务所管理的实体提供了一种简单但却非常强大的机制，称为
端点引用（endpoint reference）。虽然这样的信息可以以特别的方式在服务的 URL
中进行编码，但是端点引用提供了一个标准的 XML
元素，它使得能够采用一种结构化的方法来编码这样的细粒度寻址。
对寻址进行细粒度的控制与对消息源和目的地进行传输中立的编码，使得 Web
服务消息能够跨各种各样的传输通过中介进行发送，并且使得能够采用异步和扩展的持续时间两种通信模式。
WS-Addressing
还使发送者能够指示应该以传输独立的方式把响应发送到哪里。对消息的响应可以不必发送到发送者。例如，在 HTTP
中，由于没有 WS-Addressing，所以指定应该把响应发送到别处是不可能的。
这些对消息传递模型的增强使得 Web
服务能够用于支持许多业务场景。例如，某些银行业务为了获得批准需要在某些步骤上进行复核。通常在每个具体位置都有许多活动的任务实例。WS-Addressing
提供了一种通用的机制来把传入和传出消息与特定的任务关联起来。服务使用的这些机制对于那些通过端点引用使用服务的人来说是透明的。
传输和消息规范允许 Web
服务使用消息进行通信。但是，参与者如何知道消息是什么呢？Web
服务如何文档化或描述它发送和接收的消息呢？使用 Web
服务需要理解 Web 将使用和产生的消息——Web 服务的
接口。规范的描述组使 Web
服务能够表达它的接口和功能。
除了消息互操作性之外，这些规范还启用了
开发工具互操作性（development tool interoperability）。描述规范提供了一个标准的模型，使得来自不同厂商的各种工具能够协同支持开发人员。.以与 Web
服务把合作伙伴从实现和基础体系结构选择中分离出来的相同方式，描述规范把合作伙伴从开发工具选择中分离出来。
3.3.1 WSDL
Web 服务描述语言（Web Services Description Language，WSDL）是这一组中的基础规范。XML Schema
允许开发人员和服务提供者定义数据结构（例如订购单）和消息（例如 CreatePO 消息）的 XML 类型。WSDL
允许 Web
服务文档化它接收和发送的消息。换句话说，服务根据它接收和发送的消息执行什么“动作”或“功能”。
WSDL
为各种各样的消息交互模式提供了支持。它支持单向输入消息，这些单向输入消息可以没有响应，没有请求/响应，并且可以单向发送（有或没有响应）。后两种模式使服务能够指定它需要的其他服务。
提议的 WSDL
增强支持文档化服务支持的协议和消息格式、以及服务的地址。
3.3.2 WS-Policy
WSDL 和 XSD
定义往往没有提供调用
Web 服务的足够信息。WSDL 和 XSD
定义了服务的接口语义，但是它们没有表示关于服务如何提供它的接口或服务需要调用者的什么东西的信息。例如，服务需要安全性或实现事务吗？
WS-Policy
使服务能够指定它需要服务提供者的什么东西和它如何实现它的接口。WS-Policy
对在服务更高级的功能操作上实现互操作性是至关重要的。安全性、事务处理、可靠消息传递和其他规范需要具体的 WS-Policy
Schema。这些规范允许服务描述它们期望从调用者得到或提供给调用者的功能保证。
WS-Policy
框架提供了定义策略表达式的基本模型。
WS-Policy
支持聚合策略语句的语法，并且允许构造更灵活和更完整的策略组。
WS-PolicyAttachment 指定了如何使策略组与 XML
消息和 WSDL 元素（操作和 portTypes）相关联。
WS-Policy 和 WS-PolicyAttachment
一起提供了该框架。各个规范定义了特定于它们的领域的策略语句和 Schema。
最后，
WS-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
收集关于一组服务的元数据并且使得可以以可搜索的方式使用该信息是非常有用的。这样的元数据聚合是一个很好的存储库，企业可以在其中发布它们提供的服务，描述它们的服务的接口，采取特定领域的分类法。通用描述和发现接口（Universal Description and
Discovery Interface，UDDI）规范定义了元数据聚合服务。
解决方案在设计时可以查询 UDDI
来找到与它们的需求相匹配的服务。例如，开发人员可以在定义他们的 BPEL4WS
工作流时使用这些服务。解决方案在运行时也可以查询 UDDI。在这种场景中，调用者“知道”它调用的接口，并且搜索与它的功能匹配的或由知名合作伙伴提供的服务。
请注意，在可能用来填充带有元数据的 UDDI
服务的机制中，有一种必须通过 WS-MetadataExchangeNote
从服务获取元数据。
服务保证
Web
服务之所以引起人们如此大的热情，在某种程度上是因为它们跨接完全不同的系统的能力。开发人员已经使用传输、消息传递和描述的基本功能提出了许多功能完备的解决方案。然而，为了被创建更强大的集成解决方案的开发人员接受，Web
服务必须提供功能来确保与更传统的中间件解决方案相同级别的
服务保证（service assurances）。仅仅交换消息是不够的。应用程序和服务驻留在中间件和系统上，这些中间件和系统非常有价值的级别更高的功能，比如安全性、可靠性和事务化操作。Web
服务必须为这些功能之间的互操作性提供一种机制。
安全性
这个规范家族对于跨组织 Web
服务是至关重要的。这些规范支持验证和消息完整性、机密性、信任和隐私。它们也支持不同组织之间的安全联盟。
3.5.1 WS-Security
WS-Security 是安全 Web
服务的基本构件（building block）。现在，大多数分布式 Web
服务依赖于安全性功能的传输级别支持。例如 HTTP/S 和 BASIC-Auth
验证。这些方法提供了最低限度的安全通信。然而，它们提供的功能级别大大低于现有中间件和分布式环境所提供的。
下面两个例子显示了 BASIC-Auth 和 HTTP/S
的不足。
- A 发送消息到服务 B。B
对消息进行部分处理后将其转发到服务 C。HTTP/S 可以提供 A-B
和 B-C 之间的验证、机密性和完整性。然而，C 和 A
不能彼此验证，也不能对 B 隐藏信息。
- 对于需要使用 BASIC-Auth 进行验证的 A、B 和
C，它们必须共享复制的相同用户和密码信息。在许多场景中，这是不能接受的。
WS-Security 解决了这些问题。它支持：
- 已签署和加密的安全性令牌。Signed, encrypted security tokens. A can generate a token that C can
verify as having come from A. A 可以生成一个令牌，C
可以将此令牌作为来自 A 的令牌加以验证。B cannot forge the token.
B 不能伪造该令牌。
- A
可以签署已选择的元素或整个消息。这允许 B 和 C 确认该消息自 A 发送它以来没有更改过。
- A
可以密封该消息或已选的元素。这确保了只有为这些元素预定的服务才可以使用该信息。这阻止了 B
看到为 C 预定的信息，反之亦然。
WS-Security 使用现有的安全性模型（Kerberos、X509
等等）。这些具体地定义了如何以可互操作的方式使用现有的模型。没有
WS-Security，多跳（multi-hop）、多方的 Web
服务计算就不可能是安全的。
3.5.2 WS-Trust
安全性依赖于预先确定的信任关系。Kerberos
之所以有效，是因为参与者“信任” Kerberos 密钥分配中心（Kerberos Key Distribution
Center）。PKI 之所以有效，是因为参与者信任根验证机构。WS-Trust
定义了建立和验证信任关系的可扩展模型。
WS-Trust 中的密钥概念是
安全性令牌服务（Security Token Service，STS）。STS
是著名的 Web
服务，它签发、交换安全性令牌，并且检查安全性令牌的有效性。WS-Trust
允许 Web
服务建立和约定它们“信任”哪些安全性服务器，并且允许它们依赖于这些服务器。
STS
之所以得到了广泛的应用，是因为它可以用于签发安全性令牌来作出各种各样的断言。在许多情况下，它将用于签发相同的断言（不过格式不同）。例如，STS
可能签发 Kerberos 令牌，断言密钥持有者是 Susan，并且它可能是根据信任的证书机构（Certificate
Authority）签署的 X.509
证书来这样做的。这使得组织能够使用不同的安全性技术来结成联盟。STS
也可能根据传入的断言标识声明的安全性令牌，来签署安全性令牌，断言密钥持有者是组 BankTellers
中的某个成员。
3.5.3 WS-SecureConversation
一些 Web
服务场景只需要简短零星的少数消息的交换。WS-Security
很容易支持这种模型。还有一些场景需要在 Web
服务之间进行长期的多消息交谈。WS-Security
也支持这种模型，但是解决方案不是最佳的。
在这些场景中，有两种次优的 WS-Security
的用法：
- 重复使用计算上昂贵的加密操作，比如公共密钥有效性检查。
- 使用相同的加密钥发送和接收许多消息，提供更多允许强力攻击以“破坏代码”的信息
由于这些原因，诸如 HTTP/S
之类的协议就使用公共密钥进行简单的商议，以定义
交谈专用密钥（conversation specific keys）。这种密钥交换提供了更有效的安全性实现，并且减少了使用一些特定的密钥进行加密的信息的数量。
WS-SecureConversation 对 WS-Security
提供了类似的支持。参与者常常使用带有公共密钥的 WS-Security
来开始“交谈”或“会话”，并且使用 WS-SecureConversation
约定签署和加密信息的会话专用密钥。
3.5.4 WS-Federation
WS-Federation
允许一些组织建立一个虚拟的安全性区域。例如，旅行代理、航空公司和旅馆链可以建立这样的联盟。“进入”联盟中任一成员的终端用户可以有效地进入所有的成员。WS-Federation
通过 WS-Trust 和 WS-SecureConversation
拓扑之间的协议为给定的安全性定义了几种模型。
另外，顾客在与企业打交道时常常有“特性”。例如，优先选择靠窗或过道旁的座位或中型汽车。WS-Federation
允许成员建立联合的特性空间。这允许参与者在安全控制的条件下访问每个成员关于终端用户的特性信息。
关于个人的特性和信息可能秘密存放，因为需要保护人们的隐私，或者因为这些信息给某个成员提供了竞争优势。为了支持这些需求，WS-Federation
支持
假名模型（pseudonym model）。经过旅行代理验证的用户在与航空公司或旅馆交互的过程中使用代理生成的“别名”。这保护了终端用户的隐私和旅行代理因知道用户特性而赢得的竞争优势。
可靠消息传递
在 Internet
世界，几乎所有的信息通道都是不可靠的。消息会丢失。连接会中断。
如果没有可靠的消息传递标准，Web
服务应用程序开发人员就必须将这些功能构建在他们自己的应用程序中。基本方法和技术是很好理解的，例如，许多操作系统和中间件系统可以确保消息有惟一的标识符，提供顺序号，并且在消息丢失时使用重发。如果应用程序 Web
服务开发人员在它们的应用程序中实现了这些模型，他们就可以进行不同的假定或设计选择，而结果却没有什么不同（如果采用某种可靠消息传递的话）。
3.6.1 WS-ReliableMessaging
WS-ReliableMessaging
定义了一些机制，使 Web 服务能够确保 Web
服务在不可靠的通信网络上确保消息的传递。
WS-ReliableMessaging
不仅确保服务实现互操作方法，而且通过提供实现协议的服务使运行时厂商能够更容易地进行应用程序的开发。这大大简化了应用程序开发的任务。因此，业务逻辑有极少的错误情况需要处理。
最后，业界有很多面向消息的中间件，可以用于可靠地路由和分布消息。每个实现都使用专有的协议。WS-Reliable Messaging
协议允许不同的操作系统和中间件系统可靠地交换消息。因而，它支持把两个不同的基础体系结构跨接成一个逻辑上完整的端对端模型。
事务处理
复杂的业务场景可能需要多方交换多组消息。举例来说，几个金融机构提供一种金融产品，涉及保险政策、养老金、经常账户和经纪账户。在参与者之间交换的多个消息构成逻辑上的“任务”或“对象”。
为了成功，参与者必须能够：
- 开始新的协调的任务。
- 使操作与它们的逻辑任务相关联。参与者可以同时为不同的顾客设置多个账户。
- 约定计算的结果。例如，每个人都赞同建立的金融包吗？
WS-Coordination、WS-AtomicTransaction 和 WS-BusinessActivity
支持这些需求。
3.7.1 WS-Coordination
WS-Coordination
是开始和约定多方、多消息 Web 服务任务的结果的通用机制。WS-Coordination
有三个关键元素：
- 称为协调上下文（coordination
context）的消息元素，它在 Web
服务计算时交换的所有消息中传送。协调上下文包含对协调服务的 WS-Addressing
端点引用，而本身又包含用于标识正在协调的特定任务的信息。
-
协调器服务（coordinator service）。协调器服务提供使用
WSDL
描述的服务，这种服务能够开始协调的任务，终止协调的任务，允许参与者在任务中注册，并且产生协调上下文，所产生的协调上下文是一个组内所有消息的一部分。
- 协调服务也包括一个用 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
服务规范的可组合性的例子。
服务组合
在 Web
服务分层中，最上层的元素是
服务组合（service composition）。服务组合使开发人员能够把交换 SOAP
消息以及用 WSDL 和 WS-Policy
定义它们的接口的服务“组合”成聚合的解决方案。该聚合是组合的 Web
服务。
3.8.1 BPEL4WS
用于 Web
服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）规范支持服务组合。它使开发人员能够为共同实现一个共享的解决方案的一组 Web
服务定义结构和行为。这组服务中的每个元素都用 WSDL 和
WS-Policy 定义自己的接口。组合的解决方案本身就是 Web
服务，它支持 HTTP/SOAP 消息并且使用
WSDL 和 WS-Policy 定义其接口。
组合有三个方面：
结构（structure）、
信息（information——和
行为（behavior）。BPEL4WS
引入了三种结构来支持每个组合方面。
partnerLink
定义了参与整个解决方案的组合服务和 Web
服务之间命名的关联。组合服务和参与服务使用
WSDL 和 WS-Policy
定义了它们彼此的接口。制造企业和供应商之间的关联可能就是一个例子。
组合服务和合作伙伴之间的 partnerLink 概念和 WSDL/WS-Policy
接口定义了服务组合的
结构。它们定义协作构成组合的服务的类型、以及它们与哪些级别的保证（安全性、事务处理等等）交换哪些信息。
BPEL4WS 还为定义服务组合的
信息提供了支持。BPEL4WS
定义了容器的概念。组合服务定义了一组容器，其中的每个容器都有一个 XSD
定义。特定服务的当前状态就是它的容器的状态。这定义了它已经接收或发送了什么消息。
最后，BPEL4WS 通过
活动（activity）的概念定义了组和服务的行为。BPEL4WS
定义的服务是一组活动或“步骤”，它们定义了服务的行为。最基本的活动是把消息发送到合作伙伴或从合作伙伴接收消息。每个消息对应一个容器。BPEL4WS
为在容器之间传送数据提供了支持。
BPEL4WS
活动的一个关键方面是，通过控制使用不确定行为，BPEL4WS
为定义服务外部可见的（公共）的行为提供了支持。例如，在接受购买订单（PO）的决策流程中以特定方式进行信用检查的事件可能是供应商的私有事务。BPEL4WS
允许隐藏决策流程，为此，可以将信用检查行为从流程描述中除去，而只是显示，购买订单的响应可能是接收，也可能是拒绝。这种类型的
抽象（abstract）流程可以与 WSDL
一起使用，以支持业务合作伙伴之间或垂直行业领域（比如供应链）的互操作业务协议。
此外，BPEL4WS
还支持几种控制活动的执行流的方法。这些方法包括顺序流和基于图形的流。BPEL4WS
支持容器上的谓词，以确定组合服务遵循哪些控制路径。
总之，BPEL4WS 对以前定义的 Web
服务规范进行了两项补充。
- BPEL4WS 扩展了描述服务的 WSDL 和 WS-Policy
支持。BPEL4WS 支持把 Web
服务组合成聚合服务，文档化服务之间的关联，比如信息流和行为。这为支持协作设计 Web
服务的更高层工具之间的互操作性提供了支持。
- BPEL4WS 是
执行语言（execution language）。BPEL4WS
允许开发人员完全指定组合的 Web 服务的行为。IBM、Microsoft
和其他合作伙伴将提供环境来执行 BPEL4WS
文档和支持合作伙伴的设计和运行时绑定。
实践中的 Web 服务——一个示例
下面的场景将展示，我们可以一起使用这些
WS 规范创建 Web 服务来解决真实世界中的需求问题。这个场景将演示不同的 WS
规范的组合给开发人员带来强大功能。
在这个场景中描述的 Web 服务是为2003年9月17日 IBM-Microsoft
联合举行的技术演示会准备的。我们使用这些 WS
规范创建了一个应用程序，这个应用程序是互操作的、安全的、可靠的、事务化的，而且它跨越了组织的边界。
这个场景演示了一个联合的订单处理和厂商管理的库存（Vendor Managed Inventory，VMI）系统的运行，其中，汽车零售商从汽车制造商订购零件；而汽车制造商本身又从供应商控制的多个仓库获得零件。该系统中所有的应用程序到应用程序通信都无一例外地是使用前面描述的 Web
服务协议构建的，并且运行在使用 IBM 和 Microsoft
软件的一组计算机上。
该场景涉及经营企业的某些最常见的方面——在零售企业、零售企业的批发商和批发商的供应商之间进行的交互。该场景展示了不同的 WS
规范如何组成自动的业务流程基本要素，比如：
- 执行安全性验证（WS-Security）验证
- 不同的组织之间的信任联盟（WS-Trust 和
WS-Federation）
- 完成事务处理的数据交换（WS-AtomicTransaction）
- 通过可靠消息传递提交的订单的保证（WS-ReliableMessagingAssurance）
第一部分：顾客体验
该示例是从
Heather 开始的，Heather 是一个名为 Auto Dealer
的公司的雇员，她登陆她的零售商店的内部网 web 站点。这个 web
站点是使用标准的即购即用的 web 技术构建的。Heather
通过她的浏览器进入该站点。对该站点的访问是受密码保护的。
Heather
点击 My Page。在幕后，应用程序从汽车零售商（Auto Dealer）的库存数据库中收集信息。如果某一项的库存级别降到极限值以下，就生成一份报告，并且将其列在
Heather 的页面的“Your Alerts”显示屏中。
Heather 看见她公司的 WindshieldPro
刮水器片的库存不足。
Heather 点击该链接，然后无缝地转到汽车制造商（Auto Manufacturer）外部网上的安全 Web
页面，在那里 Heather 可以下订单。这种体验是无缝的，因为汽车零售商（Auto Dealer）软件是基于 Web
服务的。链接汽车零售商（Auto Dealer）的内部网与汽车制造商（Auto Manufacturer）的外部网的 Web
服务是通过 WS-Federation 组合起来的。WS-Federation
确保一个站点授予的安全性凭证能够被第二个站点认可。
下面说明其工作原理。汽车零售商（Auto Dealer）和汽车制造商（Auto Manufacturer）已经同意联合它们的站点。WS-Federation
协调一系列服务器到服务器通信。只要 Heather 点击 WindshieldPro
链接进入汽车制造商（Auto Manufacturer）的 Web 页面，汽车零售商（ Auto Dealer）的 Web
页面服务器就查询它的验证服务，而汽车零售商（Auto Dealer）的验证服务再查询汽车零售商（Auto Dealer）的验证服务。汽车零售商（Auto Dealer）的验证服务确认 Heather
是经授权的用户，随后把凭证以及 Heather
的零售商店的名称发回到汽车制造商（Auto Manufacturer）的验证服务，再由汽车制造商（Auto Manufacturer）的验证服务批准 Heather
进入。这完全是无缝地发生的，而 Heather
需要注意的只是她已经从一个 Web 页面进入了另一个 Web
页面。
此外，该 Web 服务还查询汽车制造商（Auto Manufacturer）的顾客数据库，以查找链接到
Heather 的账户的订购信息。此信息显示在汽车制造商（Auto Manufacturer）的 Web
页面的个性化“My Page”上。
汽车制造商（Auto Manufacturer）外部网上
Heather 的个性化 Web
页面允许她查看目前是否有未完成的订单；她有一个订单（订购 50
个单位的 SuperTires）正在发送中；她的已完成订单列表包括20个单位的 CDPlus
和50个单位的 Leather Cleaner。
Heather 点击“Create New Order”，新的页面打开，预先填入了她需要的零件——WindshieldPro
牌刮水器片、以及订购日期。她只需输入数量就可以了。完成订单所需的其他全部信息都由系统从汽车制造商（Auto Manufacturer）数据库种填入。
Heather
提交订单，然后可以搜索需要购买的其他零件，也可以单击
Logout，以结束她的会话，并且阻止别的人再她不在场时从她的计算机中下订单。
值得注意的是，通过 WS-Federation 组合 Web
服务降低了汽车零售商（Auto Dealer）和汽车制造商（Auto Manufacturer）的管理成本，并且给它们提供了端到端（end-to-end）的安全性。如果没有这项技术，汽车制造商（Auto Manufacturer）将不得不维护所有经授权的零售商店雇员和他们的密码列表。而这样做的成本将非常高昂且容易出错，同时还降低了应用程序的安全性。
举例来说，如果 Heather
辞掉她的工作，她的用户账户就会从汽车零售商（Auto Dealer）的 Web
站点上删除。但是，如果零售商店的管理员忘记与汽车制造商（Auto Manufacturer）联系，告知
Heather 的离开，Heather 就可以继续访问购买站点。而使用
WS-Federation，这将不是一个问题，因为必须更改的惟一系统是汽车零售商（Auto Dealer）的 Identity Provider
服务。汽车制造商（Auto Manufacturer）的系统（包括应用程序和验证服务）都不会预先知道
Heather，她的用户名或她的密码。
第二部分：供应商体验
虽然
Heather 从汽车制造商（Auto Manufacturer）订购
WindshieldPro
牌刮水器片，但是该公司实际制造自己的刮水器片已经是半个世纪以前的事了。WindshieldPro
牌刮水器片来自一个厂商，也就是供应商（Supplier）。
Tony 是供应商（Supplier）的销售代表，他登陆供应商（Supplier）的内部网来开始他一天的工作，而与此同时，Heather
登陆到汽车零售商（Auto Dealer）的内部网上。不过，Tony
没有使用标准的 Web 浏览器，他使用内置支持 Web 服务的 Windows
应用程序。
当 Tony
点击检查订单和库存时，他的应用程序使用 Web 服务请求允许 Tony
访问的库存数据。
这个应用程序级 Web
服务请求数据的一种关键方面是，它与 WS-Federation
组合在一起，WS-Federation 验证对汽车制造商（Auto Manufacturer）的外部网的访问。
该 Web 服务把结果返回到供应商（Supplier）的页面，在供应商（Supplier）的页面上，结果按产品类型和当前库存数量进行显示。
供应商（Supplier）已经加入了与汽车制造商（Auto Manufacturer）达成的准化化（just-in-time）购买协议。Tony
获得了这样的授权，一旦库存降到20以下，就可以代表汽车制造商（Auto Manufacturer）作为厂商管理的库存（Vendor Managed
Inventory，VMI）提供自动的再供应（re-supply）订单。Tony
点击 WindshieldPro 来下订单。在 Tony 和汽车制造商（Auto Manufacturer）之间传递的消息是受保护的，因为应用程序得到了与
WS-Security 的保护组合在一起的 Web 服务的支持。
Tony
的应用程序给他提供一个屏幕来创建对供应商（Supplier）的请求（带有汽车制造商（Auto Manufacturer）订单）。Tony
订购50个单位的 WindishieldPros
牌刮水器片，这些刮水器片需要直接发货到汽车制造商（Auto Manufacturer）。
当 Tony 点击 OK 时，仓库服务（Warehouse Service）（一个与
WS-AtomicTransactions、WS-Security 和 WS-ReliableMessaging 组合在一起的 Web
服务）就尝试与另一个 Web 服务（下级仓库服务（Warehouse
Service））下订单。当响应没有立即从仓库服务（Warehouse
Service）返回时（因为临时网络超时），WS-ReliableMessaging
就继续重新发送请求，直到接收到一个响应为止。
当仓库服务（Warehouse Service）接收到订单时，它就将订单从内部转发到该公司的两个物理仓库。由于这涉及到两个仓库之间的数据库，所以可以用
WS-AtomicTransaction 来确保数据库之间的事务行为。
仓库服务（ Warehouse Service）将订单在下级仓库中进行划分，以确保库存量，将订单的70%发往仓库1（Warehouse
1），剩下的30%发往仓库2（Warehouse 2）。主仓库（Main Warehouse）中的根协调器（Root Coordinator）发送一个消息到仓库2（Warehouse
2），请求订单的30%。仓库2（Warehouse 2）的根协调器（Root Coordinator）检查它的库存，请发送一个消息到主仓库（Main Warehouse）中的根协调器（ Root Coordinator），告知没有足够的存货。
主仓库（ Main Warehouse）中的根协调器（ Root Coordinator）直到没有足够的库存，就取消整个事务，然后发送消息到
Tony 的 Web
应用程序，指示库存状态、库存级别和事务被取消。根协调器（Root Coordinator）开始取消事务，并且在完成返回到仓库（Warehouse）时，告知事务已经被取消。
Tony（知道当前的库存）发送另一个请求到仓库（Warehouse）。根协调器（ Root Coordinator）在其他的事务性实体（其他事务的控制器）中协调，并且把这个请求发送到仓库2（Warehouse
2），继续进行和前面一样的过程。
现在，Root
协调器提交事务，锁住资源，然后完成事务。消息发送回到 Tony，指示事务已经成功完成。
在这些消息中，WS-AtomicTransaction 与 WS-ReliableMessaging
和 WS-Security
组合在一起，以提供一个完整的企业就绪分布式系统。
结束语
IBM、Microsoft
和我们的合作伙伴正在开发 Web
服务规范，我们可以使用这些规范来构建新一代强大、安全、可靠、事务化的 Web
服务。
这些规范是按照模块化和可组合的方式进行设计的，比如，开发人员可以只利用它们需要的功能。这种“类似组件”的可组合性将使开发人员能够以简单而灵活的方式创建强大的 Web
服务，而仅仅引入特定的应用程序要求的复杂性级别。
这些 Web
服务使组织能够更容易地使用面向服务体系结构（Service-Oriented Architecture，SOA）创建应用程序。此外，IBM
和 Microsoft 已经演示了安全、可靠、事务化的 SOA
应用程序，举例说明了可以使用此方法创建的业务流程的丰富。而且，这些演示是在一组异类系统（运行
IBM WebSphere 和 Microsoft .NET
软件）上的联合安全性环境中进行的。
我们预计，当工具使开发人员更容易使用这些 Web
服务技术时，这些 Web
服务技术将可以使用在操作系统和中间件中。随着开发人员和组织使用这些系统来创建下一代基于 Web
服务的解决方案，我们将欣喜地看到一些新兴的应用程序。
致谢
我们非常感谢下列对这些理念作出贡献的个人：（按字母顺序排列）Tony
Andrews、Bob Atkinson、Keith Ballinger、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、Omri Gazitt、Scot Gellock、Josh Gray、Martin Gudgin、MaryAnn
Hondo、Destry Hood、Efim Hudis、Tomasz Janczuk、Jim Johnson、Ryan Johnson、Gopal
Kakivaya、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、Karla
Norsworthy、Stefan Pharies、Scott Robinson、Yordan Rouskov、Sujay Sahni、Jeff
Schlimmer、Oliver Sharp、Yasser Shohoud、Dan Simon、Jeff Spelman、Keith
Stobie、Satish Thatte、Robert Wahbe、Elliot Waingold、Richard Ward、Sanjiva
Weerawarana、Hervey Wilson、Eric Zinda。
作者简介 | | | Donald F. Ferguson has co-authored this article |
| | | Tony Storey has co-authored this article |
| | | Brad Lovering has co-authored this article |
| | | John Shewchuk has co-authored this article |
对本文的评价
| 
