基于SOA的GIS应用设计与实现.docx
《基于SOA的GIS应用设计与实现.docx》由会员分享，可在线阅读，更多相关《基于SOA的GIS应用设计与实现.docx（17页珍藏版）》请在冰豆网上搜索。
基于SOA的GIS应用设计与实现
基于SOA的GIS应用设计与实现*
摘要：
随着网络技术的快速发展，SOA作为构建企业级分布式软件系统的思想和方法学，已经得到了越来越广泛的应用。
本文主要探讨了如何基于SOA技术实现传统的GIS应用系统。
首先，我们介绍了SOA解决的GIS系统中模块复用的两大问题：
封装和组合，以及现阶段还存在的问题，如海量数据和QoS等，接着简单介绍了当前SOA在GIS中的应用情景。
最后，我们通过一个小型校园GIS服务应用实例PKUMAP，详细阐述了如何利用SOA的核心技术，如SCA，BPEL来构建GIS应用系统。
关键字：
GIS分布式建模SOASCABPELwebservice
1.引言
GIS（GeographicInformationSystem）系统利用人们所采集到的地表各种信息，如高程信息、地理位置信息等，为地理学家、相关领域专家和普通大众提供与地理问题相关的各种功能和服务，如地理位置查询、导航、空间分析等。
GIS系统概念自提出以来就与计算机技术的发展紧密联系在一起，传统的GIS系统主要由封闭的、孤立的、单机的计算机软件系统组成，并主要为专业人员进行专业领域研究所用。
随着计算机技术的发展和网络技术的大众化，GIS系统的构建技术也随之改变，出现了开放的、联网的、多机的GIS系统架构，其应用范围和使用人群也出现了较大的变化，由以往的专业人员使用的系统转换扩展为大众日常生活工作使用的工具。
然而，GIS系统的许多特点给其应用的架构设计和使用方法造成了许多难以解决的问题和障碍。
首先，地理信息系统需要面对海量数据的处理和操作问题。
地理数据是指地理信息系统在提供地理相关功能和服务时所依赖的各种形式和用途的地理数据，常见的如地图数据、地理实体数据、高程数据等。
随着GIS与GPS、RS等技术的不断结合，人们获得各种地理数据的途径更加多样化，获取的各种数据也逐渐增多，据统计，每日所获得并需要处理的地理信息数据都在TB的量级上。
面对地理信息数据的海量性，许多数据方面的问题纷纷暴露了出来，制约了GIS系统的发展。
GIS系统在开放的网络上发展时，首先需要解决如何卸载庞大的数据包袱问题。
传统的GIS系统一般都存在自己的数据格式，不同格式之间的数据需要通过相互转化或者中转才能互通，这造成了不同系统之间的功能难以共享数据、数据重复浪费以及数据更新难以统一等问题。
其次，随着Web的不断发展以及WebServices等关键技术的成熟，越来越多的GIS产品和个性化GIS服务正不断在网络中涌现出来，GIS系统所提供的各种功能也更加贴近大众的需求。
然而，各个厂商和服务提供者所提供的各种与地理信息系统相关的服务之间不仅服务质量、服务数据不同，其实现方式和服务接口也大相径庭。
基于这些原因，各种网络上的GIS服务更多的是以一种实验性的、小粒度的、简单的服务类型为主，难以为用户的实际需求服务。
如何能够统一各种不同的服务以将这些分散的、独立的服务有机地统一起来是目前的各种GIS系统所面临的较困难的问题。
第三，随着GIS系统在网络上的不断发展，各种GIS数据和GIS服务构成了日益复杂的GIS系统，如何能够协调各种服务和数据并以更加贴近大众使用的角度完成服务和数据的查询、使用和组合是GIS系统面临的又一问题。
综上所述，面对日益复杂的分布式网络环境，GIS系统的应用受到了以上这几方面问题的制约，一方面，面对普通大众，GIS系统应该做到屏蔽底层的专业特性，提供简单易懂的服务接口供用户组合个性化的服务；另一方面，面对有特殊的专业需求，如地理建模等，要求GIS系统能够最大限度地共享和复用各种GIS专业功能和数据、最大效率地执行地理计算要求。
为了能够实现这些目标，需要从软件和网络架构方面考虑整个GIS系统的设计和构成，而SOA作为一个新兴的企业级分布式软件架构思想，可以为GIS系统的构建提供帮助。
2.SOA在GIS系统中的应用
如上文所述，随着GIS在各个领域内的不断应用，GIS软件已经逐渐走向网络化和开放化，GIS系统的不同模块、地理数据也常常部署在分布式网络的不同结点之上。
SOA作为构建企业级分布式软件系统的思想和方法学，其中的多种关键技术可以帮助设计和搭建出更加灵活、更加贴近应用的GIS系统。
2.1SOA对于GIS系统的积极作用
我们认为，SOA思想对于GIS架构的积极作用体现在两个方面：
第一，利用标准的接口和访问方式对外提供地理信息系统中的各种功能，即模块的封装性；第二，以贴近应用的形式自然地处理不同模块之间的关系，即模块间的组合性。
2.1.1模块的封装性
模块封装性的意义在于屏蔽不同模块以及来源不同的数据所存在的格式、访问方式、运行平台的问题。
经过标准封装的模块能够实现跨平台、跨实现语言的调用，除了能够对外提供标准的接口供调用外，还为今后复用此模块的内容打下了良好的基础。
SOA中的接口主要体现在服务上，服务一般指一个可以完成某种功能的模块的实例，利用WebService技术封装模块成为服务时，服务的接口就是以WSDL描述的服务定义文档。
服务的接口定义了服务的位置、参数及访问方式等，服务的调用者依靠这些信息向服务发出消息调用服务而不是以类似调用某个方法的代码形式调用服务。
服务的调用者也不需要考虑网络环境、服务所处的平台以及服务实现的语言等信息。
模块的封装性为GIS平台提供了两方面的便利：
模块的复用以及地理数据的共享。
Ø模块的复用
GIS系统往往存在一些常见的公共功能，如地图打印、地图数据格式转换、空间位置计算等，这些功能在各个GIS系统中都不难发现。
然而，这些功能常常紧密耦合于系统的设计实现方法，往往是每实现一个GIS系统时，都需要根据系统的设计结构重新实现一遍，造成了资源的重复浪费。
如果能将各个厂商提供的不同系统的公共部分抽取、划分并进行服务封装，对外提供标准的服务接口，这样新的地理信息系统实现时仅需引用相关服务即可，提高了模块的复用性。
模块的标准封装也屏蔽了模块的实现方式、访问方式等问题，使模块的服务化管理成为可能。
Ø地理数据的共享
各个厂商和GIS系统所使用的地理数据往往千差万别，难以统一和通用，而地理数据作为GIS系统的基础，是整个地理信息系统的重要组成部分，在面对海量地理数据时，如何共享地理数据则成为了关键问题。
目前，SOA的几种方法可以从不同角度解决地理数据的共享和传递问题：
1.通过SDO（ServiceDataObject）封装具有一定结构的、相关的地理数据，这样，在不同的模块之间只需要传递具有良好内部结构的SDO对象即可；2.在OGC提出的GML格式的地图数据基础上，人们又设计了许多基于服务的地理数据共享手段，如WMS（WebMapService）、WFS（WebFeatureService）和WCS（WebCoverageService）；3.利用ESB（EnterpriseServiceBus）思想设计GIS系统服务总线，为连接到总线上的不同模块设计数据传输协议和数据转换模块。
2.1.2模块间的组合性
模块间的组合性描述了在分布式环境中如何通过将相对独立的、小的模块组合成为更大的、有一定应用意义模块的过程。
模块的可组合性给软件带来了业务上的灵活性，不同的模块组合往往能够代表不同的业务逻辑和实现效果。
SOA利用SCA（ServiceComponentArchitecture）、BPEL（BusinessProcessExecutionLanguage）以及消息驱动等手段完成不同模块、服务之间的集成和组合。
SCA偏重于粗粒度的服务集成，组成一个SCA模块的各个部分通常可以存在于不同地方、使用不同的方式（如语言、所处平台等）实现；BPEL偏重于流程上的服务集成，组成一个BPEL的服务各自之间可以毫无关联，由BPEL本身将他们连接起来并形成一段有业务意义的流程形式的过程；消息驱动利用消息传递模式和消息传输中间件创造具有松散耦合关系的模块组合。
不同的服务组合方式为GIS系统提供了不同的设计方法：
Ø基于地理意义的服务组合
在GIS系统中，许多功能是以配套或者紧密关联的形式出现的，如地图浏览时必须包括地图的缩放、平移等功能，地图查询时，需要包括临近查询、POI查询、路径计算等功能，这些功能相对独立，却存在地理意义上的联系。
这些功能往往存在较多的实现算法和实现方式，因此，基于SCA的服务组合方法正适合于将这些彼此异构却又相互联系的不同部分组合成为一个有机的整体对外提供统一的服务。
此外，SCA支持异构模型、服务的集成能力，当面对使用不同形式实现的各种地理服务资源时，SCA可以轻松地将他们整合成为一个完整的模型并对外提供基于WebService的标准访问接口。
Ø基于地理过程的服务组合
地理过程描述了一个有步骤的地理功能执行和完成过程，这种过程在GIS系统中非常常见，例如在查询路径时需要首先根据用户输入的内容在数据库中查询起点和终点的坐标信息，然后根据道路拓扑信息按照一种选定的道路计算方法计算路径情况，最终将计算结果打印在地图图片上反馈给用户等。
这些地理过程所涉及到的功能往往是相互独立的，可以作为独立的功能或者服务出现，体现了地理服务的可编排性。
因此，利用BPEL的服务组合方法可以将这些服务灵活地组合在一起从而提供具有一定业务意义的地理功能。
另外，基于流程的服务组合方式也以一种更贴近用户的方式完成服务的过程，即GIS系统中可以提供一组独立的地理服务，用户根据自身的需要，利用服务链的方式完成个性化的、更具实际意义的服务组合过程。
Ø基于地理事件的服务组合
在空间分析、地理模型模拟等与GIS系统紧密联系的系统中，地理事件的发生通常会触发与GIS系统相关的其他功能计算过程的执行，地理事件的产生模块与消费这个地理事件的模块通常具有各自的独立性，而传统的地理信息系统却通常根据地理事件的联系将这些模块划分到一起。
SOA所依赖的底层消息驱动模式可以为基于地理事件的不同模块之间的协同和组合提供便利，而这种消息驱动模式通常是由消息传输模式和消息传输中间件共同组成的。
2.2SOA尚未解决的GIS问题
SOA思想并非完全为地理信息系统所设计，所以在许多方面尚未解决分布式地理信息系统的问题，但我们可以在SOA架构思想的基础上，通过改善和扩展SOA的体系结构从而使其更适应于GIS系统的构造。
这些问题主要体现在：
Ø海量数据的传输问题
地理数据往往是海量数据，SOA可以利用数据封装方法共享地理数据，但在某些需要传输地理数据进行分析的场合，如空间分析、空间插值等，并没有较高效的方法。
Ø地理过程的状态性问题
对于涉及到时间模拟行为的GIS系统来说，常常需要在系统的运行过程保存一些重要的中间结果作为中间状态，而SOA的服务概念本身是无状态性的，因此，在面对这种地理过程状态问题时，需要考虑如何设计服务。
ØQoS问题
SOA由于采用了服务化的封装和设计思想，在运行效率、数据安全等方面目前还较差，难以满足某些QoS要求较高的GIS应用场合。
2.3目前SOA在GIS中的应用情景
随着SOA思想的不断成熟和应用，越来越多的研究围绕将SOA与GIS结合这个主题展开，然而，目前的研究主要集中在两个方面：
Ø以WebServices在GIS中的应用展开
这一角度通常通过WebService体系结构中的“服务提供者、服务注册中心、服务消费者”三角结构说明GIS系统中如何采用WebServices思想进行设计和实现。
然而，SOA并非WebServices,所以，这些研究从宏观架构角度上并未真正与SOA结合。
Ø以大型GIS系统的架构性设计展开
这一角度目前主要试图应用一些SOA的思想，如服务划分、服务总线思想等，对某些整体架构进行设计，从宏观的角度阐释SOA应该如何指导架构的设计，但这些研究往往是一些较为大型系统的架构性设计，缺乏细节的描述和实际的实现，停留在概念化的层次。
下文中我们将围绕一个小型的校园GIS系统实例展开，通过讨论其设计和实现的过程展现SOA思想及其关键技术在GIS系统中的具体应用和实现过程。
3.基于SOA的GIS应用示例—以校园地图服务为例
3.1系统结构与功能
为方便游客及校内师生了解北京大学校园概况及查找校内各机构详细地址，我们开发了面向北大的校园导航服务系统PKUMAP。
PKUMAP是采用了SOA相关技术实现的面向GIS平台的轻量级Web应用，其结构示意如图1所示。
图1PKUMAP结构示意
如图1所示，PKUMAP由客户端程序、地图引擎、相关地理数据及一系列LBS服务组成，可以向用户提供基本的地图操作，如平移、缩放等，并可以提供POI查找和路径查询两个LBS服务。
下面将详细介绍系统中使用的数据及提供的所有web服务。
3.1.1数据说明
PKUMAP使用的原始数据为GML格式的北京大学地理数据，共358KB（详细图层信息如表1所示）。
表1图层详细信息
Layername
Geometry
Layername
Geometry
Land
polygon
Forest
line
Lake
polygon
Road
line
Playground
polygon
Restaurant
point
Dorm
polygon
Gate
point
Admin
polygon
Entrance
point
LiveBuild
polygon
POI
point
此外，我们还将所有的POI信息存储于远程数据库中，以供POI查找服务使用。
对于路径查询，需要已知校园内所有道路的详细信息。
我们从原始GML数据中提取出全部道路数据，根据道路之间的交叉情况生成一张道路节点的拓扑关系图，存于二进制文件中，共35.4KB。
3.1.2服务描述
在PKUMAP的结构中，最核心的部分为支持地图显示的地图引擎。
地图引擎包括地理数据解析、地图绘制、地图打印、提供LBS服务4个模块，这些模块相互之间比较独立，并可以采用不同的实现方式，通过统一的接口相互调用。
针对这一特点，我们采用SCA作为整个地图引擎的实现技术，将上述多个模块作为SCA的多个Component，分别独立提供webservice。
对于POI查询，可以认为是一个原子级别的LBS服务，我们仅将其封装成一个普通的webservice。
对于路径查找，其中需要涉及到起始点和终止点的坐标查找、最优路径计算等多个流程，其中最优路径计算可以采用不同算法实现，针对这一特点，我们采用WS-BPEL作为路径查找的实现技术。
PKUMAP包含的所有web服务如表2所示。
表2webservicelist
Webservice
Function
ParseService
解析GML数据到内存中
PrinterService
将内存中绘制的地图打印为JPEG文件
RenderService
根据解析后的地图数据，绘制地图，以及LBS服务的结果展示
LBSProviderService
在mapengine中负责调用封装为webservice的所有LBS服务
FinderService
提供POI查询
RouteService
提供道路查询服务
PathService1
根据道路拓扑结构，最优路径核心计算方法1
PathService2
根据道路拓扑结构，最优路径核心计算方法2
GetNearestNodeIDService
提供在拓扑结构中距离起始和结束点最近的道路节点ID
其中，ParseService、PrinterService、RenderService、LBSProviderService作为4个独立的Component，组成了MapEngine。
RouteService提供道路查询服务，需要调用PathService1（或2）和GetNearestNodeIDService。
几个典型服务的详细设计与实现会在3.2节介绍。
3.2典型服务的设计与实现
3.2.1兴趣点查找
FinderService旨在帮助用户确定POI的地理位置。
用户输入感兴趣的地点名称，服务器会返回高亮POI的地图到客户端。
FinderService利用Axis2发布为简单的WebService。
FinderService的接口定义和发布时的service.xml分别如下所示。
其中，find方法返回的string结果为所查找实体的地理坐标信息。
publicinterfaceFinderService{
publicStringfind（StringfeatureName）;
}
图2FinderService接口定义
xmlversion="1.0"encoding="UTF-8"?
>
Afinderservice
lbs.FinderService
RPCMessageReceiver"/>
图3service.xml
采用同样方法，PathService1、PathService2和GetNearestNodeIDService也发布为简单的webservice。
3.2.2路径查找
RouteService旨在帮助用户确定从起始点到结束点的路径。
利用WS-BPEL发布为WebService。
其BPEL调用流程如图4所示。
图4RouteService的WS-BPEL调用流程
由图4可以看出，首先RouteService会两次调用已发布的远程web服务GetNearestNodeIDService，得到用户所输入的起始点和结束点在道路拓扑结构中的Node节点ID。
将起始点和结束点的拓扑Node作为参数调用远程web服务GetPathService，即可返回相应的路径。
其中，用户可以根据不同场景选用不用算法实现的路径服务，例如距离最短或时间最短等等。
RouteService的接口定义以及BPEL文件片段如下所示（这里我们省略了变量赋值部分）。
publicinterfaceRouterService{
publicStringroute（StringstartFeaID,StringstartX,StringstartY,
StringendFeaID,StringendX,StringendY）;
}
图5RouteService接口定义
partnerLink="routePLT"
protType="ns1:
RouteService"
variable="routeRequest"/>
...
operation="getNearestNodeID"
outputVariable="getNearestNodeIDResponse1"
partnerLink="getNearestNodeIDPLT"
protType="ns2:
GetNearestNodeIDPortType"/>
operation="getNearestNodeID"
outputVariable="getNearestNodeIDResponse2"
partnerLink="getNearestNodeIDPLT"
protType="ns2:
GetNearestNodeIDPortType"/>
...
（number（$svc1）=1）
...
operation="getPath"
outputVariable="getPathService1Response"
partnerLink="getPathPLT1"
protType="ns3:
GetPathService1PortType"/>
...
operation="getPath"
outputVariable="getPathService2Response"
partnerLink="getPathPLT2"
protType="ns4:
GetPathService2PortType"/>
...
protType="ns1:
RouteService"variable="routeResponse"/>
图6RouteService的BPEL文件片段
3.2.3地图引擎
在PKUMAP的各个远程服务中，直接与用户进行交互的是MapEngineService。
如3.1节所述，MapEngine由数据解析模块、绘制模块、打印模块及LBS服务模块组成。
我们将其封装成SCAWebService，利用Tuscany发布。
各个模块作为SCA的各个Component。
MapEngine的SCA结构如图7所示。
图7MapEngine的SCA组成
其中，用户通过RenderServiceComponent提供的远程服务来获取相应的结果数据。
RenderServiceComponent会引用其它三个组件提供的services，而LBSServiceComponent远程调用FinderService和RouteService。
LBSServiceComponent的接口定义和实现片段如图8和图9所示。
publicinterfaceLBSservice{
publicStringfind（StringfeatureName）;
publicStringroute（StringstartFeaID,StringstartX,
StringstartY,StringendFeaID,
StringendX,StringendY）;
}
图8LBSService接口定义
@Reference
publicFinderServicefinderService;
升级会员 