英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料

提高GIS Web服务性能的设计策略

摘要

地理信息系统是无处不在的分布式系统，因为地理空间信息几乎无所不在。考虑到GIS的特点，以下四个设计决策问题尤为关键：事务模式（同步与异步）、服务粒度（细粒度与粗粒度）、交付方式（块与流）和传输格式（GML与二进制）。在本文中，我们分享了在这四个维度上做出选择的经验。

关键词：网络服务、地理信息系统、性能、互联网地图服务、SOAP。

1.介绍

由一个企业管理和拥有系统和应用程序的传统IT基础设施正在让位于由许多业务伙伴拥有和管理的应用程序网络。作为开发利用互联网基础设施的应用程序的平台，Web服务已经获得了强劲的发展势头。在Web服务中，我们指的是独立的、支持Web的应用程序，它不仅能够独立地执行业务活动，而且能够利用其他Web服务来完成更高阶的业务交易。从技术上讲，Web服务是指基于三种规范的Web应用程序，即SOAP（简单对象访问协议）、WSDL（Web服务定义语言）和UDDI（通用描述、发现和集成标准）。这些努力是至关重要的，因为面向服务的计算本质上需要广泛的接受。然而，标准本身并不提供工作系统。构建成功的工作系统需要智能的设计。

本文考虑了并发请求量大、计算复杂、数据传输量大的重型Web服务的设计策略。其中一个突出的例子是连接到地理信息系统（GIS）后端服务器的Web服务。地理信息系统服务至少有三个特点，使其难以以令人满意的性能设计地理信息系统Web服务。首先，由于底层计算几何中涉及复杂的计算，GIS提供的服务通常需要大量的CPU使用。第二，地理信息系统服务经常传输大量的结果数据集，如图像。第三，GIS Web服务的“客户端”通常是一些复杂的软件工具，如CAD桌面应用程序。对于可扩展的GIS，仅仅在组件之间建立通信是不够的。在GIS Web服务系统的设计中，性能始终是一个中心考虑因素。

本文通过建立一个4维的决策框架来突出GIS Web服务系统的关键设计决策问题。四个维度是事务模式、服务粒度、交付方式和传输格式。我们希望本文能够得到Web服务设计者的足够关注，以注意设计原则并构建有效的解决方案。

2.相关研究

万维网联盟（W3C）成功地将SOAP从XML中基于HTTP的RPC机制发展为具有可替换绑定的领先互操作技术。Web服务技术是软件行业的一个实用工程成果。WebServices系统的设计受到了业界[1、2、5]和学术界[3、10、11]的关注。

随着Web服务技术的发展，开放式地理信息系统联盟（OGC）一直在追求具有地图服务器和客户机互操作性的Web地图服务。2000年发布了第一个简单Web地图服务规范。当前的Web映射服务标准包括Web映射服务（WMS）和Web功能服务实现规范（WFS）[6]。由于OGC的WMS是在SOAP出现之前正式化的，所以WMS和WFS并不涉及SOAP。

3.背景

本文中报告的大部分工作是基于美国陆军工程兵团新奥尔良地区（USACE——新奥尔良）的需求。该地区计划、设计、建造、运营和维护联邦资助的中南部和路易斯安那州沿海的航行、防洪、飓风保护和水资源开发项目。在美国陆军工程兵团新奥尔良，工程师和分析师一直在使用大量不同的商业软件包来管理他们的地理信息系统和计算机辅助设计项目，包括来自Intergraph、ESRI和Bentley等公司的产品。一个IT工作者团队一直致力于通过集中的数据访问方式集成所有软件程序。[9]报告了早期数据整合的努力。

4. GIS Web服务的设计策略

对于不普通的Web服务系统，每个Web服务背后都有一个完成任务的后端系统。在每个Web服务客户机前面通常是一个使用服务的应用程序。此应用程序可以像Web浏览器一样简单，也可以像GIS或CAD应用程序套件一样复杂。图4.1描述了这种Web服务系统的概念结构。“服务消费者”和“Web服务客户端代理”组件位于同一局域网（LAN）中，甚至在同一台计算机中（在我们的实验中，我们使用Java RMI）。同样，后端系统和Web服务交互组件通常位于同一LAN中。但是，在Web服务提供者和Web服务客户机之间，我们只能假设SOAP/HTTP协议，因为系统中可能涉及不同的部门和外部客户机。

