XML Web Services 基础知识

2007-04-03

罗杰·沃尔特
Microsoft Corporation

2001 年 12 月

总结： 概述面向开发人员的 XML Web 服务的价值，并介绍了 SOAP、WSDL 和 UDDI。 ) (6 个打印页

什么是 XML Web 服务？

XML Web 服务是在 Internet 上迁移到分布式计算的基础构建基块。开放标准以及对人员和应用程序之间的通信和协作的关注创造了一个环境，其中 XML Web 服务正在成为应用程序集成的平台。应用程序是使用来自各种源的多个 XML Web 服务构造的，这些服务协同工作，无论它们驻留在何处或实现方式如何。

XML Web Service 的定义可能和构建它们的公司一样多，但几乎所有定义都有以下共同点：

XML Web Services 通过标准 Web 协议向 Web 用户公开有用的功能。在大多数情况下，使用的协议是 SOAP。
XML Web 服务提供了一种足够详细地描述其接口的方法，以允许用户生成客户端应用程序来与其通信。此说明通常在名为 Web 服务描述语言的 XML 文档中提供 (WSDL) 文档。
注册 XML Web 服务，以便潜在用户可以轻松找到它们。这是使用通用发现说明和集成 (UDDI) 完成的。

在本文中，我将介绍这三种技术，但首先我想解释为何应关注 XML Web 服务。

XML Web 服务体系结构的主要优点之一是，它允许在不同平台上以不同语言编写的程序以基于标准的方式相互通信。你们这些在业内有一段时间的人现在说，“等一下！我没有从 CORBA 和之前听到同样的承诺吗？这有什么不同？”第一个区别是 SOAP 比早期方法复杂得多，因此符合标准的 SOAP 实现的进入门槛要低得多。 Paul Kulchenko 维护 SOAP 实现列表： http://www.soapware.org/directory/4/implementations 该列表最后计数包含 79 个条目。你会看到大多数大型软件公司的 SOAP 实现，正如你所期望的那样，但你也会发现许多由单个开发人员构建和维护的实现。与之前的工作相比，XML Web 服务的另一个显著优势是，它们适用于标准 Web 协议（XML、HTTP 和 TCP/IP）。相当多的公司已经拥有 Web 基础结构，并且拥有维护 Web 基础结构的知识和经验的人员，因此，XML Web 服务的进入成本也明显低于以前的技术。

我们已将 XML Web 服务定义为通过 SOAP 在 Web 上公开的软件服务，使用 WSDL 文件进行描述并在 UDDI 中注册。下一个逻辑问题是。 “我可以使用 XML Web 服务做什么？”第一个 XML Web 服务往往是可轻松合并到应用程序中的信息源-股票报价、天气预报、体育分数等。很容易想象一大类应用程序，这些应用程序可以构建为分析和聚合你关心的信息，并通过多种方式呈现给你;例如，你可能有一个 Microsoft® Excel 电子表格，用于汇总你的整个财务情况-股票、401K、银行帐户、贷款等。如果此信息通过 XML Web 服务提供，Excel 可以持续更新它。其中一些信息是免费的，有些可能需要订阅服务。大部分此信息现已在 Web 上提供，但 XML Web 服务将使以编程方式访问它更轻松、更可靠。

将现有应用程序公开为 XML Web 服务将允许用户生成使用 XML Web 服务作为构建基块的更强大的新应用程序。例如，用户可能会开发一个购买应用程序来自动从各种供应商处获取价格信息，允许用户选择供应商，提交订单，然后跟踪发货，直到收到。除了在 Web 上公开其服务外，供应商应用程序还可能反过来使用 XML Web 服务来检查客户的信用额度、向客户的帐户收费，以及向运输公司设置发货。

将来，一些最有趣的 XML Web 服务将支持使用 Web 的应用程序执行目前无法完成的事情。例如，XML Web Services 可以实现的服务之一是日历服务。如果你的牙医和机械师通过此 XML Web 服务公开了他们的日历，你可以与他们在线安排约会，也可以根据需要直接在你的日历中安排清洁和日常维护的约会。只要有一点想象力，就可以设想成百上千个应用程序，一旦能够对 Web 进行编程，就可以生成这些应用程序。

有关 XML Web 服务和它们将帮助你构建的应用程序的详细信息，请参阅 MSDN XML Web Services 开发人员中心。

SOAP

Soap 是 XML Web 服务的通信协议。当 SOAP 被描述为通信协议时，大多数人会想到 DCOM 或 CORBA，然后开始询问诸如“SOAP 如何激活对象？”或“SOAP 使用什么命名服务？”虽然 SOAP 实现可能包含这些内容，但 SOAP 标准不会指定它们。 SOAP 是一种规范，用于定义消息的 XML 格式，这与规范的必需部分有关。如果一个格式正确的 XML 片段包含在几个 SOAP 元素中，则会显示一条 SOAP 消息。简单不是吗？

SOAP 规范的其他部分介绍了如何将程序数据表示为 XML，以及如何使用 SOAP 执行远程过程调用。规范的这些可选部分用于实现 RPC 样式的应用程序，其中，包含可调用函数的 SOAP 消息以及要传递给函数的参数从客户端发送，服务器返回包含已执行函数结果的消息。 SOAP 的大多数当前实现都支持 RPC 应用程序，因为习惯于执行 COM 或 CORBA 应用程序的程序员理解 RPC 样式。 SOAP 还支持文档样式应用程序，其中 SOAP 消息只是 XML 文档的包装器。文档样式的 SOAP 应用程序非常灵活，许多新的 XML Web 服务利用这种灵活性来生成使用 RPC 难以实现的服务。

SOAP 规范的最后一个可选部分定义包含 SOAP 消息的 HTTP 消息的外观。此 HTTP 绑定非常重要，因为几乎所有当前 OS 的 (和许多当前操作系统的) 都支持 HTTP。 HTTP 绑定是可选的，但几乎所有 SOAP 实现都支持它，因为它是 SOAP 的唯一标准化协议。因此，有一个常见的误解，即 SOAP 需要 HTTP。某些实现支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但几乎所有当前的 XML Web 服务都使用 HTTP，因为它无处不在。由于 HTTP 是 Web 的核心协议，因此大多数组织都有支持 HTTP 的网络基础结构，以及已经了解如何管理 HTTP 的人员。 HTTP 的安全性、监视和负载均衡基础结构现已推出。

开始使用 SOAP 时，造成混淆的一个主要来源是 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 服务的理想基础。有关 SOAP 的详细信息，请参阅 MSDN SOAP 主页。

安全性如何？

SOAP 新人首先问到的一个问题是 SOAP 如何处理安全性。在开发初期，SOAP 被视为基于 HTTP 的协议，因此假设 HTTP 安全性足以满足 SOAP 要求。毕竟，目前有数千个 Web 应用程序使用 HTTP 安全性运行，因此这确实足以满足 SOAP 的需求。出于此原因，当前的 SOAP 标准假定安全性是一个传输问题，并且对于安全问题是无提示的。

当 SOAP 扩展为在大量传输上运行的更通用的协议时，安全性成为更大的问题。例如，HTTP 提供了多种方式来验证哪个用户正在进行 SOAP 调用，但是当消息从 HTTP 路由到 SMTP 传输时，如何传播该标识？ SOAP 被设计为构建基块协议，因此幸运的是，在 SOAP 的基础上构建，为 Web 服务提供其他安全功能的工作中已有规范。 WS-Security 规范定义了一个完整的加密系统。

WSDL

WSDL (通常发音为 whiz-dull) 代表 Web 服务描述语言。就我们的目的而言，我们可以说 WSDL 文件是一个 XML 文档，用于描述一组 SOAP 消息以及如何交换消息。换句话说，WSDL 是将 IDL 用于 CORBA 或 COM。由于 WSDL 是 XML，因此它是可读和可编辑的，但在大多数情况下，它由软件生成和使用。

若要查看 WSDL 的值，假设你要开始调用某个业务合作伙伴提供的 SOAP 方法。你可以要求他提供一些示例 SOAP 消息，并编写应用程序以生成和使用类似于示例的消息，但这很容易出错。例如，你可能会看到客户 ID 2837，并假设它是一个整数，而实际上它是一个字符串。 WSDL 指定请求消息必须包含的内容，以及响应消息在明确表示法中的外观。

WSDL 文件用于描述消息格式的表示法基于 XML 架构标准，这意味着它既是非特定编程语言又基于标准的，这使得它适合描述可从各种平台和编程语言访问的 XML Web Services 接口。除了描述消息内容外，WSDL 还定义服务可用的位置以及用于与服务通信的通信协议。这意味着 WSDL 文件定义编写程序以使用 XML Web 服务所需的所有内容。有多种工具可用于读取 WSDL 文件并生成与 XML Web 服务通信所需的代码。其中一些功能最强大的工具位于 Microsoft Visual Studio® .NET 中。

许多当前的 SOAP 工具包都包括从现有程序接口生成 WSDL 文件的工具，但用于直接编写 WSDL 的工具很少，并且对 WSDL 的工具支持也不像应该的那样完整。编写 WSDL 文件，然后生成代理和存根的工具应该不会太久，就像 COM IDL 工具一样成为大多数 SOAP 实现的一部分。此时，WSDL 将成为为 XML Web 服务创作 SOAP 接口的首选方法。

提供了 WSDL 的精彩说明，可以在中找到 WSDL 规范 http://www.w3.org/TR/wsdl。

UDDI

通用发现说明和集成是 Web 服务的黄色页面。与传统的黄页一样，可以搜索提供所需服务的公司，阅读所提供服务的相关信息，并联系某人获取详细信息。当然，你可以提供 Web 服务而无需在 UDDI 中注册，就像你可以在地下室开设一家企业并依靠口碑广告一样，但如果你想进入一个重要的市场，你需要 UDDI，以便你的客户可以找到你。

UDDI 目录条目是描述企业及其提供的服务的 XML 文件。 UDDI 目录中的条目有三个部分。 “白页”描述了提供服务的公司：姓名、地址、联系人等。“黄页”包括基于标准分类的工业类别，例如北美行业分类系统和标准工业分类。 “绿页”非常详细地描述了服务的接口，以便有人编写应用程序以使用 Web 服务。定义服务的方式是通过名为类型模型或 tModel 的 UDDI 文档。在许多情况下，tModel 包含描述 XML Web 服务的 SOAP 接口的 WSDL 文件，但 tModel 非常灵活，几乎可以描述任何类型的服务。

UDDI 目录还包括几种搜索生成应用程序所需的服务的方法。例如，可以在指定地理位置或指定类型的企业中搜索服务的提供商。然后，UDDI 目录将提供信息、联系人、链接和技术数据，以便评估哪些服务符合你的要求。

UDDI 允许你查找可能想要从中获取 Web 服务的企业。如果你已经知道要与谁做生意，但不知道提供了哪些服务，该怎么办？ WS-Inspection 规范允许浏览特定服务器上提供的 XML Web 服务的集合，以查找哪些服务可能满足你的需求。

有关 UDDI 的详细信息，请参阅 http://www.uddi.org/about.html。

还剩下什么？

到目前为止，我们已经讨论了如何 (SOAP) 与 XML Web 服务通信，如何 (WSDL) 描述 XML Web 服务，以及如何 (UDDI) 查找 XML Web 服务。这些规范构成了一组基线规范，为应用程序集成和聚合提供了基础。从这些基线规范中，公司正在构建真正的解决方案，并从中获得真正的价值。

尽管为使 XML Web 服务成为现实做了大量工作，但还需要做更多工作。如今，人们在 XML Web 服务方面取得了成功，但仍有一些工作留给开发人员®，例如安全性、运营管理、事务、可靠的消息传递。全局 XML Web Services 体系结构将提供一个一致的常规用途模型，用于向模块化和可扩展的 XML Web 服务添加新的高级功能，从而帮助将 XML Web 服务提升到下一个级别。

WS-Security 是全局 Web 服务体系结构中的规范之一。操作管理需求（例如在多个服务器之间路由消息和动态配置这些服务器进行处理）也是全球 Web 服务体系结构的一部分， WS 路由规范和 WS-Referral 规范也满足这些需求。随着全球 Web 服务体系结构的发展，将引入针对这些需求和其他需求的规范。

有关详细信息，请参阅全局 XML Web Services 体系结构。

通过