图 1 概括了地址查询 Web 服务的调用过程。尽管 WSDL 是服务提供者和服务请求者之间的协议，但 它对应用程序开发者了解调用细节却是个困难。在 Web 服务开发中，由于许多函数共享同样的对象数据类型，或者一个 Web 服务可以被其它 Web 服务共享，服务开发者理所当然地利用基于对象的技术和 UML 模型来开发服务。

    然而在实践中，对于服务请求者来说，很难了解哪一个 Web 服务被嵌入到其它服务中，或一个特定数据对象类型的组件是否被应用到 Web 服务。一旦服务提供者升级服务，服务请求者不得不相应地更新他们的应用程序。例如，在ArcWeb 服务的 1.0 版本中，还没有 point 数据类型， location 数据类型直接包含 x、y 的值。服务请求者将不得不更新他们的关于 ArcWeb 服务的应用程序以便从接收到的响应中从 Point 对象取出 x、y 坐标。否则，应用程序将运行失败。这是 Web 服务不够健壮和稳定的一个原因。

    图 1: 理解和调用地址查询 Web 服务的工作流
 

    本文研究的目标在于如何规范和简化 Web 服务，特别是地理空间信息 Web 服务的实现过程，使得服务请求者可以获取正确的结果，而不需要知道服务提供者是如何开发 Web 服务的。Vogels (2003) 声称 XML 文档是 Web 服务的基础，因为它包含服务客户发送给服务处理的所有特定于应用程序的信息。相对于封装的数据对象和嵌入的函数，服务请求者和服务提供者之间基于 XML 文档交换的通信能够更清楚地描述服务细节。

    通过语义请求和响应公开隐藏信息

    WSDL 的困惑源于 Web 服务开发过程基于软件工程的面向对象技术。 在面向对象编程中 (Schach， 2002)，对象是一个自我包含的程序单元，既包含数据也包含操纵数据的函数。由于对象封装了数据和函数实现，因此对于 Web 服务的应用程序开发者来说，对象是个黑盒。包含在对象中的隐藏信息使得应用程序开发者很难了解如何调用服务。

    WSDL 文件只是描述数据类型，包括数据类型的名字、操作和功能等，但并没有描述数据类型的意义。 一些数据类型通过名字元素来数据的内容，例如，地址查询 Web 服务的 WSDL 文件的 address 数据类型中， street 元素是 string 数据类型。 然而，在地址查询 Web 服务中，WSDL 文件中的 location 数据类型包含 2 个名为 <description1> 和 <description2> 的元素，而没有任何意义说明信息。

    <description1> 和 <description2> 是什么呢？在 Arc Web 服务的在线文档中，ESRI（2004）对这些元素作出如下说明：

    description1 包含位置的长描述信息 (如，Redlands， California， United States) 。 

    description2 包含位置的短描述信息 (如，Redlands)， 在地址查找服务中不使用它。 

    <description2> 不用在地址查询 Web 服务中，但是作为地址查询 Web 服务 WSDL 协议的一部分。 由此看来 WSDL 协议不是自我校验的，且当计算机程序生成 WSDL 文件时，不是明确组合的。因此可以认为面向对象技术在开发 Web 服务方面是有优势的，但是由面向对象编程中封装对象数据类型而得到的 WSDL 文件不适合服务请求者和服务提供者之间的交流。

    尽管 Web 服务技术解决了分布式计算系统之间的非互操作性技术难题，但它还应该克服计算机与开发人员之间的语义上难以互操作的障碍。为了公开封装在黑盒内部的隐藏信息以集成 Web 服务，如 清单 7 所示，看一下如何调用地址查询服务并了解整个实现过程。在本文中，利用 Visual Basic .NET 来进行示例编码，当然你可以利用 Java 编程或 C# 来实现同样的目的。