2.2　Web服务技术

Web原本是蜘蛛网和网的意思。在互联网中，Web指的是一种基于网站（Website）的使用环境，是网站的前台布局、后台程序、数据库和用户访问等一系列技术的总称。网站是一种信息工具，就像布告栏一样，人们可以通过网站来发布自己想要公开的信息，或者利用网站来提供相关的网络服务。人们可以通过网页浏览器来访问网站，获取自己需要的信息或者享受网络服务。

Web服务（Web Service）是基于Web技术，在互联网上提供的一套分布式可互操作的应用程序（服务）及其标准，定义了多种应用程序如何在互联网上实现互操作，具有平台独立、松耦合、自包含等特点。在依据Web Service规范实施的应用程序之间，无论它们所使用的语言、平台或内部协议是什么，都可以相互交换数据，从而使得互联网中运行在不同机器上的不同应用程序无须借助附加、专门的第三方软件或硬件，就可以相互交换数据或进行集成。Web Service使用开放的XML来描述、发布、发现、协调和配置这些应用程序。

进行Web服务开发的核心技术是WSDL，它使用端口类型或者通用服务接口来描述Web服务。服务接口描述了服务支持的各种操作，以及每个操作输出的和输入的消息结构。服务描述能够告诉客户端互联网中的服务提供哪些功能，以及如何调用它们。相比面向对象的软件设计架构CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）中的接口定义语言（IDL），WSDL能够用于自动生成面向编程语言的架构，这些架构通过隐藏发布的细节来简化服务开发过程。然而，服务接口的描述并不充分，因为它缺少服务支持的交互过程顺序消息集合的描述，以及其他在操作调用上的约束。

我们使用的Web服务协议是对客户端和服务端之间正确交互作用集合的定义。服务模型非常重要，因为它们允许应用开发者能够正确开发与服务交互的客户端。因此，包含服务协议规范的服务描述是十分重要的。另外，也有必要扩展服务描述语言，从而支持消息调用的正确顺序及其属性（包括WSCL、WSCI、BPEL4WS、WS-Coordination等）的约束。

Web服务策略（WS-Policy）是Web服务抽象中的另一个重要部分。明确描述服务策略的需求比传统应用集成更为重要，因为Web服务将会基于各种策略在动态和自治环境中潜在运行。这方面的工作包括制定WS-Security、WS-Policy、WS-Security Policy等规范。这些规范仅规定了将策略需求具体化的XML语法，但是不能解决如何对这些需求进行建模或管理的问题。因此，还需要一个高级架构，以利于开发者使用服务策略规范工具和自动化服务策略进行服务生命周期的管理。

Web服务的另一个重要的特性是，一旦各种应用功能以Web服务的形式提供给用户，就会大大降低其异构性。当服务被描述并以一种标准化的方式交互时，通过组合其他服务来开发复杂服务的任务就相对简单了。事实上，随着服务相关技术的成熟，人们期望服务组合能够在服务开发工作中发挥越来越大的作用。由于服务会在其组成部分的组装和事务到事务之间的交互过程中被查找，其功能和策略需要以这样的方式来描述：客户端可以发现它们并且评估其组装和交互的适应性。

针对Web服务协议和策略，目前已有的服务组装语言和工具已经成熟。其中，最重要的规范是服务流程执行语言（Business Process Execution Language，BPEL），它是一种用于自动化服务流程的形式规约语言，能够自动生成代码和外部规范。用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式形成服务流程。而且，这些流程能够在任何一个符合BPEL规范的平台或产品上执行。因此，通过允许顾客在各种各样的创作工具和执行平台之间移动和使用这些流程，BPEL保护了他们在流程自动化上的已有投资。

2.2.1　Web服务架构（WSA）

WSA（Web Service Architecture，Web服务架构）将Web服务技术放在上下文（Context）体系中考虑并简化其关系。WSA协议栈包含大量Web服务协议的子集，这些协议设计用来支持Web服务应用的服务质量（QoS）。

简单对象访问协议（Simple Object Access Protocol，SOAP）是Web服务默认的消息传输协议，是WSA协议栈中底层的协议。SOAP头部使得高层Web服务协议能够简单地集成到其基础消息交换协议中。

每个协议的头部都是被单独处理的，允许软件代理在Web服务中接收到消息时执行协议规定的活动。相似地，当服务发送消息时，协议特定的代理可能会加入任何必要的头部，并重写到消息中任何合适的地方。SOAP头部的内容是不固定的，这就允许Web服务能够有效地确定其协议栈。统一包含在Web服务协议栈中的协议如图2-7所示。

WSA具有以下特性。

1.可组合性

尽管多种协议规范可能被组合到一起来实现某些复合行为，但每个协议规范都是独立设计的。也就是说，尽管一个给定的协议规范为了提供额外可选的功能而用到了另一个协议规范，但是这些协议规范之间并没有必需的依赖关系。

2.面向消息

