Web 服务规范和功能 (AMT 袁磊)

2、 基础 —— 传输协议和消息传递

如果我发给您一封用法语写的信，而您希望用英语进行电话交谈，那么我们将无法沟通。Web 服务的互操作性面临着同样的问题；我们可以通过提供一组通用的传输协议和消息传递技术来解决这个问题。

另外，为了确保这些技术在实践中是有效的，IBM、Microsoft 和其他公司创立了 Web 服务互操作性组织（Web Services Interoperability Organization，WS-I）。最近，WS-I 发布了基本概要，正式文档化了可互操作的 Web 服务传输协议和消息传递机制。

2.1 传输协议 —— HTTP、 HTTP/S,、SMTP

这一组规范定义了在 Web 服务之间传送原始数据的核心通信机制。

其中包括HTTP、 HTTP/S, 和简单邮件传输协议（Simple Mail Transport Protocol，SMTP）。Web 服务实现可以另外支持其他的传输协议，但是支持标准的、可互操作的协议是非常重要的。

2.2 消息格式 —— XSD

下一组规范为编码传输的 Web 服务消息定义了可互操作的机制。传输在服务之间传送“字节”块。只有当参与者能够把字节转换成它们的应用程序可以处理的有效数据结构时，这才是有用的。

消息传递规范组定义了如何正确地安排消息的格式。XML and XML Schema 定义提供了抽象约定消息（数据）结构的机制。SOAP 定义了表示 XML 消息的标准编码方法，其中，XML 消息用服务通过传输交换的字节信息进行表示。

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 提供了一种通用的机制来把传入和传出消息与特定的任务关联起来。服务使用的这些机制对于那些通过端点引用使用服务的人来说是透明的。

3、 描述

传输和消息规范允许 Web 服务使用消息进行通信。但是，参与者如何知道消息是什么呢？Web 服务如何文档化或描述它发送和接收的消息呢？使用 Web 服务需要理解 Web 将使用和产生的消息——Web 服务的接口。规范的描述组使 Web 服务能够表达它的接口和功能。

除了消息互操作性之外，这些规范还启用了开发工具互操作性（development tool interoperability）。描述规范提供了一个标准的模型，使得来自不同厂商的各种工具能够协同支持开发人员。.以与 Web 服务把合作伙伴从实现和基础体系结构选择中分离出来的相同方式，描述规范把合作伙伴从开发工具选择中分离出来。

3.1 WSDL

Web 服务描述语言（Web Services Description Language，WSDL）是这一组中的基础规范。XML Schema 允许开发人员和服务提供者定义数据结构（例如订购单）和消息（例如 CreatePO 消息）的 XML 类型。WSDL 允许 Web 服务文档化它接收和发送的消息。换句话说，服务根据它接收和发送的消息执行什么“动作”或“功能”。

WSDL 为各种各样的消息交互模式提供了支持。它支持单向输入消息，这些单向输入消息可以没有响应，没有请求/响应，并且可以单向发送（有或没有响应）。后两种模式使服务能够指定它需要的其他服务。

提议的 WSDL 增强支持文档化服务支持的协议和消息格式、以及服务的地址。

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 获取描述

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

目前，最常用的方法是通过电子邮件交换或口头表达。为了达到更通用的目的，可伸缩模型是必要的。有两种选择，服务可以直接进入服务以使用 WS-MetadataExchange 来获得信息，也可以选择使用 UDDI 服务，该服务聚合多个目标服务的这种信息。

当开发人员引用服务并且需要了解它做什么时，他们可以使用 WS-MetadataExchange。当开发人员想要查找支持一组特定功能的服务的引用时，他们可以使用 UDDI。

3.4 WS-MetadataExchange

如上所述，服务一般提供描述服务本身的信息（比如 WSDL、WS-Policy 和 XSD）。我们把与服务有关的信息统称为元数据。WS-MetadataExchange 规范使得服务能够通过 Web 服务接口将元数据提供给其他的服务。假定只引用一种 Web服务，潜在用户就可以访问一组 WSDL/SOAP 操作来检索描述服务的元数据。客户机在设计、构建或运行时可以使用 WS-MetadataExchange。

