XML Web Service 是在 Internet 上进行分布式计算的基本构造块。开放的标准以及对用户和应用程序之间的通信和协作的关注产生了这样一种环境，在这种环境下，XML Web Service 成为应用程序集成的平台。应用程序是通过使用多个不同来源的 XML Web Service 构造而成的，这些服务相互协同工作，而不管它们位于何处或者如何实现。
有多少个构建 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。
XML Web Service 体系结构的主要优点之一是：允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。对这一行业有所了解的用户可能马上会说：“等一等，CORBA 和之前的 DCE 不是都做过相同的承诺吗？这和它们有什么区别？”最重要的区别在于：SOAP 比以前的方法要简单得多，因此要实现与标准兼容的 SOAP，障碍也要少得多。Paul Kulchenko 在 http://www.soapware.org/directory/4/implementations（英文）上提供了一个 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 Web Service 的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOAP 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 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（英文）主页。
安全性如何？