XML Web Service 是在 Internet 上进行分布式计算的基本构造块。开放的标准以及对用户和应用程序之间的通信和协作的关注产生了这样一种环境，在这种环境下，XML Web Service 成为应用程序集成的平台。应用程序是通过使用多个不同来源的 XML Web Service 构造而成的，这些服务相互协同工作，而不管它们位于何处或者如何实现。 本文将介绍这三种技术，但首先需要解释一下为什么要关注 XML Web Service。 Soap 是 XML Web Service 的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOAP 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。这是不是很简单？ 通常，刚接触 SOAP 的用户提出的第一个问题就是 SOAP 如何解决安全性问题。在其早期开发阶段，SOAP 被看作是基于 HTTP 的协议，所以认为 HTTP 的安全性对于 SOAP 已经足够了。毕竟目前有数以千计的 Web 应用程序都在使用 HTTP 安全性，所以这对于 SOAP 确实已经足够。因此，当前的 SOAP 标准假定安全性属于传输问题，而并不作为安全性问题处理。 WSDL (Web Services Description Language) 表示 Web 服务说明语言。在本文中，我们可以认为 WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。换句话说，WSDL 对于 SOAP 的作用就象 IDL 对于 CORBA 或 COM 的作用。由于 WSDL 是 XML 文档，因此很容易进行阅读和编辑；但大多数情况下，它由软件生成和使用。 通用发现、说明和集成 (UDDI) 是 Web 服务的黄页。与传统黄页一样，您可以搜索提供所需服务的公司，阅读以了解所提供的服务，然后与某人联系以获得更多信息。当然，您也可以提供 Web 服务而不在 UDDI 中注册，就象在地下室开展业务，依靠的是口头吆喝；但是如果您希望拓展市场，则需要 UDDI 以便能被客户发现。 到现在为止，我们已经讨论了如何与 XML Web Service 通信 (SOAP)，XML Web Service 是怎样进行说明的 (WSDL)，以及如何查找 XML Web Service (UDDI)。这些内容构成了一套基本规范，为应用程序的集成和聚合提供了基础。根据这些基本规范，公司可以构建实际的解决方案，并从中获益。
有多少个构建 XML Web Service 的公司，就可能有多少种 XML Web Service 定义。不过几乎所有定义都具有以下共同点：
XML Web Service 通过标准的 Web 协议向 Web 用户提供有用的功能。多数情况下使用 SOAP 协议。
XML Web Service 可以非常详细地说明其接口，这使用户能够创建客户端应用程序与它们进行通信。这种说明通常包含在称为 Web 服务说明语言 (WSDL) 文档的 XML 文档中。
XML Web Service 已经过注册，以便潜在用户能够轻易地找到这些服务，这是通过通用发现、说明和集成 (UDDI) 来完成的。
XML Web Service 体系结构的主要优点之一是：允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。对这一行业有所了解的用户可能马上会说：“等一等，CORBA 和之前的 DCE 不是都做过相同的承诺吗？这和它们有什么区别？”最重要的区别在于：SOAP 比以前的方法要简单得多，因此要实现与标准兼容的 SOAP，障碍也要少得多。Paul Kulchenko 在 （英文）上提供了一个 SOAP 实现方案的列表。上次统计时，该列表已经包含了 79 项。正如您所预料，多数大的软件公司都提供 SOAP 实现方案，但也有许多实现方案是由个别开发人员创建和维护的。相对以前的方案而言，XML Web Service 的另一大优点是使用标准的 Web 协议 - XML、HTTP 和 TCP/IP。许多公司都已经建立了 Web 基础结构，同时它们的员工在维护方面也都具备相应的知识和经验。因此，引入 XML Web Service 与引入以前的技术相比，其成本要低得多。
我们将 XML Web Service 定义为：通过 SOAP 在 Web 上提供的软件服务，使用 WSDL 文件进行说明，并通过 UDDI 进行注册。那么，您也许要问：“使用 XML Web Service 能够做什么？”最初的 XML Web Service 通常是可以方便地并入应用程序的信息来源，如股票价格、天气预报、体育成绩等等。我们很容易想到，可以构建一整类应用程序以分析和汇总所关心的信息，并以各种方式提供这些信息；例如，您可以使用 Microsoft® Excel 电子表格来汇总所有的财务信息 - 股票、401K、银行存款、贷款等等。如果能够通过 XML Web Service 获得这些信息，Excel 就可以不断对其进行更新。这些信息中有些是免费的，有些则可能需要订阅才能获得相应服务。大部分这种信息现在已经可以在 Web 上找到了，但是 XML Web Service 可以使编程访问更简单，也更可靠。
以 XML Web Service 方式提供现有应用程序，可以构建新的、更强大的应用程序，并利用 XML Web Service 作为构造块。例如，用户可以开发一个采购应用程序，以自动获取来自不同供应商的价格信息，从而使用户可以选择供应商，提交订单，然后跟踪货物的运输，直至收到货物。而供应商的应用程序除了在 Web 上提供服务外，还可以使用 XML Web Service 检查客户的信用、收取货款，并与货运公司办理货运手续。
将来，某些最有趣的 XML Web Service 所支持的应用程序还可以利用 Web 完成目前无法完成的任务。例如，日历服务就是 Microsoft .NET My Services（英文）项目即将支持的服务之一。如果您的牙医和机械师通过这一 XML Web Service 提供其日程安排，您就可以通过网络与他们安排约会；如果您愿意，他们也可以直接在您的日历上约定清洁和日常保养的日期。不难想象，只要能够对 Web 进行编程，您就可以创建数以百计的应用程序。
有关 XML Web Service 及其可以构建的应用程序的详细信息，请参阅 MSDN Web 服务（英文）主页。
SOAP
SOAP 规范的其他部分介绍如何将程序数据表示为 XML，以及如何使用 SOAP 进行远程过程调用 (RPC)。这些可选的规范部分用于实现 RPC 形式的应用程序，其中客户端将发出一条 SOAP 消息（包含可调用函数，以及要传送到该函数的参数），然后服务器将返回包含函数执行结果的消息。目前，多数 SOAP 实现方案都支持 RPC 应用程序，这是因为习惯于开发 COM 或 CORBA 应用程序的编程人员熟悉 RPC 形式。SOAP 还支持文档形式的应用程序，在这类应用程序中，SOAP 消息只是 XML 文档的一个包装。文档形式的 SOAP 应用程序非常灵活，许多新的 XML Web Service 都利用这一特点来构建使用 RPC 难以实现的服务。
SOAP 规范的最后一个可选部分定义了包含 SOAP 消息的 HTTP 消息的样式。此 HTTP 绑定非常重要，因为几乎所有当前的 OS（以及许多以前的 OS）都支持 HTTP。HTTP 绑定虽然是可选的，但几乎所有 SOAP 实现方案都支持 HTTP 绑定，因为它是 SOAP 的唯一标准协议。由于这一原因，人们通常误认为 SOAP 必须使用 HTTP。其实，有些实现方案也支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但由于 HTTP 非常普遍，几乎所有当前的 XML Web Service 都使用它。由于 HTTP 是 Web 的核心协议，因此大多数组织的网络基础结构都支持 HTTP，并且员工已经了解了如何对其进行管理。如今，已经建立了用于 HTTP 的安全保护、监视和负载平衡的基础结构。
开始使用 SOAP 时，最容易混淆的是 SOAP 规范及其许多实现方案之间的差异。多数使用 SOAP 的用户并不直接编写 SOAP 消息，而是使用 SOAP 工具包来创建和分析 SOAP 消息。这些工具包通常将函数调用从某种语言转换为 SOAP 消息。例如，Microsoft SOAP Toolkit 2.0 将 COM 函数调用转换为 SOAP，而 Apache Toolkit 将 JAVA 函数调用转换为 SOAP。函数调用的类型和支持的参数的数据类型随每个 SOAP 实现方案的不同而不同，因此适用于一个工具包的函数可能并不适用于另一个工具包。这并不是 SOAP 的限制，而是所使用的特定实现方案的限制。
到目前为止，SOAP 最引人注目的特征是它可以在许多不同的软件和硬件平台上实现。这意味着 SOAP 可用于链接企业内部和外部的不同系统。过去曾试过多种方法以提出一个可用于系统集成的通用通信协议，但它们都没有象 SOAP 一样获得广泛的认可。为什么呢？因为与许多早期的协议相比，SOAP 更小巧，而且更易于实现。例如，DCE 和 CORBA 的实现需要数年时间，所以只发布了很少几个实现方案。而 SOAP 可以利用现有的 XML 分析器和 HTTP 库完成大部分艰苦的工作，因此 SOAP 实现方案在数月内便可完成。这就是为什么现在已经有 70 多个 SOAP 实现方案的原因。当然，SOAP 并不具备 DCE 或 CORBA 的全部功能，虽然功能减少了，但由于其复杂程度大大降低了，因此 SOAP 更易于应用。
HTTP 的普及和 SOAP 的简单性使您几乎可以从任何环境调用它们，因此成为 XML Web Service 的理想基础。有关 SOAP 的详细信息，请参阅 MSDN SOAP（英文）主页。
安全性如何？
当 SOAP 扩展至更为通用的协议，并运行于众多传输之上时，安全性问题就变得突出了。例如，HTTP 提供若干种方法对进行 SOAP 调用的用户进行身份验证，但是当消息从 HTTP 路由到 SMTP 传输时，怎样传播该身份标识呢？SOAP 是作为构造块协议进行设计的，所以幸运的是，已经有了相应的规范以基于 SOAP 为 Web 服务提供额外的安全保护功能。WS-Security 规范（英文）定义了一套完整的加密系统，而 WS-License 规范（英文）定义了相应的技术，以保证调用者的身份标识，并确保只有授权用户才可以使用 Web 服务。
WSDL
要查看 WSDL 的值，可以假设您要调用由您的一位业务伙伴提供的 SOAP 方法。您可以要求对方提供一些 SOAP 消息示例，然后编写您的应用程序以生成并使用与示例类似的消息，但这样很容易出错。例如，您可能看到一个 2837 的客户 ID，并假设它为整数，而实际上它是一个字符串。WSDL 通过明确的表示法指定请求消息必须包含的内容以及响应消息的样式。
WSDL 文件用于说明消息格式的表示法以 XML 架构标准为基础，这意味着它与编程语言无关，而且以标准为基础，因此适用于说明可从不同平台、以不同编程语言访问的 XML Web Service 接口。除说明消息内容外，WSDL 还定义了服务的位置，以及使用什么通信协议与服务进行通信。也就是说，WSDL 文件定义了编写使用 XML Web Service 的程序所需的全部内容。有几种工具可以读取 WSDL 文件，并生成与 XML Web Service 通信所需的代码。其中一些最强大的工具可在 Microsoft Visual Studio® .NET 中找到。
当前，许多 SOAP 工具包都包括从现有程序接口生成 WSDL 文件的工具，但却几乎没有直接用于编写 WSDL 的工具，而且 WSDL 的工具支持也很不完整。但不久就会出现编写 WSDL 文件的工具，接着还会有生成代理和存根的工具（与 COM IDL 工具很相似），这些工具将成为多数 SOAP 实现方案的一部分。到那时，WSDL 将成为创建 XML Web Service 的 SOAP 接口的首选方法。
这里有一个非常好的 WSDL 说明（英文），您还可以在 （英文）找到 WSDL 规范。
UDDI
UDDI 目录条目是介绍所提供的业务和服务的 XML 文件。UDDI 目录条目包括三个部分。“白页”介绍提供服务的公司：名称、地址、联系方式等等；“黄页”包括基于标准分类法（例如 North American Industry Classification System 和 Standard Industrial Classification）的行业类别；“绿页”详细介绍了访问服务的接口，以便用户能够编写应用程序以使用 Web 服务。服务的定义是通过一个称为类型模型（或 tModel）的 UDDI 文档来完成的。多数情况下，tModel 包含一个 WSDL 文件，用于说明访问 XML Web Service 的 SOAP 接口，但是 tModel 非常灵活，可以说明几乎所有类型的服务。
UDDI 目录还包含若干种方法，可用于搜索构建您的应用程序所需的服务。例如，您可以搜索特定地理位置的服务提供商或者搜索特定的业务类型。之后，UDDI 目录将提供信息、联系方式、链接和技术数据，以便您确定能满足需要的服务。
UDDI 允许您查找提供所需的 Web 服务的公司。如果您已经知道要与谁进行业务合作，但尚不了解它还能提供哪些服务，这时该如何处理呢？WS-Inspection 规范（英文）允许您浏览特定服务器上提供的 XML Web Service 的集合，从中查找所需的服务。
有关 UDDI 的详细信息，请访问 （英文）。
其他内容
为实现 XML Web Service，我们已经做了许多工作，但仍有大量工作需要完成。今天，人们已经使用 XML Web Service 取得了成功，但对于开发人员来说，仍有许多环节需要完善。例如，安全性、运营管理、事务处理以及可靠的消息传递等。Global XML Web Services Architecture 将通过以下方式帮助 XML Web Service 进入下一个发展阶段：提供一个一致的通用模型，以模块化和可扩展的方式向 XML Web Service 添加新的高级功能。
上面提到的安全模块（WS-Security [英文] 和 WS-License [英文]）就是 Global Web Services Architecture 规范的一部分。运营管理的需要（例如在多个服务器之间路由消息，以及动态配置这些服务器以便进行处理）也是 Global Web Services Architecture 的一部分，它们是通过 WS-Routing 规范（英文）和 WS-Referral 规范（英文）来实现的。随着 Global Web Services Architecture 的发展，还将进一步介绍满足上述需要以及其他需要的规范。
