XML Web Service

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  体系结构的主要优点之一是：允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。对这一行业有所了解的用户可能马上会说：“等一等，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  的用户提出的第一个问题就是  SOAP  如何解决安全性问题。在其早期开发阶段，SOAP  被看作是基于  HTTP  的协议，所以认为  HTTP  的安全性对于  SOAP  已经足够了。毕竟目前有数以千计的  Web  应用程序都在使用  HTTP  安全性，所以这对于  SOAP  确实已经足够。因此，当前的  SOAP  标准假定安全性属于传输问题，而并不作为安全性问题处理。

当  SOAP  扩展至更为通用的协议，并运行于众多传输之上时，安全性问题就变得突出了。例如，HTTP  提供若干种方法对进行  SOAP  调用的用户进行身份验证，但是当消息从  HTTP  路由到  SMTP  传输时，怎样传播该身份标识呢？SOAP  是作为构造块协议进行设计的，所以幸运的是，已经有了相应的规范以基于  SOAP  为  Web  服务提供额外的安全保护功能。WS-Security  规范（英文）定义了一套完整的加密系统，而  WS-License  规范（英文）定义了相应的技术，以保证调用者的身份标识，并确保只有授权用户才可以使用  Web  服务。

WSDL
WSDL  (Web  Services  Description  Language)  表示  Web  服务说明语言。在本文中，我们可以认为  WSDL  文件是一个  XML  文档，用于说明一组  SOAP  消息以及如何交换这些消息。换句话说，WSDL  对于  SOAP  的作用就象  IDL  对于  CORBA  或  COM  的作用。由于  WSDL  是  XML  文档，因此很容易进行阅读和编辑；但大多数情况下，它由软件生成和使用。

要查看  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  接口的首选方法。

UDDI
通用发现、说明和集成  (UDDI)  是  Web  服务的黄页。与传统黄页一样，您可以搜索提供所需服务的公司，阅读以了解所提供的服务，然后与某人联系以获得更多信息。当然，您也可以提供  Web  服务而不在  UDDI  中注册，就象在地下室开展业务，依靠的是口头吆喝；但是如果您希望拓展市场，则需要  UDDI  以便能被客户发现。

UDDI  目录条目是介绍所提供的业务和服务的  XML  文件。UDDI  目录条目包括三个部分。“白页”介绍提供服务的公司：名称、地址、联系方式等等；“黄页”包括基于标准分类法（例如  North  American  Industry  Classification  System  和  Standard  Industrial  Classification）的行业类别；“绿页”详细介绍了访问服务的接口，以便用户能够编写应用程序以使用  Web  服务。服务的定义是通过一个称为类型模型（或  tModel）的  UDDI  文档来完成的。多数情况下，tModel  包含一个  WSDL  文件，用于说明访问  XML  Web  Service  的  SOAP  接口，但是  tModel  非常灵活，可以说明几乎所有类型的服务。

UDDI  目录还包含若干种方法，可用于搜索构建您的应用程序所需的服务。例如，您可以搜索特定地理位置的服务提供商或者搜索特定的业务类型。之后，UDDI  目录将提供信息、联系方式、链接和技术数据，以便您确定能满足需要的服务。