分布式软件的许多设计原则不仅适用于Web服务的设计，而且对于应用于GIS Web服务更为关键。在本节中，我们将讨论有关事务模式、服务粒度、通信方式和传输格式的设计决策。

4.1同步服务与异步服务

当我们把地理信息系统推向互联网时，一个地理信息系统Web服务的成功通常是通过点击量来衡量的。具有讽刺意味的是，增加并发命中的数量不可避免地会压倒服务器的容量，因为地理信息系统服务通常需要密集的计算和巨大的数据，从而分别使CPU和带宽紧张。处理性能问题的一般策略是最小化同步事务。将客户机的同步服务调用转换为异步请求的经典方法是使用回调设计模式。当结果准备好后，将通知调用者。

GIS Web服务客户机通常是另一个应用程序或级联映射服务器。正如OGC WMS规范所描述的那样，级联映射服务器是一个WMS，其行为类似于其他WMS的客户机，对其他客户机的行为也类似于WMS。在相同规范给出的示例中，级联映射服务器可以将多个不同映射服务器的内容聚合到一个服务中。此外，级联映射服务器可以代表其他服务器执行其他功能，例如输出格式转换或坐标转换。在后一种情况下，级联映射服务器显然更愿意并行地进行数据获取和格式转换。这需要来自映射服务提供程序的异步服务。应用回调设计模式是为级联映射服务器或也提供其他Web服务的应用程序实现异步服务的一种简单方法。因为它们已经有了自己的Web服务服务器实例，所以只需要包含一个客户端（级联映射服务器或应用程序）的URL，该URL将通知客户端获取结果。回调的实现成本是创建一个Web服务服务器。

通过提供异步服务，服务器不仅可以通过将服务器的计算与客户端的其他操作重叠来从用户的角度隐藏其计算时间，还可以通过对请求进行优先级排序来优化作业调度。

4.2细粒度服务与粗粒度服务

对于GIS Web服务，通过在分布式系统中，因特网是最薄弱的，传输的数据量往往很大。为了避免过度的通信开销，服务的粒度值得特别注意。

对于Web服务系统，粗粒度服务应该优先于细粒度服务，即使传统的面向对象设计倾向于支持细粒度服务以实现灵活性。例如，地理信息系统数据库为用户提供对每个几何元素的访问。但是，如果一个gis web功能服务提供商允许远程用户以与本地数据库相同的访问能力访问本地数据库，那么在用户端组装一个具有数千个功能的地图将导致数千个web服务请求，其通信开销将严重阻碍性能。相反，我们更喜欢提供一系列功能（在边界框中具有某些选定属性）的服务。

以GIS服务为资源进行分析，用户的典型使用模式是查询选择获取。例如，地理信息系统专家将首先查询一个区域中所有可用的要素类。然后从查询结果中手动选择有用的要素类。最后，从资源中提取所选的要素类并将其添加到当前工作空间中。为了有效地实现这种服务，我们强烈推荐一种称为“辅助对象标识”的设计模式，该模式已被CORBA软件社区[7]使用多年。WMS规范中定义的getCapabilities操作是另一个很好的示例，它获取每个Web地图服务的一组丰富的服务级元数据。认识到“二次对象身份”设计模式产生的原因，可以帮助我们积极地将其应用到自己的设计中。我们将使用查询选择获取过程的示例来解释这种设计模式。

假设边界框是一个参数，那么查询select fetchprocess的简单面向对象设计将由四个服务组成：（1）getmaps--返回与边界框重叠的所有映射的服务；（2）getfeatureClasses--返回映射中可用功能类的所有名称的服务；（3）getdesc--返回功能类描述的服务；（4）getFeatureContent——返回功能类内容的服务。使用这些细粒度服务，可以执行查询选择获取过程，如下面的伪代码所述（变量声明和其他详细信息将被省略）。

map_list=getmaps（bounding_box）；

for each map in map_list {

feature_class_list = getFeatureClasses(map);

for each feature_class in feature_class_list {

display(getDesc(feature_class));

}

}

hellip; // the user selects feature classes

for each selected feature_class in its residing map {

getFeatureContent(map, feature_class);

hellip;

}

