本文从组件、交互以及应用程序开发模式的观点描述了 Web 服务的体系结构。该体系结构是 IBM 实例化 Web 服务方法的蓝图。它是构建和部署 Web 服务应用程序的框架。

　　本文中提到的体系结构包括对 Web 服务需要的组件和功能的高级描述，以及对实现这些组件和功能的工具和中间件的要求。现在，诸如 IBM XML and Web Service Development Environment、IBM Web Service Toolkit 以及 IBM WebSphere Application Server 之类的产品中已经有了一些功能。将来这些产品以及其它产品会实现另外的功能。但是，组件、功能或要求在本文中出现并不保证会在未来的 IBM 产品中实现。

　　目标读者

　　Web 服务的早期采用者和实现者。

　　IBM 公司以外的评估 IBM Web 服务方法的技术评论家。

　　Web 服务概览

　　这一部分对 Web 服务作为一种应用集成技术加以简要评论，定义 web 服务一词并描述 Web 服务模型。

　　Web 服务：电子商务的新天地

　　Web 是为了程序到用户的交互，而 Web 服务是为程序到程序的交互做准备。Web 服务使公司可以降低进行电子商务的成本、更快的部署解决方案以及开拓新机遇。达到这个新天地的关键在于通用的程序到程序通信模型，该模型应建立在现有的和新兴的标准之上，例如，HTTP、可扩展标记语言（Extensible Markup Language，XML）、简单对象访问协议（Simple Object Access Protocol，SOAP）、Web 服务描述语言（Web Service Description Language，WSDL）以及通用描述、发现和集成（Universal Description Discovery and Integration，UDDI）。

　　Web 服务使应用程序的集成比以前更快、更容易而且更便宜。集成在协议栈中较高层发生，它基于更注重服务语义而不那么注重网络协议语义的消息，从而实现了业务功能的松散集成。这些特性对于在企业之间和企业内部通过 Web 连接业务功能是非常理想的。它们提供一种一致化编程模型，从而在企业内外都可以利用通用的基础设施并以一种通用的方法进行应用程序集成。利用现有的语言和平台以及旧应用程序，可以以一种增量的方式来集成和应用 Web 服务。此外，Web 服务遵循 Java 2 平台，企业版（Java 2 Platform，Enterprise Edition，J2EE）、通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）以及其它针对与耦合较紧的分布式或非分布式应用程序集成的标准。Web 服务是部署并提供通过 Web 访问业务功能的技术；J2EE、CORBA 和其它标准是实现 Web 服务的技术。

　　尽管 Web 服务早先是类似对等的并且是专用的，但它仍能解决程序到程序通信的整个问题，包括描述、发布和查找接口。而且，随着 Web 服务的使用越来越多以及行业的成熟，将会有更多的应用程序集成的动态模型发展起来。最终，通过 Web 服务进行系统集成将会在运行时动态发生。即时集成将宣布通过因特网进行企业到企业集成的新纪元的到来。

　　Web 服务的定义

　　Web 服务是描述一些操作（利用标准化的 XML 消息传递机制可以通过网络访问这些操作）的接口。Web 服务是用标准的、规范的 XML 概念描述的，称为 Web 服务的服务描述。这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。这允许并支持基于 Web 服务的应用程序成为松散耦合、面向组件和跨技术实现。Web 服务履行一项特定的任务或一组任务。Web 服务可以单独或同其它 Web 服务一起用于实现复杂的聚集或商业交易。

　　Web 服务模型

　　Web 服务体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互涉及发布、查找和绑定操作。这些角色和操作一起作用于 Web 服务构件：Web 服务软件模块及其描述。在典型情况下，服务提供者托管可通过网络访问的软件模块（Web 服务的一个实现）。服务提供者定义 Web 服务的服务描述并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作来从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用 Web 服务实现或同它交互。服务提供者和服务请求者角色是逻辑结构，因而服务可以表现两种特性。图 1 图示了这些操作、提供这些操作的组件及它们之间的交互。

　　图 1. Web 服务角色、操作和构件
 
　　Web 服务体系结构中的角色

　　服务提供者。从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托管访问服务的平台。

　　服务请求者。从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互的应用程序。服务请求者角色可以由浏览器来担当，由人或无用户界面的程序（例如，另外一个 Web 服务）来控制它。