3.5 UDDI

收集关于一组服务的元数据并且使得可以以可搜索的方式使用该信息是非常有用的。这样的元数据聚合是一个很好的存储库，企业可以在其中发布它们提供的服务，描述它们的服务的接口，采取特定领域的分类法。通用描述和发现接口（Universal Description and Discovery Interface，UDDI）规范定义了元数据聚合服务。

解决方案在设计时可以查询 UDDI 来找到与它们的需求相匹配的服务。例如，开发人员可以在定义他们的 BPEL4WS 工作流时使用这些服务。解决方案在运行时也可以查询 UDDI。在这种场景中，调用者“知道”它调用的接口，并且搜索与它的功能匹配的或由知名合作伙伴提供的服务。

请注意，在可能用来填充带有元数据的 UDDI 服务的机制中，有一种必须通过 WS-MetadataExchangeNote 从服务获取元数据。

4、服务保证

Web 服务之所以引起人们如此大的热情，在某种程度上是因为它们跨接完全不同的系统的能力。开发人员已经使用传输、消息传递和描述的基本功能提出了许多功能完备的解决方案。然而，为了被创建更强大的集成解决方案的开发人员接受，Web 服务必须提供功能来确保与更传统的中间件解决方案相同级别的服务保证（service assurances）。仅仅交换消息是不够的。应用程序和服务驻留在中间件和系统上，这些中间件和系统非常有价值的级别更高的功能，比如安全性、可靠性和事务化操作。Web 服务必须为这些功能之间的互操作性提供一种机制。

5、 安全性

这个规范家族对于跨组织 Web 服务是至关重要的。这些规范支持验证和消息完整性、机密性、信任和隐私。它们也支持不同组织之间的安全联盟。

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 服务计算就不可能是安全的。

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 中的某个成员。

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 约定签署和加密信息的会话专用密钥。

5.4 WS-Federation

WS-Federation 允许一些组织建立一个虚拟的安全性区域。例如，旅行代理、航空公司和旅馆链可以建立这样的联盟。“进入”联盟中任一成员的终端用户可以有效地进入所有的成员。WS-Federation 通过 WS-Trust 和 WS-SecureConversation 拓扑之间的协议为给定的安全性定义了几种模型。

另外，顾客在与企业打交道时常常有“特性”。例如，优先选择靠窗或过道旁的座位或中型汽车。WS-Federation 允许成员建立联合的特性空间。这允许参与者在安全控制的条件下访问每个成员关于终端用户的特性信息。

关于个人的特性和信息可能秘密存放，因为需要保护人们的隐私，或者因为这些信息给某个成员提供了竞争优势。为了支持这些需求，WS-Federation 支持假名模型（pseudonym model）。经过旅行代理验证的用户在与航空公司或旅馆交互的过程中使用代理生成的“别名”。这保护了终端用户的隐私和旅行代理因知道用户特性而赢得的竞争优势。

6、可靠消息传递

在 Internet 世界，几乎所有的信息通道都是不可靠的。消息会丢失。连接会中断。如果没有可靠的消息传递标准，Web 服务应用程序开发人员就必须将这些功能构建在他们自己的应用程序中。基本方法和技术是很好理解的，例如，许多操作系统和中间件系统可以确保消息有惟一的标识符，提供顺序号，并且在消息丢失时使用重发。如果应用程序 Web 服务开发人员在它们的应用程序中实现了这些模型，他们就可以进行不同的假定或设计选择，而结果却没有什么不同（如果采用某种可靠消息传递的话）。

6.1 WS-ReliableMessaging

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

WS-ReliableMessaging 不仅确保服务实现互操作方法，而且通过提供实现协议的服务使运行时厂商能够更容易地进行应用程序的开发。这大大简化了应用程序开发的任务。因此，业务逻辑有极少的错误情况需要处理。