hellip;

}

假设有M个映射与给定的边界框重叠；每个映射都有F个特征；用户选择C个特征类。然后该进程将进行（1 M*F C）服务调用。“辅助对象标识符”设计模式的基本思想是使用包含对象标识符和足够信息的组合的数据结构来支持用户的选择。相应地，上述任务可以与以下两个服务一起使用：（1）GetFeatureClassInfo——返回与边界框重叠的映射中可用要素类的所有必要信息的服务；（2）GetFeatureClassContent——返回要素标识符内容的服务。使用这些粗粒度服务，查询选择获取过程可以简化为以下伪代码。

feature_class_Info_list=getFeatureClassInfo(bounding_box);

for each feature_class_Info in feature_class_Info_list {

display(feature_class_Info);

}

hellip; // the user selects features

for each selected feature_class in its residing map {

getFeatureClassContent(feature_id);

// feature_id is from in feature_class_Info

hellip;

}

feature_id包含在feature_class_Info中。因此，服务呼叫的数量减少到（1 c）。这种方法的一个隐藏的复杂性是结构featureClassInfo必须包含要素名称，描述和标识信息，例如驻留地图名称和组成feature_id的要素名称。客户端必须能够提取feature_id的值。在SOAP中，可以很容易地表示和解析这种数据结构。

在图4.1中，来自“后端系统”的“响应”似乎只是由“Web服务交互组件”作为SOAP响应转发到Web服务客户端。但是，它们的差异可能不仅仅是格式化，而是粒度明显不同，因为这两个部分的通信差别很大。为了灵活性，我们为“后端系统”和“Web服务交互组件”之间的交互定义了一组细粒度服务。这两个组件位于同一LAN中。另一方面，Web服务提供者提供的服务大多是粗粒度的，因为“Web服务交互组件”和“Web服务客户端代理”通过Internet进行通信。

4.3流式传输与单块传输

流式传输通常用于传输多媒体内容。对于网络浏览图像，流媒体不是非常重要；所需的像素数量将受到网络浏览器屏幕大小的限制。但是，对于浏览大型矢量数据集或功能强大的Web服务客户机（如MicroStation用户），通常需要大型矢量数据集或高分辨率TIFF图像。

SOAP 1.2的规范考虑请求-响应消息交换模式（MEP）绑定中的流。有人说：“在Web服务系统中，响应的SOAP节点可以在仍在接收和处理SOAP请求的同时开始传输SOAP响应。”然而，这不是我们需要的。SOAP请求响应MEP不要求多个请求之间存在任何关联，也不要求为多个请求指定特定的时间。为了支持在固定大小的块中迭代大型数据集，可以应用迭代器设计模式。考虑到传输大型数据集是GIS分析师的常见需求，我们的Web服务设计中包含了迭代器模式。

在“Web服务客户端代理”和“服务使用者”之间进行分离后，向服务使用者组件的最终流传送需要“Web服务客户端代理”和“服务使用者”组件中的目标对象之间的另一个流。这种分离对消费者组件至少有两个好处。首先，消费者组件不需要了解Web服务。第二，即使Web服务在一个整体块中传输，也可以模拟流式传输。在我们的实验实现中，我们使用了Java对象流对象。虽然objectinputstream对象不断尝试读取，但每当块到达“Web服务客户机代理”时，objectOutputstream对象就会发送向量数据集的几何元素或图像的字节数组。

4.4二进制与GML传输

在OGC的努力下，GML的规范迅速发展，以追求几何数据之间的最终互操作性。WFS要求GML在接口中表示特性。（用于存储地理特征的数据存储对于客户机应用程序来说是不透明的。）领先的地理信息系统软件供应商，如ESRI和Intergraph已经实现了WFS。Intergraph还为其几何图形用户提供了GML导出器[3]。在我们的设计中，我们选择在Web服务提供商和MicroStation客户机之间以二进制方式传输数据。这一选择主要是由于性能问题。MicroStation使用DGN文件作为其优化的操作数据表示。对于相同的几何信息，GML文档的大小通常比DGN文件大几十倍。许多MicroStation安装运行在相对较旧的计算机上。将GML转换为DGN需要明显的延迟。美国陆军工程

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[20195]，资料为PDF文档或Word文档，PDF文档可免费转换为Word