XML Web 服务基础结构

最新推荐文章于 2024-10-17 10:26:35 发布

hdy007

最新推荐文章于 2024-10-17 10:26:35 发布

阅读量936

点赞数

分类专栏： Java Web 文章标签： xml web soap internet 文档 url

Java 同时被 2 个专栏收录

303 篇文章 0 订阅

订阅专栏

Web

37 篇文章 0 订阅

订阅专栏

要在 Web 的多样性世界里取得成功，在涉及到操作系统、对象模型和编程语言的选择时，XML Web 服务不能有任何倾向性。同样，要使 XML Web 服务像其他基于 Web 的技术一样被广泛采用，必须符合下列条件：

　　松耦合的：如果对两个系统的唯一要求是要理解前面提到的自我描述的文本消息，那么这两个系统就被认为是松耦合的。另一方面，紧耦合系统要求大量自定义系统开销来进行通信，并要求系统之间有更多的了解。
　　常见的通信：大概不会有人会在现在或不远的将来构建一个无法连接到 Internet 的操作系统，因此，需要提供常见的通信信道。同样，能够将几乎所有系统或设备连接到 Internet 的能力将确保这样的系统和设备可以供连接到 Internet 的所有其他系统或设备使用。
　　通用数据格式：通过用现有的开放式标准而不是专用的封闭通信方法，任何支持同样的开放式标准的系统都能够理解 XML Web 服务。在采用自我描述的文本消息时，XML Web 服务及其客户端无须知道每个基础系统的构成即可共享消息，这使得自治系统和不同的系统之间能够进行通信。XML Web 服务使用 XML 实现此功能。

　　XML Web 服务采用的基础结构提供下列内容：定位 XML Web 服务的发现机制、定义如何使用这些服务的服务描述以及通信时使用的标准连网形式。下图显示了此基础结构的一个示例。

　　XML Web 服务基础结构

基础结构组件	角色
XML Web 服务目录	XML Web 服务目录提供一个用于定位其他组织提供的 XML Web 服务的中心位置。XML Web 服务目录(如 UDDI 注册表)充当此角色。XML Web 服务客户端可能参考也可能不参考 XML Web 服务的目录。
XML Web 服务发现	XML Web 服务发现是定位(或发现)使用 Web 服务描述语言 (WSDL) 描述特定 XML Web 服务的一个或多个相关文档的过程。DISCO 规范定义定位服务描述的算法。如果 XML Web 服务客户端知道服务描述的位置，则可以跳过发现过程。
XML Web 服务描述	要了解如何与特定的 XML Web 服务进行交互，需要提供定义该 XML Web 服务支持的交互功能的服务描述。XML Web 服务客户端必须知道如何与 XML Web 服务进行交互才可以使用该服务。
XML Web 服务连网形式	为实现通用的通信，XML Web 服务使用开放式连网形式进行通信，这些格式是任何能够支持最常见的 Web 标准的系统都可以理解的协议。SOAP 是 XML Web 服务通信的主要协议。

　　XML Web 服务目录

　　与 Internet 上的所有其他资源一样，如果没有某种手段搜索特定 XML Web 服务，那么就几乎不可能找到该服务。XML Web 服务目录提供一个中心位置，XML Web 服务提供程序可在其中发布与可用的 XML Web 服务有关的信息。这样的目录甚至可以就是 XML Web 服务本身，可以通过编程方式访问，并在响应来自潜在的 XML Web 服务客户端的查询时提供搜索结果。可能需要出于某一特定目的而使用 XML Web 服务目录来定位提供 XML Web 服务的组织，或者需要确定某个特定组织提供何种 XML Web 服务。DDI(通用说明、发现和集成)规范定义一个发布和发现有关 XML Web 服务的信息的标准方式。与 UDDI 关联的 XML 架构定义四种使开发人员能够使用已发布的 XML Web 服务的信息。它们是：业务信息、服务信息、绑定信息以及有关服务规范的信息。

