XML Web Services 基础知识

  • 项目

 

罗杰·沃尔特
Microsoft Corporation

2001 年 12 月

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

目录

什么是 XML Web 服务？
SOAP
WSDL
UDDI
剩下什么？

什么是 XML Web 服务？

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

XML Web 服务的定义可能和有公司一样多，但几乎所有定义都有这些共同点：

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

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

XML Web 服务体系结构的主要优点之一是，它允许在不同平台上以不同语言编写的程序以基于标准的方式相互通信。 你身边的人现在说：“等一分钟！ 我没有听到 CORBA 和 DCE 之前的相同承诺？ 这有什么不同？第一个区别是 SOAP 比早期方法要复杂得多，因此符合标准的 SOAP 实现的入口门槛要低得多。 Paul Kulchenko 维护 SOAP 实现列表： http://www.soapware.org/directory/4/implementations 最后的计数包含 79 个条目。 你将从大多数大型软件公司中找到 SOAP 实现，正如预期的那样，但也会发现许多由单个开发人员构建和维护的实现。 XML Web 服务在先前的努力中具有的另一个显著优势是，它们使用标准 Web 协议-XML、HTTP 和 TCP/IP。 许多公司已经拥有 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 服务可能实现的服务之一是日历服务。 如果你的牙医和机械师通过此 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。 HTTP 绑定是可选的，但几乎所有 SOAP 实现都支持它，因为它是 SOAP 的唯一标准化协议。 因此，SOAP 需要 HTTP 有一个常见的误解。 某些实现支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但几乎所有当前的 XML Web 服务都使用 HTTP，因为它无处不在。 由于 HTTP 是 Web 的核心协议，因此大多数组织都有一个网络基础结构，支持 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 (通常发音低调) 代表 Web 服务描述语言。 出于我们的目的，我们可以说 WSDL 文件是一个 XML 文档，用于描述一组 SOAP 消息以及如何交换消息。 换句话说，WSDL 是 SOAP 对 CORBA 或 COM 的 IDL。 由于 WSDL 是 XML，因此它是可读和可编辑的，但在大多数情况下，它由软件生成和使用。

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

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

许多当前的 SOAP 工具包包括用于从现有程序接口生成 WSDL 文件的工具，但很少有用于直接编写 WSDL 的工具，并且 WSDL 的工具支持不如原样完整。 编写 WSDL 文件的工具之前不久，生成代理和存根与 COM IDL 工具非常类似，将成为大多数 SOAP 实现的一部分。 此时，WSDL 将成为为 XML Web 服务创作 SOAP 接口的首选方法。

WSDL 的出色说明可用，可以在其中 http://www.w3.org/TR/wsdl找到 WSDL 规范。

UDDI

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

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

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

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

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

左派是什么？

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

虽然做了大量工作，使 XML Web 服务成为现实，但需要更多的工作。 如今，人们对 XML Web 服务取得了成功，但仍有一些内容作为开发人员®的练习，例如安全性、操作管理、事务、可靠的消息传送。 Global XML Web Services 体系结构将通过提供一个一致的常规用途模型，将 XML Web 服务提升到下一级别，以便向模块化和可扩展的 XML Web 服务添加新的高级功能。

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

有关 全局 XML Web 服务体系结构的详细信息。