最后，业界有很多面向消息的中间件，可以用于可靠地路由和分布消息。每个实现都使用专有的协议。WS-Reliable Messaging 协议允许不同的操作系统和中间件系统可靠地交换消息。因而，它支持把两个不同的基础体系结构跨接成一个逻辑上完整的端对端模型。

7、事务处理

复杂的业务场景可能需要多方交换多组消息。举例来说，几个金融机构提供一种金融产品，涉及保险政策、养老金、经常账户和经纪账户。在参与者之间交换的多个消息构成逻辑上的“任务”或“对象”。

为了成功，参与者必须能够：

1. 开始新的协调的任务。
2. 使操作与它们的逻辑任务相关联。参与者可以同时为不同的顾客设置多个账户。
3. 约定计算的结果。例如，每个人都赞同建立的金融包吗？

WS-Coordination、WS-AtomicTransaction 和 WS-BusinessActivity 支持这些需求。

7.1 WS-Coordination

WS-Coordination 是开始和约定多方、多消息 Web 服务任务的结果的通用机制。WS-Coordination 有三个关键元素：

1. 称为协调上下文（coordination context）的消息元素，它在 Web 服务计算时交换的所有消息中传送。协调上下文包含对协调服务的 WS-Addressing 端点引用，而本身又包含用于标识正在协调的特定任务的信息。
2. 协调器服务（coordinator service）。协调器服务提供使用 WSDL 描述的服务，这种服务能够开始协调的任务，终止协调的任务，允许参与者在任务中注册，并且产生协调上下文，所产生的协调上下文是一个组内所有消息的一部分。  
3. 协调服务也包括一个用 WSDL 定义的接口，参与的服务可以使用这个接口来获得协调的任务的结果方面的通知。

接收带有新协调上下文的消息的 Web 服务向该上下文中的协调器服务注册以接收结果信息。其他的规范可以在领域方面扩充此框架，并且保证特定的需求。

WS-Coordination 是一个通用的规范，具有通用的功能。WS-AtomicTransaction 和 WS-BusinessActivity 扩展了此规范，以使分布式计算中的参与者能够稳固地决定结果。

7.2 WS-AtomicTransaction

WS-AtomicTransaction 定义了一组特定的协议，这组协议可以插入 WS-Coordination 模型，以实现传统的两阶段原子事务处理协议。注意到原子的两阶段模型只是就涉及的服务而言的非常重要。提供服务的站点或基础体系结构可能大肆宣传两阶段提交，但是却使用一些其他的企业内部模型，比如补偿模型或版本模型。这种自由使简单的两阶段提交模型对于长期运行的 Internet 计算更有用。

7.3 WS-BusinessActivity

WS-BusinessActivity 定义了一组特定的协议，这组协议可以插入 WS-Coordination 模型，以实现长期运行的、基于补偿的事务处理协议。虽然 BPEL4WS 为业务处理定义了一个事务处理模型，但是指定对应的协议翻译的是 WS-BusinessActivity。这又是一个 Web 服务规范的可组合性的例子。

8、服务组合

在 Web 服务分层中，最上层的元素是服务组合（service composition）。服务组合使开发人员能够把交换 SOAP 消息以及用 WSDL 和 WS-Policy 定义它们的接口的服务“组合”成聚合的解决方案。该聚合是组合的 Web 服务。

用于 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 服务规范进行了两项补充。

1. BPEL4WS 扩展了描述服务的 WSDL 和 WS-Policy 支持。BPEL4WS 支持把 Web 服务组合成聚合服务，文档化服务之间的关联，比如信息流和行为。这为支持协作设计 Web 服务的更高层工具之间的互操作性提供了支持。
2. BPEL4WS 是执行语言（execution language）。BPEL4WS 允许开发人员完全指定组合的 Web 服务的行为。IBM、Microsoft 和其他合作伙伴将提供环境来执行 BPEL4WS 文档和支持合作伙伴的设计和运行时绑定。