　　服务注册中心。这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色，因为服务提供者可以把描述直接发送给服务请求者。同样，服务请求者可以从服务注册中心以外的其它来源得到服务描述，例如本地文件、FTP 站点、Web 站点、广告和服务发现（Advertisement and Discovery of Services，ADS）或发现 Web 服务（Discovery of Web Services，DISCO）。

　　Web 服务体系结构中的操作

　　对于利用 Web 服务的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。这些操作具体为：

　　发布。为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化（请参阅“服务发布”以了解更多细节）。

　　查找。在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型（请参阅“服务发现”以了解更多细节）。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作：在设计时为了程序开发而检索服务的接口描述，而在运行时为了调用而检索服务的绑定和位置描述。

　　绑定。最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。

　　Web 服务的构件

　　服务。在这里，Web 服务是一个由服务描述来描述的接口，服务描述的实现就是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。服务存在就是要被服务请求者调用或者同服务请求者交互。当服务的实现中利用到其它 的Web 服务时，它也可以作为请求者。

　　服务描述。服务描述包含服务的接口和实现的细节。其中包括服务的数据类型、操作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其它元数据。服务描述可以被发布给服务请求者或服务注册中心。

　　Web 服务体系结构解释了如何实例化元素和如何以一种可以互操作的方式实现这些操作。

　　Web 服务开发生命周期

　　Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。服务注册中心的开发和部署不在本文的范围以内。

　　开发生命周期有以下四个阶段：

　　1. 构建

　　生命周期的构建阶段包括开发和测试 Web 服务实现、定义服务接口描述和定义服务实现描述。可以通过创建新的 Web 服务、把现有的应用程序变成 Web 服务和由其它 Web 服务和应用程序组成新的 Web 服务提供 Web 服务的实现。

　　2. 部署

　　部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把 Web 服务的可执行文件部署到执行环境（典型情况下，Web 应用程序服务器）中。

　　3. 运行

　　在运行阶段，可以调用 Web 服务。在此，Web 服务完全部署、可操作并且服务提供者可以通过网络访问服务。现在服务请求者可以进行查找和绑定操作。

　　4. 管理

　　管理阶段包括持续的管理和经营 Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。

　　体系结构概览

　　我们可以在几个层中讨论 IBM Web 服务。首先，我们将看看 Web 服务的一个概念性协议栈以及这个协议栈的细节。然后我们将讨论选择网络协议的标准。我们还将回顾一下基本的基于 XML 的消息传递分布式计算。我们将用服务描述扩展基本的 XML 消息传递，而服务描述是根据它的协议栈来解释的。接下来，我们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。最后，我们将描述基本 Web 服务体系结构的扩展，电子商务需要这些扩展才能使用 Web 服务。

　　Web 服务协议栈

　　要以一种可互操作的方式执行发布、发现和绑定这三个操作，必须有一个包含每一层标准的 Web 服务协议栈。图 2 展示了一个概念性 Web 服务协议栈。上面的几层建立在下面几层提供的功能之上。垂直的条表示在协议栈中每一层必须满足的需求。左面的文本表示协议栈的那一层所应用的标准技术。

　　概念性 Web 服务协议栈

　　图2. Web 服务概念性协议栈
 
　　Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用，就必须是可以通过网络访问的。因特网上可以公用的 Web 服务使用普遍部署的网络协议。HTTP 凭借其普遍性，成为了因特网可用的 Web 服务真正的标准网络协议。Web 服务还可以支持其它因特网协议，包括 SMTP 和 FTP。内部网域可以使用可靠消息传递和调用基础结构，如 MQSeries 和 CORBA 等等。本文的“网络层”部分将更详细地描述这个层。

　　下一层是基于 XML 的消息传递，它表示使用 XML 作为消息传递协议的基础。选择 SOAP 作为 XML 消息传递协议有很多原因：

　　它是使用 XML 传送以文档为中心的消息以及远程过程调用的标准化封装机制。

　　SOAP 很简单；它基本上是一个用 XML 信封作为有效负载的 HTTP POST。

　　SOAP 比对 XML 简单的 HTTP POST 更受青睐，因为它定义了一个标准机制，这个机制将正交扩展（orthogonal extension）合并为使用 SOAP 报头和对操作或函数进行标准编码的消息。

　　SOAP 消息支持 Web 服务体系结构中的发布、查找和绑定操作。“基于 XML 消息传递的分布式计算”部分将更详细地描述这一层。