WSA中的各种协议规范均体现为消息和消息交换形式的规定，没有任何结构性或者服务实现技术方面的额外规定。

任何具有这类特性的Web服务协议都可以与其他Web服务协议交互工作，从而支持特定QoS的消息交换。然而，Web服务组合方法的松耦合特性意味着Web服务系统是非集中式管理的，虽然有中心可能有助于在跨越整个应用的QoS协议时保持一致性，但这样会导致每个Web服务都不能正确解释和处理其中的QoS协议消息。

3.传输独立性

在SOA的架构中，虽然在Web服务传送消息可以使用HTTP作为传输协议，但在Web服务激增的早期阶段及现在都不是必须使用HTTP协议的。目前，大多数的Web服务规范都是基于SOAP消息交换形式来定义的，而与任何特定传输层协议无关。正如人们所理解的那样，Web服务与Web是解耦的。

不依赖特定传输层协议的SOAP消息实现了消息级别的寻址。像WSAddressing和WS-Message Delivery这样的协议允许在消息中加入寻址信息，在SOAP消息中封装为头部子块，在消息传输的过程中绑定到下面的传输层寻址机制中。结果是SOAP消息可以利用任何传输层协议在网络中传送，如图2-8所示。

4.消息路由

基于传输层协议独立和可扩展的消息传输机制，可以定义其他高层消息协议，如组播和可靠消息交付协议。这样的协议允许Web服务交换信息的方式超越传统的点到点消息交换方式。

5.元数据

Web服务的类型结构如图2-9所示。从图2-7中可以看出元数据和策略元素栈管理描述服务的方式。特别是，WSDL描述消息格式和服务期望参与的消息交换形式，而且可选策略规定了许可消息或者其他QoS特性的内容约束条件。

访问一个Web服务的元数据，传统上是一个特设事务，都在Web服务的URL上发起一个HTTP GET来获取Web服务的WSDL约定。虽然该机制现在已经标准化，但仍然是基于具体传输协议的，因此不是Web服务的最好方式。WS-Metadata Exchange规范被认为是从相关的Web服务获取WSDL约定和策略的SOAP友好方法。

6.QoS协议

如果没有任何协议来提供适当级别的服务质量（QoS）保证，Web服务将不会是一个部署可靠计算系统的有效方法。WSA中的QoS协议解决了可靠性系统的重要问题，而且是通过增加底层面向消息结构的消息安全性、可靠消息及事务的方式实现的。虽然这些讨论仅限于安全、可靠消息交付和事务，但支持的原则同样适用于其他QoS协议。

7.安全性

虽然“安全”是一个广义术语，但是，在Web服务领域，安全性的讨论仅限于消息传输方面。WS-Security支持Web服务之间的私有、防篡改、验证和不可否认的消息交互。考虑到消息交互在通过包括互联网在内的任意网络时，这些属性是极为重要的。如果机密信息被泄露，或者如果邮件内容在中途被改变，结果可能是灾难性的。确定邮件的发件人是同样重要的，因为它可能会影响是否接收Web服务及如何处理该消息。

在Web服务领域，允许Web服务中间件屏蔽底层网络中的故障，以便提供尽力将消息交付给Web服务（例如，WS-ReliableMessaging）的能力。

2.2.2　Web服务分析

典型的Web服务系统结构是多层次的，它包括信息传输、处理、服务逻辑及在运行时环境承载的资源层。Web服务的实现将其中许多Web服务协议与某些服务特定的逻辑相结合，并将预期的功能交付给网络。

宿主（Hosting）环境可以是任何的计算机系统，例如，从一个单一的操作系统过程到Web服务器（如IIS或Apache），到整个应用的服务器群的部署（基于Web Sphere）。宿主环境只需要提供信息处理能力的执行上下文，就能够启动处理过程以响应消息的接收。

传输层完成输入、输出消息的处理和路由事件。它通常是实现一个或多个通信协议（例如，内存中的交换、TCP、UDP、SMTP、HTTP等）的特定基础设施中间件。

信息处理层的功能是使用底层传输协议传递SOAP消息，以及根据该消息的内容执行任何必要转换或特定协议行动。此外，还提供抽象揭示底层消息传递活动的可编程抽象。服务逻辑通过这些抽象绑定到底层应用和基础设施协议上。SOAP消息处理器结构如图2-10所示。

此外，信息处理层还为Web服务逻辑提供必要的执行上下文，以便提取和处理包含具体协议的SOAP消息头部。根据部署或服务对所有传出的SOAP消息的具体要求，引入了协议特定的头文件。典型的消息处理器（见图2-10）将允许以“handler”或“plug-in”两种方式沿两个逻辑消息处理管道（一个用于接收消息，另一个用于发送消息）来处理SOAP消息。任何需要handler传播到服务实现的消息都是在对邮件正文处理过程中完成的，一般来讲是通过在handler（处理程序）和服务逻辑之间共享执行上下文来实现的，通常每个handler实现一个SOAP中间代理（如每个SOAP处理模型）。