【IT168 信息化】

    引言

    通过 Web 服务描述语言（WSDL）接口，Web 服务技术为分布式计算系统的动态绑定提供了基础，使得它们可以在异构的计算机网络间实现数据和函数的传输和交互。WSDL 可能会包含嵌入式 Web 服务或在多个 Web 服务间共享通用对象数据类型，由于数据和服务的内容和意义不能够被描述，WSDL 对那些想把 Web 服务集成到自己应用程序中的应用程序开发者来说是个困惑的问题。可以预见，在不远的将来，将会有大量不同服务者提供的 Web 服务大量出现，那么对于应用程序开发者来说，即使提供对象模型、流程图以及其它一些辅助信息资料，跟踪和理解这些 Web 服务调用的操作方法也会很困难。

    将服务请求和响应规范化为基于 XML 文档的形式，以取代服务请求者和服务交互者之间交互的数据对象和函数，开发和利用地理空间 Web 服务的提议将明显改善地理空间 Web 服务的交流和实现过程。这一方法将 公开封装在面向对象技术中的隐藏信息，同时又 隐藏了实现细节；开发过程的简化将产生更加可靠的地理空间 Web 服务，并且这些地理空间 Web 服务具备智能化集成到分布式计算系统中的能力。它建议 Web 服务描述的新标准和新规范，特别是地理空间 Web 服务术语和标记的定义应该公式化，这样使得它可以进一步构建新一代地理空间 Web 服务以进行集成映射和地理信息处理，否则，这一问题对于地理信息系统（GIS）和 GIS 组织将会是个大难题。

    WSDL 的困惑

    WSDL 是开发和部署 Web 服务的核心概念，因为它在服务提供者和服务请求者之间建立了协议。WSDL 描述了输入输出变量的数据类型、每一个服务的操作集的名称、客户调用服务必须遵守的格式等等。然而，WSDL 协议 不包括： 请求服务所必须的一切信息。为理解如何调用 Web 服务，服务请求者必须至少满足下面条件中的一条：

    ·了解 Web 服务是如何构建的实现细节。 
    ·处理 WSDL 文件。 
    ·找到协议外的必要信息。 
    · 跟踪服务的对象图。 
    ·从示例中学习。 

    本文利用一个名为 ArcWeb 的服务作为示例，它来自于 ESRI，一个 GIS 软件和技术领域的知名公司。 对于示例中 ESRI 的 ArcWeb 服务，它的地址查询 Web 服务通过一个名为 findAddress 的函数来查找一个指定地址的位置（经度和纬度）。你可以在 http://arcweb.esri.com/services/v2/AddressFinder.wsdl 中找到地址查询 Web 服务的 WSDL 文件。由于 WSDL 是服务请求者和服务提供者之间的协议，服务请求者必须首先通过研究协议的内容来了解如何调用这一服务。

    WSDL 文件中的下述部分，如 清单 1 所示，描述了怎样调用 findAddress 函数，作为 <portType> 元素，它被定义为一组操作以及包含在每个操作中的消息。

    清单 1: 地址查询 Web 服务的 WSDL 文件 -- <portType> 元素

    <portType name="IAddressFinder">  
     <operation 
    name="findAddress" 
    parameterOrder=
     "address addressFinderOptions token">
    <documentation>Returns an x,y-coordinate from an address.</documentation>
    <
    input name="findAddress1In" 
    message="tns:findAddress1In" />
    <
    output name="findAddress1Out" 
    message="tns:findAddress1Out" />
    </operation>
    </portType>
    
    这里， <message> 元素描述了将被传递的消息 -- 输入消息被命名为 findAddress1In，输出消息被命名为 findAddress1out。你可以在 WSDL 文件的下面片段跟踪 <message> 元素的详细信息。

    清单 2: 地址查询 Web 服务的 WSDL 文件 -- <message> 元素
    
    <message name="
    findAddress1In">
     <part name="address" 
    type="ns13:Address">
    <documentation>the address find x,y-coordinates for.</documentation>
    </part> 
    <part name="addressFinderOptions" 
    type="ns13:AddressFinderOptions">
    <documentation>options object.</documentation>
    </part> 
    <part name="token" 
    type="xsd:string">
    <documentation>the authentication token.</documentation>
    </part></message><message name="
    findAddress1Out"></message>
    <message name="
    findAddress1Out">
    <part name="Result" 
    type="ns12:LocationInfo">
    <documentation>LocationInfo location information object.</documentation>
    </part>
    </message>

    <message> 元素通过 <part> 子元素来描述其逻辑部分。每一个 <part> 元素具有一个名字和类型属性来定义消息 part 的名字及相应的数据类型。为调用函数 findAddress，需要 3 种类型： address、 AddressFinderOptions 和一个名为 token 的字符串数据类型。 在 <portType> 元素中，输入变量的顺序描述为 参数顺序 = address addressFinderOptions token 。 输出数据类型是一个名为 result 的 LocationInfo 对象。

    在 WSDL 文件中 <types> 元素定义用来交换信息的各种数据类型。下面就是作为输入变量用来调用 findAddress 服务的每一种数据类型的描述。

    【IT168 信息化】

    清单 3: 地址查询 Web 服务的 WSDL 文件 -- <types> 元素 示例 1

    <xsd:complexType name="
    Address">
    <xsd:sequence>
    <xsd:element name="houseNumber" nillable="true" type="xsd:string" />
    <xsd:element name="street" nillable="true" type="xsd:string" />
    <xsd:element name="intersection" nillable="true" type="xsd:string" /> 
    <xsd:element name="city" nillable="true" type="xsd:string" />
    <xsd:element name="state_prov" nillable="true" type="xsd:string" /> 
    <xsd:element name="zone" nillable="true" type="xsd:string" />
    <xsd:element name="country" nillable="true" type="xsd:string" />
    </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="
    AddressFinderOptions">
    <xsd:sequence>
    <xsd:element name="dataSource" nillable="true" type="xsd:string" /> 
    </xsd:sequence>
    </xsd:complexType>

    现在，服务请求者能够知道如何来调用服务：一系列具有不同名字的字符串类型包括 Address 对象数据类型和一个描述 datasource 的字符串数据类型。 然而，WSDL 文件，或者说协议并 没有指明哪一个元素是调用服务必须的或可选的变量。 协议既没有说明调用服务有多少数据源，也没有说明有哪种数据源。服务请求者不得不检查 ArcWeb 服务的 Web 站点“关于数据源和信用”来了解 未包含在协议中的可获取数据源。尽管 <enumeration> 数据类型在 Web 服务开发中可以部分地解决数据源的选择问题，但对于服务请求者 WSDL 仍旧不是一个好的解决方案。 

    token 字符串数据类型是干什么的呢？ token 作为输入变量是调用 findAddress 服务必须的。然而，您在地址查询 Web 服务的 WSDL 文件中能够找到的唯一线索就是作为 身份验证令牌的 <message> 元素中的 <documentation>元素。在检查和跟踪 ArcWeb 服务之后， 身份验证 是另一个 Web 服务 -- Authentication Web 服务验证服务请求者是否允许访问 ArcWeb 服务。 这意味这服务请求者必须与另外一个服务提供者签署协议来调用地址查询 Web 服务。

    最终，在调用服务后，服务请求者所获得的输出是一个对象数据类型 -- LocationInfo。 为了找到一个给定地址的位置（经度和纬度），服务请求者必须跟踪如下所述的对象数据类型：

    清单 4: 地址查询 Web 服务的 WSDL 文件 -- <types> 元素示例 2

    <xsd:complexType name="
    LocationInfo">
     <xsd:sequence>
    <xsd:element name="matchType" nillable="true" type="xsd:string" /> 
    <xsd:element name="
    candidates" nillable="true" 
    type=
    "ns12:ArrayOfLocation" /> 
    <xsd:element name="hasMore" type="xsd:boolean" /> 
    <xsd:element name="errorCode" nillable="true" type="xsd:string" /> 
    </xsd:sequence>
    </xsd:complexType>
    
    LocationInfo 中的一个元素是 ArrayOfLocation 数据类型，它包含如下所示的一个 location 数据类型数组。在示例中，只有 Morgantown 包含在输入变量中来调用地址查询 Web 服务，不同国家和地区关于 Morgantown 的 15 个位置将被作为输出变量返回，它们被包含在一个候选位置的数组中以供最终决策。

    清单 5: 地址查询 Web 服务的 WSDL 文件 -- <types> 元素示例 3 

    <xsd:complexType name="
    ArrayOfLocation">
    <xsd:complexContent>
    <xsd:restriction base="soapenc:Array">
    <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType=
    "ns12:
    Location[]" /> 
    </xsd:restriction>
    </xsd:complexContent>
    </xsd:complexType>
      
    location 数据类型包含 point 数据类型来最终提供如下所示的位置信息（经度和纬度）。

    Listing 6: 地址查询 Web 服务的 WSDL 文件 -- <types> 元素示例 4 

    <xsd:complexType name="Location">
    <xsd:sequence>
    <xsd:element name="point" nillable="true" type="ns11:
    Point" /> 
    <xsd:element name="description1" nillable="true" type="xsd:string" /> 
    <xsd:element name="description2" nillable="true" type="xsd:string" /> 
    <xsd:element name="score" type="xsd:double" /> 
    <xsd:element name="matchType" nillable="true" type="xsd:string" /> 
    <xsd:element name="type" nillable="true" type="xsd:string" /> 
    <xsd:element name="locationExtent" nillable="true" type=
    "ns11:Envelope" /> 
    </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="
    Point">
    <xsd:sequence>         
    <xsd:element name="
    x" type="xsd:double" />          
    <xsd:element name="
    y" type="xsd:double" />          
    <xsd:element name="coordinateSystem" nillable="true" type=
    "ns11:CoordinateSystem" /> 
    </xsd:sequence>
    </xsd:complexType>

    图 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# 来实现同样的目的。
 

    清单 7: VB.NET 中 ESRI 的地址查询 Web 服务调用过程

    Dim myAddress As New Address()
    myAddress.houseNumber = "888"
    myAddress.street = "Willey St"
    myAddress.city = "Morgantown"
    myAddress.state_prov = "WV"
    myAddress.zone = "26505"
 
    Dim myAddressFinderOptions As New AddressFinderOptions() 
    myAddressFinderOptions.dataSource = "GDT.Streets.US"
 
    Dim myAuthentication As New Authentication()
    Dim token as Stringtoken = 
    myAuthentication.getToken("[username]","[password]", 5)
    Dim myAddressFinder As New com.esri.arcwebservices.AddressFinder ()
    Dim myLocationInfo As New LocationInfo()
 
    myLocationInfo = 
    myAddressFinder.findAddress(myAddress,myAddressFinderOptions,token)
    
    在这一过程中，一些变量是基本的元素，是必须输入的，而其它一些却是可选的。 例如，除了门牌号和街道名称，Address 对象还有几个可选属性，如 Cross Street，它在上面的代码片段中并没有用到。所有其它属性都是调用过程必须的，但您如何知道黑盒中的这些详细信息呢？考虑到在不久的将来，将有大量的 Web 服务被开发和利用，对于应用程序开发者来说，即使提供对象模型、流程图和描述信息，深入分析和了解这些由不同服务提供者产生的 Web 服务调用规程也将非常困难。

    Web 服务的语义调用主要关注服务请求和响应的标准化，以此来简化编程步骤，使得 Web 服务调用机制可读，容易理解。 整个过程如 清单 8 所示，可以与 清单 7 调用地址查询 Web 服务的代码片段进行对比。

    清单 8: 通过语义请求 ESRI 的地址查询 Web 服务调用过程 

    Dim myService As New com.esri.arc Web services ()
    Dim request as String
    Dim response As String
    request = getRequestXMLDoc()
 
    response = myService.getService(request)
    
    这里，请求和响应都是 XML 文档，它们描述了服务调用规程的细节和步骤，其中包括输入变量和输出结果的要求。首先，服务请求者需要编辑如 清单 9 所示的 XML 文档， 然后产生一个 getRequestXMLDoc 函数，以字符串或指向文档的 URL 的形式来读取这个 XML 文档，它取决于服务提供者的定义。

    一般来说，服务名字就是函数调用的对象名，如 AddressFinder， 它有一个 findAddress函数。然而，语义请求和响应通过在 XML 文档中标准化整个编码流程而公开了开发规程。 在这种情况下，各种各样的 Web 服务可以共享同一个功能接口，如 getService(request)。

    在地址查询 Web 服务示例中，它的服务调用可以以 清单 9 所示的 XML 文档作为输入请求。通过这种方式，面向对象编程中隐藏的信息可以公开给服务请求者。

    清单 9: 调用 ESRI 的地址查询 Web 服务的语义请求

    <?xml version="1.0" encoding="utf-8" standalone="no"?>
    <ServiceRequest>  
    <Service Name="AddressFinder">    
    <Function Name="findAddress">       
    <InputVariables>    
    <address>    
    <houseNumber>888</houseNumber>    
    <street>Willey St</street>    
    <city>Morgantown</city>    
    <state_prov>WV</state_prov>    
    <zone>26505</zone>    
    </address>    
    <datasource>GDT.Streets.US</datasource>    
    <username>[username]</username>    
    <password>[password]</password>       
    </InputVariables>    
    </Function>  
    </Service>
    </ServiceRequest>
 
    通过语义请求和响应隐藏实现细节

    地址查询 Web 服务的输出是一个 LocationInfo 对象，它包含如下信息，如 Number of Candidates、 Match Type 等等以及一个 Location 对象类型的数组，就像前面提到的。为获取位置信息（经度和纬度），Visual Basic .NET 中必须使用如 清单 10 所示突出显示的代码片段。

    清单 10: 在 VB.NET 中通过地址查询 Web 服务获取位置信息 

    Dim myAddress As New Address()
    myAddress.houseNumber = "888"
    myAddress.street = "Willey St"
    myAddress.city = "Morgantown"
    myAddress.state_prov = "WV"
    myAddress.zone = "26505"
 
    Dim myAddressFinderOptions As New AddressFinderOptions() 
    myAddressFinderOptions.dataSource = "GDT.Streets.US"
 
    Dim myAuthentication As New Authentication()
    Dim token as Stringtoken = myAuthentication.getToken("[username]","[password]", 5)
    Dim myAddressFinder As New com.esri.arcwebservices.AddressFinder ()
    Dim myLocationInfo As New LocationInfo()
 
    myLocationInfo = myAddressFinder.findAddress(myAddress,myAddressFinderOptions,token)
 
    Dim loc As New com.esri.arcwebservices.Location()
    loc = locInfo.candidates(0) 'just retrieve the first record
    Dim strLocation As String
    strLocation = loc.description1 + " is located at: " + 
    " Longitude: " + loc.point.x + ", Latitude: " + loc.point.y
 
    同样，隐藏信息通过如 清单 11 所示的语义响应而清楚地公开出来。例如 WSDL 文件中 <description1> 元素的意义可以通过从服务请求者获取的语义响应中的 <LocationDescription> 元素来清楚地说明。

    清单 11: 调用 ESRI 的地址请求 Web 服务之后的语义响应
    
    <?xml version="1.0" encoding="utf-8" standalone="no"?>
    <ServiceResponse>  
    <Service Name="AddressFinder">    
    <Function Name="findAddress">       
    <InputVariables>    
    <address>    
    <houseNumber>888</houseNumber>    
    <street>Willey St</street>    
    <city>Morgantown</city>    
    <state_prov>WV</state_prov>    
    <zone>26505</zone>    
    </address>    
    <datasource>GDT.Streets.US</datasource>    
    <username>[username]</username>    
    <password>[password]</password>       
    </InputVariables>    
   
    <OutputResult>        
    <NumberOfCandidates>1</NumberOfCandidates>
    <Location>             
    <LocationDescription>888 Willey 
    St, Morgantown, WV 26505</LocationDescription>
    <longitude>-79.946623</longitude>             
    <latitude>39.635351 </latitude>        
    </location>   
    </OutputResult>
   
    </Function>  
    </Service>
    </ServiceResponse>
   
    其中，最重要的是，语义请求和响应可以隐式调用 Web 服务的实现细节，如清单 10 和 11 所示。 传统调用方式如 清单 10 所示，服务请求者不得不通过传递必须的变量（用户名、密码、有效时间）来调用另外一个名为 Authentication 的服务，以此获得一个令牌来作为获得访问 ArcWeb 服务的身份确认。为获取位置信息（经度和纬度），服务请求者必须首先通过调用地址查找 Web 服务以获取一个 LocationInfo 对象，然后产生一个 location 对象来从候选的 LocationInfo 对象中获取经度和纬度的值。通过语义响应，如 清单 11 所示，服务请求者可以忽略这些实现细节使得实现更加紧凑高效。

    Web 服务的一个主要弱点就是 Web 服务不够稳定和健壮，因为如果服务提供者改变了面向服务编程中的架构设计，服务请求者不得不也作出相应的改变以升级服务的调用，否则，提供的服务将不会工作。对于地址请求 Web 服务应用程序来说，当服务提供者将服务从版本 1 升级到版本 2 时，你将不得不作出改变，如 表 1 所示：

    表 1: 参数变动
 

    标准化语义 Web 服务

    Web 服务的调用可以标准化为如 清单 12 所示的格式：

    清单 12: Web 服务标准化调用

    Dim myService As New com.esri.arcwebservices ()
    Dim request as String
    Dim response As String
 
    Dim description as String
    description = myService.getServiceDescription()
    request = getRequestXMLDoc()
    response = myService.getService(request)

    服务提供者需要提供两个基本接口 getService 和 getServiceDescription。 getServiceDescription 提供一个 XML 文档，它包含调用函数 getService 的 所有必要的信息和函数。通过服务请求和响应模板文档的 XML 模式，所有隐藏的信息必须在 getServiceDescription 中公开，例如关于输入输出变量是必须还是可选的等等。

    对于示例中的地址请求 Web 服务，可通过请求 getServiceDescription 函数来获取 XML 文档，它包括语义请求和响应模板。模板如 清单 13 (sidefile) 所示。

    清单 13 中的模板是自我描述的。为调用地址请求 Web 服务，请求者需要编辑一个 XML 文档，它包含模板中 <description> 描述的必要的元素，如：

    ·XML 声明 
    ·服务请求 
    ·指定名称的服务 
    ·指定名称的函数 

    元素中描述的输入变量的集合 服务请求模板定义了哪个输入变量是可选的，数据源可使用哪个选项等等。 

    模板同样告诉服务请求者，为了利用函数调用 response = myService.getService(request)（详细信息参考 清单 13 ）发送请求到 Web 服务，请求输入的字符串数据类型的可接收内容应该是一个指向服务请求模板的 XML 文档的 URL。这样请求者不得不将 XML 模板保存为 Web 服务器目录上的 XML 文档。URL 可以通过调用 request = getRequestXMLDoc() 来获得（详细信息请参考 清单 13 ）。

    在服务请求者发送请求来调用服务之前，基于服务提供者提供的模式，服务请求的 XML 模板可以通过函数 getRequestXMLDoc 来校验。 如果服务请求者不能够通过校验过程，服务请求者就会知道服务请求者升级了所提供的服务。在这种情况下，服务请求者只需要检查服务描述的 XML 文档模板来查看调用服务有哪些新的需求。

    例如，ArcWeb 服务对于尚不具备数据源的服务增加了数据源参数。数据源在 表 2 列出的所有请求中都是必须的：

    表 2: 包含数据源对象数据类型的 ArcWeb 服务
 

    服务请求者需要在服务请求的 XML 模板中插入新的节点，而不是改变清单 7 和 10 中的代码片段。 尽管面向对象的技术可以仍旧在开发 Web 服务中继续使用，但语义请求和响应在服务提供和服务请求之间将优先考虑。语义调用将明确规范和简化 Web 服务的开发和利用，通过这种方式，服务请求者和服务提供者之间的协议内容将更加具体和明确。

    由于 Web 服务通过语义请求和响应进行标准化，WSDL 和 UDDI 的角色需要重新认定，可以被 XML 模板描述的内容包括：

    ·内容 
    ·输入输出变量的定义和意义 
    ·函数性能 
    ·怎样利用语义请求和响应来调用 Web 服务 

    这意味着所有 WSDL 文件可以拥有同样语法和内容，除了 Web 服务的名称和位置。在这种情况下，WSDL 将只是作为服务请求者区分和调用 Web 服务的接口而没有任何其它意义，因为所有的 Web 服务将拥有同样的 2 个功能接口：getServiceDescription:string 和 getService(request:string):string 。

    结束语

    WSDL 自身不能够明确地描述 Web 服务的内容和意义。对于服务请求者，通过跟踪对象图或其它辅助资料来找出服务实现细节、隐藏的服务以及多个服务共享的通用对象类型将很困难。如何让服务请求者以简单、稳定和有效的方式使用 Web 服务是服务提供者主要关注点和任务。通过本研究已经表明，Web 服务，包括地理空间 Web 服务能够通过语义请求和响应的方法进行标准化，它可以公开 WSDL 以及相关 Web 服务中所有隐藏的和必须的信息，同时对 Web 服务请求者隐藏实现细节。这种新方法与传统 Web 服务实现间的主要区别如 图 2 所示，新方法在服务请求者和服务提供者之间交换的是 XML 文档而不是数据和函数。

    图 2: WSDL 中取代数据和服务交换的 XML 文档交换
 

    Web 服务请求和响应的语义模板将在服务提供者和请求者之间建立一个明确的协议。服务描述的语义模板对分布式计算系统智能化集成以实现自动匹配和 Web 服务功能链接具有至关重要的地位。 因此，数据和函数的意义以及服务请求变得明确地机器可读和可理解。人工智能指的是计算机可以模仿人的行为。为调用 Web 服务， 图 1 以红色虚线所示的人的行为表示计算机在仿真人的行为方面还存在障碍，因为计算机只能够通过 WSDL 来理解 Web 服务，而不能够在 WSDL 之外自动查找实现信息。然而，如果 Web 服务调用只需要交换 XML 文档，而且 XML 文档中明确包含了所有必需的信息和指令，那么对于计算机来说自动实现操作而不需要人工干预也是可能的。这种研究方法同样区别于目前基于本体的（ontology-based）语义 Web 服务研究，基于本体的语义 Web 服务研究仍然研究对象和函数的交换，而不是数据和服务描述内容和意义的 XML 文档，例如 complexType ( WSDL schema 的集合元素) 在基于本体的定义中被建模为带有属性的类－—子类继承关系，如图1所示。在 XML 文档的交换中，这种继承关系是不必要的，也是可以忽略的，因为服务请求者只想知道 x，y 的值而不是服务器端的实现细节。

    地理空间 Web 服务的开发者和客户面临着如何描述新一代地理空间 Web 服务的新难题，这些 Web 服务用来映射、地理处理和集成。例如构建交互式地图服务，根据这种服务，对于地图上特定的地理空间特征， 服务请求者可以定义图标和标记类型，在这个例子中，语法和内容如何实现相互理解主要依赖 GIS 领域新的规范和标准的产生。 在这种条件下，面向对象技术将不再是一个有效的方法，例如，为州际公路产生一个屏蔽标签，在 Vb.NET 中利用 ArcObjects 将产生超过 60 行的代码。但是，如果这个屏蔽标签可以明确定义，那么在服务请求的 XML 模板中只需要 1 行文本元素。 这种能力已经通过空间引用系统（SRS）的标准和规范得到验证。许多开放式 GIS 团体 (OGC) Web 地图服务 (WMS) 服务器利用预先定义的 欧洲石油测量集团 (EPSG) 项目， 如 EPSG:4326 引用 WGS84 (世界地测数据)， EPSG:26917 引用 NAD83 / UTM zone 17N 以及 EPSG:26717 引用 NAD27 / UTM zone 17N等等。符号和标签的标准化将遵循 EPGS 同样的机制，并将成为未来最重大的难点。OGC 已期望在这一领域以新的起点开始工作。下一个重大挑战是将服务模板规范化为 XML 文档，在通用领域以自我描述的数据和服务语义来构建新一代的 Web 服务。