　　服务描述层实际上是描述文档的一个协议栈。首先，WSDL 是基于 XML 的服务描述的真正标准。这是支持可互操作的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。要指定业务环境、服务质量和服务之间的关系，我们还需要另外的描述。WSDL 文档可以由其它服务描述文档来补充，从而描述 Web 服务的这些更高级的方面。例如，描述业务环境除了使用 WSDL 文档，还要使用 UDDI 数据结构。Web 服务流程语言（Web Services Flow Language，WSFL）文档中则描述了服务组成和流程。“服务描述：从 XML 消息传递到 Web 服务”部分更详细地描述了这一层。

　　因为 Web 服务被定义为可以通过 SOAP 从网络进行访问，并由服务描述表示，所以该协议栈中的前三层需要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消息传递层的 SOAP 协议以及服务描述层的 WSDL。所有企业间或公用 Web 服务都应该支持这种可互操作的基础协议栈。Web 服务，特别是企业内部或专用 Web 服务，能够支持其它的网络协议和分布式计算技术。图 3 描述了可互操作的基础协议栈。

　　图 3. 可互操作的基础 Web 服务协议栈
 
　　图 3 中描述的协议栈提供了互操作性，它使 Web 服务能够利用现有的因特网基础结构。这将使进入普遍存在的环境的成本非常低。灵活性并不会因为互操作性需求而有所降低，因为我们可以为选择性和增值的技术提供另外的支持。例如，我们必须支持 HTTP 上的 SOAP，但也可以同时支持 MQ 上的 SOAP。

　　协议栈的最下面三层确立了保证一致性和互操作性的技术，而它们上面的两层，即服务发布和服务发现，可以用多种解决方案来实现。

　　任何能够让服务请求者使用 WSDL 文档的操作，不管它处于服务请求者生命周期的哪个阶段，都符合服务发布的标准。该层中最简单、最静态的示例就是服务提供者直接向服务请求者发送 WSDL 文档。这被称为直接发布。电子邮件是直接发布的载体之一。直接发布对静态绑定的应用程序来说很有用。另外，服务提供者还可以将描述服务的文档发布到主机本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点。我们将在“服务发布”部分更详细地讨论各种不同的服务发布机制。

　　因为 Web 服务如果没有被发布就不能被发现，所以说服务发现依赖于服务发布。该层的各种发现机制和一组发布机制互相平行。任何允许服务请求者获得对服务描述的访问权，并在运行时使应用程序能够使用该服务描述的机制都符合服务发现的标准。最简单、最静态的发现的示例是静态发现，其中服务请求者从本地文件获取 WSDL 文档。这通常都是通过直接发布获取的 WSDL 文档，或者前面查找操作的结果。另外，也可以通过使用本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。我们将在“服务发现”部分更详细地讨论各种不同的服务发现机制。因为 Web 服务实现是一种软件模块，所以通过组建 Web 服务来产生 Web 服务是很自然的。Web 服务的组合可以扮演很多角色之一。企业内部的 Web 服务可能会相互合作，从而对外显示出一个单独的 Web 服务接口，或者，来自不同企业的 Web 服务可以相互合作，从而执行机器到机器、企业到企业的事务。另外，工作流程管理者还可以在参与业务流程的时侯调用每个 Web 服务。最上面一层，即服务流程，描述了如何执行服务到服务的通讯、合作以及流程。WSFL 用于描述这些交互。Web 服务这个主题在它自己那一部分，即“业务流程、工作流程和 Web 服务”中有所描述。

　　要使 Web 服务应用程序满足当今电子商务的迫切需求，就必须提供企业级基础结构，包括安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须得到解决。每一层的解决方案可以彼此独立。随着 Web 服务范例的采用和发展，将会出现更多此类垂直条。我们将在“真正电子商务的 Web 服务”部分讨论这些垂直条。

　　该协议栈的最下面几层表示基础 Web 服务协议栈，它们相对于协议栈中上面几层来说更成熟，也更标准。Web 服务的成熟和采用将会带动协议栈中上面几层和垂直条的开发和标准化。

　　网络层

　　Web 服务协议栈的最底层是网络层。该层可表示任意多个网络协议：HTTP、FTP、SMTP、消息排队（Message Queuing）、因特网 ORB 间协议（Internet Inter ORB Protocol，IIOP）上的远程方法调用（Remote Method Invocation，RMI）、电子邮件等等。在任何给定的情况下使用的网络协议都依赖于应用程序需求。

