地理信息集成互操作平台及其QoS.doc

地理信息集成互操作平台及其QoS* 本文得到国家重点基础研究发展规划973项目(2006CB701306)和国家自然科学基金项目(40730527)资助。汪小林，男，博士，副教授，主要研究方向为地理信息系统及系统虚拟化。罗英伟，男，博士，教授，主要研究方向为地理信息系统及系统虚拟化，。汪小林 罗英伟（北京大学计算机科学技术系，北京，100871）摘要：Web Services是一项基于标准的软件技术，它以面向服务的开发、部署和集成为基本的出发点，已经成为Internet上分布式计算和服务环境下主要的发布形式和组织框架。目前，在大型空间信息的分布式应用中，由于GIS用户长久以来对各类GIS厂商的数据格式和平台的较大的依赖性，跨平台空间信息交互的困难性和系统开发的重复性、复杂性十分明显。本文主要结合当前Web Service的基础框架以及实现Web Service的事实标准，给出了在地理信息应用领域中用于解决平台异构和在线服务等重要问题的互操作平台的基本设计和实现。该平台主要致力于实现屏蔽空间数据源和数据服务的异构性，以GML为统一的空间数据传输和交换格式，完成透明的基于元数据的空间信息获取和处理。另外，本文还着重就空间数据缓存、GML数据压缩、地图在线生成控制等方面对平台的Web GIS的QoS进行了讨论。关键字：Web Service；空间信息集成；互操作；QoS Geospatial Information Integration and Interoperation Platform and Its QoSWANG Xiaolin, LUO Yingwei and XU Zhuoqun(Dept. of Computer Science and Technology, Peking University, Beijing, 100871)Abstract: Web Service is a standard-based software technology. It sets service-oriented development, deployment and integration as its basic jumping-off place, and has become the primary publishing mechanism and organization framework in the environment of distributed computing and services among Internet. Currently, especially in distributed applications of large scaled spatial information, due to users strong dependence on data formats and platforms of certain GIS manufacturer, there are obvious difficulty and complexity in inter-platform spatial information exchange and system development. This paper initializes the idea from the basic concept of Web Service with regard to the concurrent framework as well as the factual standards for its implementation, and then presents the concrete design and implementation of an integration and interoperation platform that aims to solve heterogeneity and on-line service for geographical information. This platform concentrates on implementation to shield heterogeneity among spatial data sources and services, and to accomplish metadata-based transparent spatial data access and process through a common spatial data transmission and exchange format-GML. In addition, this paper also details on QoS to WebGIS Services from aspects of cache mechanism, GML data compression, map on-line generation, etc.Key Words: Web Service, Spatial Information Integration, Interoperation, Quality of Service1 引言Web Services是一项基于标准的软件技术，它使得编程人员和集成人员能够在一个公司范围内，或者是在许多公司之间通过Internet按照全新的方式将已有的系统和新的系统绑定起来。Web Services允许由不同的供应商提供的、或者运行在不同的操作系统和平台上的以不同编程语言书写的软件间存在互操作性1。Web Service的关键特性在于它基于工业标准，强调互操作性，并实现跨平台、跨支撑语言快速配置（Deploy）。Web Service以面向服务的开发、部署和集成为基本的出发点，它所基于的基础框架“面向服务的体系结构”（Service-Oriented Architectures）也着重于对已有的业务流程的继承和重组，提供尽量便捷的系统功能和业务流程的转换能力，避免大范围的代码重写。为了实现这一点，遗产系统（Legacy Systems）的企业安全、系统平台、可重用组件等成为基于Web Service的体系结构需要特别关注的问题。在地理信息领域，当前的发展现状是：各主要的GIS平台（例如Arc/Info、MapInfo）以及一些数据库厂商（如Oracle）提供了基于自身空间数据模型的数据、服务以及产品系列，而长期以来拥有各自背景的应用分别搭建在这些不同的平台之上。由于地理信息数据的数据量较大，数据积累周期较长，因而很难做到平台间的数据迁移。但是目前随着数字地球、数字城市等大规模空间规划对跨领域的地理数据的强烈需求，地理信息集成已经成为急待解决的问题。已有的一些解决方案侧重于为参与应用集成的各个平台编写应用相关的适配软件，从而屏蔽平台的异构性，形成基于应用本身的集成。但是由于应用流程的多样性和处理的复杂性，应用的每次变更都将造成相关软件的重复开发。因而依靠这些为参与集成的各个平台编写的适配软件来完成系统集成，不仅为开发和维护带来困难，而且难以利用遗产系统的已有模块。在有些情况下开发人员在一定程度上还受限于相关企业的数据和服务安全约束。Web Service专注于对遗产系统的快速整合和部署，所以建立基于Web Service的地理信息互操作平台不仅可以有效利用遗产系统，而且通过服务进行功能发布能够将系统实现和功能界面较好的分离开来。后者允许在保持参与集成的服务接口一致的前提下灵活地进行实现上的功能替换，并且由于接口和实现分离，部分企业内部的重要数据和相关的服务的安全性也可以得到保证。本文将重点论述如何在地理信息集成方面应用Web Service技术。2 地理信息集成互操作平台建设2.1 地理信息集成互操作平台模型依据Web Service的技术标准和实现规范，我们设计并实现了如图1所示的地理信息集成互操作平台2。该平台的设计目标是提供以图层为基本地理数据组织单位的服务集成，完成从多个不同平台的GIS数据源中获取数据，进行地图数据的在线叠加、分析、显示以及用户交互。平台所采取的设计方法是：以服务为基本组织，以SOAP（Simple Object Access Protocol）为基本的Web Service通讯协议实现互操作平台的业务流程调度，对外提供独立于企业应用的API工具集，即为基于本平台的二次开发提供透明的地理信息服务接口。图1 地理信息集成互操作平台该地理信息集成互操作平台包括四类基本服务：（1）AIS（Application Integration Service），即应用集成服务，它是实现互操作平台的业务流程调度的核心服务，主要功能包括： 建立与客户端的连接，并能够解析用户请求，进行任务分解； 能够与可用的元数据服务进行交互，获取业务流程所需的数据描述和服务描述； 启动数据请求线程，完成和地图数据转换服务TS（Transform Service）的交互，以GML（Geography Markup Language）为统一的地理数据格式获取图层数据； 启动数据处理线程，完成基于GML数据的坐标转换、空间分析等信息处理； 完成地图的多个图层数据的协调整理，在考虑客户端QoS服务特征的前提下，以各种有效的途径（完全的矢量数据、剪裁的矢量数据、点阵数据）响应客户端请求； 向基于互操作平台的二次开发用户提供开发工具集PAIToolkits。该工具集提供一系列空间信息及服务的API函数包和Web Service。这些API和Web Service借助元数据服务提供的元数据，有效地调度和集成不同的元数据服务、地图数据转换服务、空间分析服务以完成指定的功能，并屏蔽信息和服务的异构性、分布性和语义冲突，使开发人员不必关心异构、分布性和语义冲突，实现空间数据互操作、软件互操作和语义互操作。（2）MDS（MetaData Service），即元数据服务，它在协助AIS完成整个业务流程以及在实现TS的自动注册方面具有非常重要的意义。MDS内部维持了整个平台的Web Service的服务信息，并通过WSDL描述了外部可用的查询接口从而在业务流程中实现服务的动态发现和绑定。MDS自身是分布的，这样就提高了平台的可用性和可伸缩性；（3）TS（Transform Service），即地图数据转换服务，它可以嵌入各个GIS服务提供商的平台，完成从各种GIS平台提取图层数据并转换为统一的GML（Geography Markup Language）数据格式的功能。GML是XML在地理信息领域的行业标准，它采用XML格式表达通用的空间对象，目前已经成为GIS平台间进行数据交换的通用协议。TS必须在MDS完成注册才能够成为互操作平台的有效服务节点。TS自身可以维护一定的数据保密性，可以对生成的可发布的GML做一定程度上的过滤，这有利于保证互操作平台在Internet上的安全性。（4）SAS（Spatial Analysis Service），即空间分析服务，它能够接受GML空间数据，提供基于GML数据本身的空间数据剪裁、投影、坐标转换、叠加分析等常用的空间分析能力。考虑到被处理的数据量可能较大，SAS可借用TS的数据转换能力，依托一些比较成熟的GIS平台的空间分析模块协助进行数据处理。以上两种策略都最终形成经过分析处理的GML目标数据。如图1所示，对于一个地图请求而言，该地图是由异构GIS平台存储的多个图层叠加而成的，比较典型的服务流程是：Web服务器获得Web客户端的地图数据请求，调用PAIToolkits中的相应API启动AIS，由后者完成如下的Web Service服务流程：l 请求MDS获取当前请求中所涉及的图层数据和图层服务的元数据信息。MDS通过它所维护的后端数据源查询得到上述信息并返回给AIS；l AIS根据图层服务的元数据信息定位TS，并将如上得到的图层元数据作为参数并发请求多个TS的数据转换服务，并最终收集得到的以GML格式表达的图层数据；l AIS根据客户端的客户服务特征和当前的网络性能考虑QoS（有关QoS的详细说明在第3节中），对得到的GML数据进行适当的剪裁处理或在线生成点阵图，将结果返回给Web客户端。2.2 Web Service开发工具的选择我们采用Web Service的标准通信协议SOAP作为互操作平台中各个服务之间信息交换的主要方式。在互操作平台的Web Service的通信实现中，我们选择了基于Java的Web Service的工具集AXIS（Apache eXtensible Interaction System）作为SOAP的基本框架，它是Apache SOAP的后继者，具有和平台应用相关的诸多优点 3：l AXIS完全支持SOAP 1.1，并支持带附件的SOAP（SOAP with Attachments），这使得使用GML格式进行表达的大量的图层数据能够以一种比较便捷的方式进行封装、打包、拆包和解析，而不是完全就所有的矢量信息填充进SOAP协议本身。这一点大大提高了SOAP请求以及响应在平台中流动时的效率，降低了协议解析负载；l AXIS拥有模块化的结构，相对Apache SOAP结构更加合理清晰。它可以运行在任何Servlet Engine上，本身也自带了一个功能相对较弱的服务器。这使得平台集成的遗产系统在选择适当的服务器进行Web Service发布时，有比较大的回旋余地；l AXIS有完善的WSDL支持，包括Java2WSDL、WSDL2Java工具以及自动生成WSDL的能力。这使得平台的开发可以完全关注于各个集成系统的业务接口的发布本身，脱离了使用Web Service所必须考虑的一些通用的技术细节，无论从业务设计还是开发本身都提高了效率；l AXIS有较好的数据类型支持，除了标准的可串行化数据类型外，可串行化的Java对象以及注册了的Java Beans都可以被应用到SOAP消息中。这对于在地理信息领域拥有较多复杂的对象类型的情形尤为适合，它保证了平台内SOAP消息的语法上的可行性和语义上的直观性的良好结合，使得平台发布的接口和参数更易于理解。由此可以看出，采用AXIS，不仅能够完全继承SOAP的基本特性和模块支持，而且能够使各个服务的业务功能与信息发布分离，这非常有利于服务的动态扩展和更新，并有利于整个平台对服务的协调和管理。2.3 平台实现以TS的实现为例2.3.1 TS服务结构TS主要提供对4类GIS数据源的GML数据转换能力：ArcInfo的SHP文件、MapInfo的Tab文件、存储在Oracle spatial的空间数据库中的空间数据以及我们自主开发的Geo-Union平台中存储的空间数据。通过对已有的或者新开发的数据转换模块（包括DLL组件、C的可执行文件和Java包）的Web Service封装，TS对外提供统一的转换接口。在平台内部，TS主要和AIS进行服务交互，完成AIS对数据转换的服务调度。互操作平台中TS服务结构如图2所示。图2 互操作平台TS服务结构2.3.2 TS服务实现TS的主要实现体现在：（1）实现了对应于不同空间数据存储类型的转换器：地图数据存储格式转换器Oracle Spatial数据库存储Oracle2GMLerGeo-Union数据库存储GeoUnion2GMLerArcInfo文件存储ArcInfo2GMLerMapInfo文件存储MapInfo2GMLer（2）使用Apache组织的“Tomcat + AXIS”实现Web Service。TS和AIS之间通过SOAP协议进行通信：消息类型传递方向消息参数请求AISTS图层名称，存储格式，其他必要参数（包括数据库连接参数信息等）响应TSAIS对应图层数据（GML格式）2.3.3 TS服务接口的WSDL描述TS实现中的多个转换器通过WSDL（Web Service Description Language）发布其外部可用的接口。下面的WSDL片断给出了对应于上文表格中Oracle2GMLer转换器的接口描述：（1）Oracle2GMLer转换器的请求和响应消息描述 /wsdl:message（2）Oracle2GMLer转换器接口的端口类型描述 （3）Oracle2GMLer转换器接口的端口绑定描述 最后，TS需要将自身发布的多个接口与一个HTTP地址进行绑定，这样，客户端就可以方便地通过该绑定调用相应的转换接口，完成多源GIS数据格式的GML统一转换了： 3 互操作平台中的QoS3.1 Web Service的QoS2QoS问题在各类分布式应用中已经得到越来越广泛的关注，Web Service作为应用较为广泛的一类分布式服务提供机制，在QoS方面的优劣成为评价服务提供商成功与否的一个重要的因素。QoS决定了服务的可用性和效率，这两者都在很大程度上影响了服务的受欢迎程度。由于Internet所带来的网络连接的动态性和不可预知性，QoS的实现面临较大的挑战。因而，从分析Web Service的需求入手，建立支持QoS的Web Service，综合考虑影响QoS的瓶颈，提供相应的QoS方法和事务服务成为构建基于Web Service的QoS模型的一个主要流程。3.1.1 QoS的需求在Web Service上支持QoS的主要需求有：l 可用性（Availability），它给出了一个服务能够被使用的概率，较大的可用性数值说明服务总是处于就绪状态，而小的数值说明了服务在一个特定时间内的可用性不可预计。和可用性相关的还有修复时间（TTR，time-to-repair）的概念，它说明了用于恢复一个失败的服务所需要的时间。l 可访问性（Accessibility），它反映了能够为一个Web Service请求服务的程度，即一个成功的服务实例在某点上的成功概率。要想获得很高的可访问性，必须建立具有较高可伸缩性（Scalability）的系统。可伸缩性反映了能够持续的为请求服务的能力，不论请求在某段时间的容量有多大。l 集成性（Integrity），它反映了Web Service能够正确的针对资源进行交互的能力。事务（transactions）能够保证对资源进行正确交互。事务是一组作为一个工作单元的行动序列，只有所有的行动都正确执行了才能保证事务正确，否则已做的事务必须回滚。l 性能（Performance），它通过对Web Service的吞吐量和延迟的描述得以体现。吞吐量反映了在一个固定时间内所能够处理的Web Service请求的数目。延迟则给出了从一个Web Service请求发出到收到回复所经历的时间。高的吞吐量和低的延迟是高性能的体现。l 可靠性（Reliability），它反映了维护服务和服务质量的能力大小。一个月或者一年内服务失败的次数能够对服务的可靠性有所反映，另一方面，它也指一个经过确认的消息序列能够被正确的接收和发送。l 规则性（Regulatory），它反映了Web Service与规则、制度以及标准协同的能力。保持与标准同步对于请求方正确的激活服务非常重要。l 安全性（Security），它作为QoS的一个方面维持了Web Service能够在公共的Internet上得到应用。3.1.2 建立支持QoS的Web Service建立支持QoS的Web Service，首先需要一个单独的QoS语言来回答诸如“未来的延迟是多大”、“可接受的响应时间是多少”等问题，以弥补WSDL对语义信息表述的缺陷；其次，需要定义用户和Web Service服务进行交互的整个流程中的QoS协商机制，这包括在请求中包含QoS，使用QoS Broker在UDDI（Universal Description Discovery and Integration）中查找服务提供商，以及在所提供的QoS和请求的QoS间建立一个协商后的QoS用于以后的交互。3.1.3 影响Web Service的瓶颈Web Service的服务性能所遭遇的瓶颈主要在于底层消息传送协议的限制。Web Service广泛依赖于HTTP、SOAP等协议使得我们必须处理它们所带来的负担。HTTP的主要问题在于它不确保包一定被送往目的地以及包的传送顺序，SOAP的问题则主要来自于自身的XML格式表达和解析机制。虽然SOAP使用易懂的文本，但是XML本身无法对数据进行优化，使用XML Parser进行解析自身也很耗时。目前可以考虑使用异步消息队列或者私有的局域网来代替HTTP通信，并且选用合适的XML解析器（如能提高吞吐量的基于SAX的解析器）解析SOAP协议，SOAP文本自身在传输中也要考虑压缩。3.1.4 提供QoS的方法服务提供商提供QoS的途径很多，主要体现在以下几个方面：l 缓存机制和负载平衡，这两方面不仅可以在Web Server层面上提供，也可以在Web Application Server层面上提供；l 服务提供商可以进行性能建模（Capacity Modeling）来为请求通信量、当前性能使用情况以及结果QoS建立一个自顶向下的模型；l 服务提供商可以根据通信量的容量、不同的应用服务类型的通信量以及来自不同资源的通信量来为Web Service的通信量分类，为一系列的服务命令和未来具有负载平衡能力的Web Application Server和Web Server的性能进行规划；l 服务提供商可以提供“差别服务（Differentiated Servicing）”。即通过性能模型来决定不同的客户和服务类型所需要的性能，从而保证不同的应用和客户可以获得恰当的QoS层次。一个典型的例子是，一个多媒体Web Service需要较好的吞吐量，而一个银行Web Service需要安全性保证和事务QoS；l 对于维护Web Service的集成性相对重要的业务流程使用事务QoS，并应用典型的分布式环境下的两阶段协议或要求相对宽松的事务补偿机制支持事务的ACID（Atomic, Consistent, Isolated and Durable）特性。3.2 互操作平台中的QoS控制由于地理信息数据自身具有分布性和海量性等特点，并且经常涉及多个数据和服务提供商，在基于Web Service的地理信息集成互操作平台内部有效地体现出QoS也是平台建设的主要组成部分之一，是影响平台可用性的重要方面。下面就图1描述的平台流程中涉及的QoS问题做进一步的讨论。在地理信息集成互操作平台中提供QoS的必要性体现在： 地理数据在Internet上进行应用最大的服务瓶颈来源于数据的传输。众所周知，地理数据即使在普通的公众应用中也是很大的，一个图层往往包括几千到几万个几何实体；另外，如同在第一节中所提到的那样，以XML为基本语法的GML虽然具有数据格式上的同一性从而使得数据处理统一，但由于GML格式上的繁冗使得GML的数据传输量更是大大增加，所以必须进行有效的处理减少因为数据传输带来的效率上的下降； 客户端的请求往往带有用户的特征需求。由于用户终端所处的网段以及用户类型带来的用户使用地图习惯上的差异，客户端获取地图数据的形式成了满足客户端应用需求的重要环节。最明显的例子体现在，是选择在客户端维持GML矢量数据处理模块而由AIS提供完全的矢量数据，还是在AIS预先完成地图数据的绘制而在客户端只保留显示功能，这在不同的用户环境下都会形成效率上的显著差别。在地理信息集成互操作平台中，基于QoS的实现策略主要体现在以下3个方面：3.2.1 GML数据压缩实现GML数据压缩是减少各个Web Service之间地理数据传输量的最为直接也是比较简单的手段。这一点侧重于解决Web Service需求中的性能问题，也是化解SOAP协议带来的瓶颈的主要手段之一。GML数据压缩在互操作环境中具有层次概念：l 在TS的GML生成过程中立即完成GML数据的压缩。这在图层数据本身变动不频繁，数据量又相对较大的情况下是可行的。而对于数据更新比较频繁的图层则不宜过早的完成压缩，否则由于数据版本更新带来的GML数据重复压缩代价将变为新的瓶颈；l 在AIS缓存中维护TS生成数据的压缩版本。由于AIS有相应的缓存版本控制机制（在3.2.2节中进行说明），这个策略通常是可行的。不过如果需要频繁地在AIS完成地图的动态生成则不宜只保留压缩版本的GML数据缓存，道理和上面大致相同，这时AIS需要经常的解压缩GML数据以完成数据解析；l 在向客户端提供GML数据时实时的完成GML数据压缩，相当于只在客户端和AIS之间的数据传输过程中进行GML数据压缩。这在AIS维护的地图缓存版本比较稳定且用户对地图数据的请求并不频繁的情况下有较高的效率，否则则不能保证由于数据压缩带来的效率上的提高。3.2.2 缓存机制缓存机制是提供QoS的重要途径。互操作平台能够依照客户端用户的地图使用习惯、地图应用精度以及当前的网络速度完成在线的GML数据的剪裁，通过与地图缓存管理的配合增加GIS服务的QoS。这是为了在Web Application Server层面上提供QoS所作的考虑。和数据压缩类似，缓存的建立也是具有层次性的，它不仅体现在整个互操作平台的架构上，还体现在地理数据模型的粒度上。从平台架构上讲：l 为了避免TS对重用性较高的图层数据做反复的转换从而消耗过多的计算和IO资源，在TS上维护对数据版本相对稳定的图层数据的缓存就可以获得很大的效率收益；l 在AIS建立缓存是实现数据集成的关键。在平台处于应用繁忙之中时，AIS将无法承受大量开启的接收转换数据流的线程，因此，建立面向应用、具有快速存取能力的缓存结构就使得整个互操作平台具有真正意义上的可用性。AIS的存储框架目前基于GML图层数据文件进行组织，使用地图名命名的目录方式组织下属的物理图层，对图层加上必要的版本和时间戳，保证QoS允许范围内的数据正确性；l 目前，客户端浏览器使用IE自带的Internet缓存目录进行数据在线缓存，如果需要更高性能、更精致的数据缓存，可以考虑在网页中有效地对网页Session进行维护，有针对性地实现客户端地图浏览时的地理数据处理。从地理数据模型的粒度上讲，缓存可以基于地图、图层、实体三个层次进行维护。目前平台采用的基于物理上独立的图层进行维护，这样做具有以下优点：l 相对基于概念的地图组织而言，图层独立于具体的应用，便于多个应用共享相同的图层缓存，从而避免大量的缓存数据冗余，以及因此造成的数据版本上的不一致，这就提高了缓存空间的使用效率；l 相对更细粒度的基于实体的缓存组织而言，由于GML文件更适合于对图层的完整映射，对图层的完整缓存避免了大量拆分几何实体带来的数据缓存的建立、修改和删除上的耗时操作，并且将基于实体的查询留给经GML解析器后的应用逻辑来完成，要比对大量零散的单实体GML文件作解析更加高效。使用缓存面临的主要挑战在于，对数据更新有较高的频度和实时性要求的应用，如何实现较好的适应性。处理该问题的关键在于在AIS建立数据更新控制的协调器，并和缓存管理器合作完成图层版本的完整、高效更新。目前，在互操作平台上实现高效的数据更新正在设计和实现中。3.2.3 其他和QoS相关的差别服务在互操作平台内部，提供基于用户身份和当前性能需求的差别服务也是进行QoS控制的策略之一。系统主要提供以下两类差别服务：（1）地图转换和数据集成服务 基于GML数据格式的地图裁减：互操作平台能够依照客户端用户的地图使用习惯、地图应用精度以及当前的网络速度完成在线的GML数据的剪裁，并通过与地图缓存管理的配合提高GIS服务的QoS。 在线地图生成服务：互操作平台不仅提供基于GML数据的数据发送，也支持瘦客户端的点阵图在线生成和发送。地图缓存服务也为点阵图的版本控制和更新提供支持。地图剪裁和在线地图生成服务一般配合使用，对网速慢、地图刷新较少和实时性要求不高的客户端提供基于屏幕的剪裁点阵图，而对网速较快、地图刷新频繁和有很高实时传送要求的客户端提供高效的大容量矢量数据在线绘制能力。（2）元数据服务元数据服务是互操作平台实现集成的重要组成部分，它记录了所有加入互操作平台框架的转换服务以及相应的平台的数据源信息，并实现了对简单的空间元数据的RDF语义建模，能够根据用户的请求进行查询分解，动态完成信息的在线调度和返回。所有的元数据查询均以Web Service的形式发布。 地图元数据描述：互操作平台提供了基本的对地图的元数据描述信息，它能够比较灵活的刻画地图的成员图层、存放位置、访问方式，并根据地图的领域组织了相关的辅助图层信息（例如，对相似的图层名给定了映射方式）。它是元数据服务的基础，是实现其他元数据信息的框架。 地图转换服务元数据描述：根据地图的每个图层的存放位置，互操作平台提供了完成该图层转换的相应服务的元数据描述，包括服务端口，服务接口，服务参数信息以及服务权限。这些元数据能够辅助完成地图的在线生成功能。相应的，互操作平台提供了完成对相应图层刷新的服务的元数据描述，内容和前面类似。 基于应用的空间元数据的语义建模和查询处理：为了处理应用领域的给空间信息带来的语义重叠问题，也为了处理用户端更为复杂和灵活的GIS查询业务，互操作平台依据W3C的Ontology规格，以RDF为基本的语义框架，给出了简单的空间元数据的语义建模，并提供了方便的基于语义的查询功能。元数据服务也记录了QoS的级别信息，能够根据当前的客户和网络情况调整元数据服务的质量，为特定的用户选择合适的地图来源、转换服务以及进行语义交换的内容。4 结论本文