　　作为 UDDI 项目的核心组件，UDDI 业务注册表使公司能够以编程方式定位有关其他组织公开的 XML Web 服务的信息。开发人员可以使用 UDDI 业务注册表定位发现文档和服务描述。有关更多信息，请参见 UDDI 网站 (http://uddi.microsoft.com)。

　XML Web 服务发现

　　XML Web 服务发现是定位(或发现)使用 Web 服务描述语言 (WSDL) 描述特定 XML Web 服务的一个或多个相关文档的过程。XML Web 服务客户端通过发现过程了解 XML Web 服务是否存在以及该 XML Web 服务的描述文档所处的位置。

　　已发布的 .disco 文件(包含指向描述该 XML Web 服务的其他资源的链接的 XML 文档)使以编程方式发现 XML Web 服务成为可能。下面显示了一个发现文档的结构的示例：

<?xml version="1.0" encoding="utf-8" ?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://www.contoso.com/Counter.asmx?wsdl"
                docRef="http://www.contoso.com/Counter.asmx"
                xmlns="http://schemas.xmlsoap.org/disco/scl/" />
    <soap address="http://www.contoso.com/Counter.asmx"
        xmlns:q1="http://tempuri.org/"
        binding="q1:CounterSoap"
        xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>

　　注意

　　发现文档是一些元素的容器，这些元素通常包含一些链接 (URL)，指向为 XML Web 服务提供发现信息的资源。如果 URL 是相对的，则假定相对于发现文档的位置。

　　但是，实现 XML Web 服务的网站不需要支持发现。另一站点可能负责描述服务，如 XML Web 服务目录。或者，可能不存在查找服务的公共方法，如在出于个人使用目的创建服务时。

　XML Web 服务描述

　　XML Web 服务基础结构是建立在通过基于 XML 的消息进行通信的基础上，这些消息符合已发布的服务描述。服务描述是使用称为 WSDL(Web 服务描述语言)的 XML 语法编写的 XML 文档，定义 XML Web 服务可以理解的消息格式。服务描述起协议的作用，定义 XML Web 服务的行为并指示潜在客户端如何与该服务进行交互。XML Web 服务的行为由该服务定义并支持的消息处理模式确定。这些模式在概念上指定在将格式正确的消息提交给 XML Web 服务时，该服务的使用者所能期望发生的操作。

　　例如，与远程过程调用 (RPC) 样式的服务关联的请求/响应模式将定义调用特定方法时所使用的 SOAP 消息架构。该模式还将定义随即产生的响应 SOAP 消息应遵循的格式。

　　另一个消息处理模式的例子是单向交互。该模式在要进行单向通信时使用。这种情况下，发送方将不接收任何来自 XML Web 服务的消息(包括错误消息)。对此，提醒您注意，如果建立单向通信时使用的是传统的请求/响应协议，则可能返回错误消息。

　　定义 SOAP 消息格式的架构可以在内部定义到实际的服务描述，也可在外部定义然后导入到服务描述中。

　　除消息格式定义和消息处理模式以外，服务描述还可以选择包含与每个 XML Web 服务入口点关联的地址。此地址的格式将适合用于访问服务的协议，例如，对于 HTTP 为 URL，而对于 SMTP 则为电子邮件地址。

　　有关 WSDL 规范，请访问 W3C 网站 (http://www.w3.org/TR/wsdl)。

　　XML Web 服务连网形式

　　二进制协议(如 DCOM)由在专用通信协议上运行的方法请求层组成。此类协议无益于创建通用的 XML Web 服务。然而，这并不防碍您在 XML Web 服务方案中使用此类协议，但使用它们的缺点是此类协议依赖于它们的基础系统的特定结构，因此会限制潜在客户端的范围。

　　或者，您可以构造使用一种或多种开放式协议(如 HTTP 和 SOAP 的组合)的 XML Web 服务。支持不同协议所需的基础结构各有不同。

　　XML Web 服务并不仅限于提供远程过程调用 (RPC) 访问。它们还可用于交换结构化信息(如采购订单和发票)以及用于自动化和连接内部与外部业务流程。

　　HTTP-GET 和 HTTP-POST

　　HTTP-GET 和 HTTP-POST 是使用 HTTP(超文本传输协议)谓词以及与之关联的请求语义将参数作为名称/值对编码和传递的标准协议。每个协议都由一系列 HTTP 请求头组成，这些头与一些其他信息一起定义客户端向服务器请求的内容，而在成功时，服务器将用一系列 HTTP 响应头和所请求的数据响应。

　　HTTP-GET 使用 application/x-www-form-urlencoded MIME 类型以 URL 编码文本格式传递其参数，该 MIME 类型追加到处理该请求的服务器的 URL 后。URL 编码是一种字符编码格式，它确保传递的参数由一致的文本组成(如将空格编码为 %20)。追加的参数也称为查询字符串。

　　与 HTTP-GET 类似，HTTP-POST 参数也是 URL 编码的。但是，名称/值对不是作为 URL 的一部分传递，而是在实际的 HTTP 请求消息中传递。

　　SOAP

　　SOAP 是一种基于 XML 的、用于在 Web 上交换结构化和类型信息的简单的轻型协议。SOAP 的总体设计目标是使其尽可能地简单，并提供最少的功能。该协议定义一个不包含任何应用程序或传输语义的消息处理框架。因此，该协议是模块化的，并具有很强的扩展性。

　　通过在标准传输协议上传输，SOAP 能够利用现有的 Internet 的开放式结构并可轻松地为能够支持最基本的 Internet 标准的任意系统所接受。可以认为支持符合 SOAP 的 XML Web 服务所需的基础结构极其简单但却功能强大，原因是它向现有的 Internet 基础结构添加的内容相对较少，但仍能支持用 SOAP 生成的服务的通用访问。

　　SOAP 协议规范包含四个主要组成部分。第一部分定义用于封装数据的必需的可扩展信封。该 SOAP 信封定义 SOAP 消息，并且是 SOAP 消息处理器之间的基本交换单位。这是该规范唯一必需的部分。

　　SOAP 协议规范的第二部分定义用来表示应用程序定义的数据类型和有向图形的可选数据编码规则，以及一个用于序列化非句法数据模型的统一模型。

　　第三部分定义 RPC 样式(请求/响应)的消息交换模式。每个 SOAP 消息都是单向传输。尽管 SOAP 的根位于 RPC 中，但它不仅仅只是请求/响应机制。XML Web 服务经常组合 SOAP 消息以实现此类模式，但 SOAP 并不强制要求消息交换模式，这部分规范也是可选的。

　　规范的第四部分定义 SOAP 和 HTTP 之间的绑定。但该部分也是可选的。可以将 SOAP 与任何能够传输 SOAP 信封的传输协议或机制(包括 SMTP、FTP 甚至软盘)结合在一起使用。

　　有关 SOAP 规范，请访问 W3C 网站 (http://www.w3.org/TR/soap)。