　　对于可以从因特网访问的 Web 服务，人们选择网络技术的时侯通常会倾向于选择普遍部署的协议，如 HTTP。对于内部网中提供和使用的 Web 服务，使用另外的网络技术也会被认同。我们可以根据其它需求选择网络技术，包括安全性、可用性、性能以及可靠性。这使得 Web 服务可以利用已有的功能更高级的联网基础结构和面向消息的中间件，如 MQSeries。在有多种网络基础结构的企业中，HTTP 可以用来在这些基础结构之间搭建桥梁。

　　Web 服务的好处之一在于，它为专用内部网和公用因特网服务的开发和使用提供了统一的编程模型。所以，网络技术的选择对服务开发者来说是透明的。

　　基于 XML 消息传递的分布式计算

　　IBM Web 服务体系结构最基础的支柱是 XML 消息传递。当前 XML 消息传递的行业标准是 SOAP。IBM、Microsoft 以及其它企业都向 W3C 建议 SOAP 作为 XML 协议工作组（XML Protocol Working Group）的基础。XML 协议将代替 SOAP 作为行业标准 XML 消息传递协议的位置。当 W3C 发布 XML 协议的草案标准时，IBM Web 服务体系结构就会从 SOAP 迁移到 XML 协议。

　　SOAP 是一种简单的、轻量级的基于 XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP 包括三部分：一个定义描述消息内容的框架的信封、一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用（remote procedure calls，RPC）和响应的约定。SOAP 可以和各种网络协议（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI）相结合使用，或者用这些协议重新封装后使用。

　　虽然理解这个基础很重要，但多数 Web 服务开发者不必直接处理这个基础结构。大多数 Web 服务都会使用从 WSDL 生成的经过优化的特定于编程语言的绑定。当服务提供者和服务请求者都在类似的环境中执行时，这种优化可能尤为重要。

　　图 4 展示了 XML 消息传递（即 SOAP）和网络协议如何组成 IBM Web 服务体系结构的基础。

　　图 4. 使用 SOAP 的 XML 消息传递
 
　　网络节点在基于 XML 消息传递的分布式计算中扮演提供者和请求者的角色的基本要求是构建、解析 SOAP 消息的能力（或两者），以及在网络上通信的能力（接收、发送消息，或两者）。

　　通常，在 Web 应用程序服务器中运行的 SOAP 服务器将执行这些功能。另外，我们也可以使用在 API 中封装这些功能的特定于编程语言的运行库。应用程序与 SOAP 的集成可以通过使用四个基本步骤来实现：

　　在图 4 中，服务提供者的应用程序在（1）创建一条 SOAP 消息。这条 SOAP 消息是调用由服务提供者提供的 Web 服务操作的请求。消息主体中的 XML 文档可以是一个 SOAP RPC 请求，也可以是一个服务描述中所描述的以文档为中心的消息。服务请求者将此信息和服务提供者的网址一起提供给 SOAP 基础结构（例如一个 SOAP 客户机运行时）。SOAP 客户机运行时与一个底层网络协议（例如 HTTP）交互，然后在网络上将 SOAP 消息发送出去。

　　网络基础结构在（2）将消息传送到服务提供者的 SOAP 运行时（例如一个 SOAP 服务器）。SOAP 服务器将请求消息路由到服务提供者的 Web 服务。如果应用程序需要，SOAP 运行时负责将 XML 消息转换为特定于编程语言的对象。这个转换由消息中可以找到的编码模式所控制。

　　Web 服务负责处理请求信息并生成一个响应。该响应也是一条 SOAP 消息。响应的 SOAP 消息在（3）被提供给 SOAP 运行时，其目的地是服务请求者。在 HTTP 上的同步请求／响应的情况中，联网协议的底层请求／响应本质用于实现消息传递的请求／响应本质。SOAP 运行时将 SOAP 消息响应发送到网络上的服务请求者。

　　响应消息在（4）由服务请求者节点上的联网基础结构接收。消息会经过整个 SOAP 基础结构；可能会将 XML 消息转换为目标编程语言中的对象。然后，响应消息被提供给应用程序。

　　本示例使用了请求／响应传送基本原理，这种原理在大多数分布式计算环境中都很常见。请求／响应交换可以是同步的，也可以是异步的。其它传送基本原理，如单向消息传递（无响应），通知（推动式响应）以及发布／订阅，也可能用到 SOAP。

　　那么，服务请求者如何知道请求消息应该使用什么格式呢？这个问题在下面一部分中会得到回答。