SAAS 模 式 WebGIS 关 键 技 术

何 洪 磊

(连云港职业技术学院 信息工程学院，江苏 连云港 222006)

0 引 言

WebGIS(互联网地理信息系统)在当前有着广泛的应用，例如天气预报、调查统计、国土管理、公共设施管理、城市规划、环境评估、灾害预测、军事公安、农林牧业、水利电力、资源调查、邮电通讯、商业金融、交通运输、宣传展示等几乎所有领域。

因此，有众多的用户需要搭建满足自己需求的WebGIS系统。目前，搭建系统的方式通常是使用专业软件(例如ARCGIS、mapinfo、超图)，聘请专业人员开发完成。这样的搭建方式就需要较高的费用成本，对于大部分用户来说构成负担，尤其是一些非核心业务，不频繁使用的用户。而且，在众多的WebGIS系统应用中，有许多是相同或者是相近的，重复搭建也是是一种资源的浪费。

为了解决这种问题，本文提出了一种SAAS模式的WebGIS系统：用户可以通过在线定制的方式搭建符合自己需求的WebGIS系统；用户自己制作的系统可以作为模板共享给其他用户；有着相似应用需求的用户，可以使用某种WebGIS系统模板，修改参数就可以完成自己系统的定制。

1 SAAS模式WebGIS系统结构设计

当前最主流的WebGIS系统是分层式瓦片地图，它将系统功能分解为浏览器端模块和服务器端模块组合实现[1-2]，如图1所示。浏览器端的JavaScript引擎运行地图模块，从服务器端获取地图瓦片并组织成为地图，同时还能够响应用户的缩放、拖动、标记等各种操作。服务器端提供WMS(Web地图服务)、WTS(Web瓦片服务)、WFS(Web要素服务)以及各种应用服务。这样的好处是降低了服务器端的负载，提高了对浏览器的兼容性。

图1 WebGIS系统结构

SAAS模式WebGIS系统设计采用了这种主流的分层式瓦片地图结构，同时又要考虑到SAAS系统用户众多，用户的各种不同需求，就需要实现系统的可定制性。为了满足众多租户的各种需求，在进行系统设计之前，首先对租户的需求进行分析，也就是在众多的租户需求中统计分解出共同的需求和差异化的需求。对于差异化的需求，在系统设计时，要考虑到可以允许租户自己定制，并且不同的用户之间不会互相影响[3-4]，如图2所示。

图2 差异化需求的定制

假设共性需求为D0，可选的差异化需求为Δi(Δ1,Δ2,…,Δk)，那么系统的总需求集是D=D0+Δ1+Δ2+…+Δk。不同用户的需求集可以表示为:

(1)

系统提供服务集，每个服务对应解决一个需求。例如对应解决需求Δi的服务为Si，则系统的总服务集：

S=S0+S1+S2+…+SK

不同用户的服务集可以表示为

(2)

考虑到用户众多，差异化需求会非常多，如果这些需求对应的服务都在服务器端运行，会极大地增加服务器的负载，降低系统的运行性能。为了降低服务器负载，将对应共性需求D0的服务S0在服务器端实现，对应差异化需求Δi的服务Si在浏览器端实现。

系统的一个关键技术就是可定制性，用户可以根据自己的需要，对业务逻辑、用户界面、数据结构进行定制[5]。根据该原则结合WebGIS特点设计了SAAS模式WebGIS系统的结构，如图3所示。

图3 SAAS模式WebGIS系统结构

数据层在服务器端，包括地图瓦片数据、地理信息数据、元数据、应用数据、WMS、WFS、WCS等。用户对数据结构的定制通过元数据实现，同时元数据也是用来保存用户定制的业务逻辑和界面信息。

业务逻辑层包括服务器端Web服务和浏览器端业务逻辑层两部分，服务器端提供多种Web服务，主要是实现用户共性需求的功能。浏览器端业务逻辑层包括地图模块、服务模块、配置模块、控制模块。地图模块实现地图常用功能；服务模块实现差异化需求的功能，提供各种服务模块供用户选择；配置模块是提供用户定制界面、定制服务、定制业务逻辑功能；控制模块是用户定制内容的实现，控制系统按照用户定制的业务逻辑运行。

表示层就是浏览器端提供的用户界面，可以由用户在配置模块中定制。然后将配置信息存放到服务器端元数据表中。用户使用系统时，按照元数据表中的信息显示用户界面。

2 SAAS模式WebGIS关键技术

SAAS模式WebGIS系统既要能满足用户定制需求，同时又要保证服务器的性能。本文设计的解决方案是：采用SOA方式，将系统服务功能分解并模块化，供用户自由配置，然后将负载合理分配到服务器端和客户端。

所以SAAS模式WebGIS系统的关键技术包括：

(1) SOA和负载均衡。将用户共性需求和差异性需求对应的功能分别由多个服务实现，并合理分布在服务器端和浏览器端。当多个用户定制的不同实例同时运行时，降低服务器压力。

(2) 系统可配置性。系统可由用户定制性，包括用户界面、业务逻辑、数据结构等。

(3) 控制引擎。系统能够监听用户活动和服务模块的返回值，按照用户定制的参数运行。

(4) 系统的易用性。用户可以将定制的系统作为模板，共享给其他用户使用。

2.1 SOA和负载均衡

建立SOA架构，首先分析共性需求和差异性需求，然后构建对应的服务模块解决。通过分析，常用的WebGIS系统需求包括：用户管理、地理信息管理、地图管理、类型切换、制图、定时器、数据搜索、数据定制等[6-10]。对应的服务模块如下：

(1) 地图服务。地图服务通过浏览器端的JavaScript API和服务器对应的服务实现。可以通过设置各种参数，包括地图的ID、对齐方式、地图瓦片、中心坐标、宽度、高度等来确定具体的属性。

(2) 地理信息管理。地理信息服务包括地理信息的类别管理和地理信息的添加、删除、修改等。

(3) 用户管理。用户管理包括用户的注册、登录、类别、权限等。

(4) 制图服务。制图服务是指根据地理信息在地图指定的图层中绘制图表。例如在地图上绘制各城市的GDP三维直方图、绘制农田病虫害的散点图、绘制河流湿地的生态图等。

(5) 语音视频通信服务。语音视频通信服务是指提供和地图上的某信息点视频通信的服务。例如远程在线监控、语音视频通话。

(6) 定时器。设置定时器，每隔一个指定时间，执行设定的操作。例如，每隔5 min刷新气象图。

(7) 数据搜索。数据搜索服务包括搜索目标和返回结果显示方式两个部分，搜索目标是指定要搜索的数据库，SQL语句。返回结果显示方式是指返回结果显示区的宽度、高度等样式和显示区界面中的数据集的字段。

其中一些服务对应的类如图4所示：GMap是通过GMAP接口实现的地图对象;GIcon是图标;GPoint是坐标;GPolyline是折线;GMark是标注;GDiv是在地图对象指定图层写入内容的类;Plot是在地图绘制图表的类;Search是实现搜索功能的类;Vedio_comm是实现地理位置实时通信的类;Web_commu是在WebRTC接口实现的浏览器端语音视频通信类。

图4 服务模块类图

系统将用户管理、地理信息管理等用户共同的需求，由服务器端实现。其他的差异化需求由于数量众多，而且用户数量庞大，如果这些需求对应的服务放在服务器端同时运行将会对服务器构成非常大的压力[11]。所以，将对应的差异化需求解决方案由JavaScript模块完成，将这些模块组成解决方案库。用户定制时，选择相应的JavaScript模块，下载到客户端浏览器运行即可。这些浏览器端的运行的服务模块，如果需要访问服务器端的数据库，只需要调用在服务器端的一个数据库操作的Web服务即可，如图5所示。

图5 服务模块的负载均衡

2.2 系统的可配置

系统的可配置包括用户界面、业务逻辑的定制。用户界面就是HTML文档，所以界面自制就用户编辑HTML文档或者DOM对象树。而业务逻辑包括是服务模块选择和业务规则文件的制作。各种服务模块本身也需要配合用户界面，例如地图服务就是Gmap对象实例绑定一个DIV。通常是在HTML文档包含要调用服务的JS库，然后绑定DOM对象并实例化。所以，用户界面定制和服务模块的选择可以一起完成的。

当前浏览器都支持编辑模式，所以主要开启浏览器编辑模式，可以在线编辑HTML文档。流程图如图6所示。

图6 配置流程图

工作过程如下：

(1) 首先生成一个iframe对象，将该iframe的中的document设置成编辑状态(document.designMode="on")，这样，就可以在这个空白文档中实现在线编辑了。然后在用户界面编辑区上方设置一个工具条，用于编辑用户界面和服务模块。

(2) 鼠标光标在编辑区内拖动选择编辑范围，也可以单击鼠标确定坐标。

(3) 编辑器会自动识别选择范围内的对象和其父对象的DOM结构，例如document.table.img,用户如果选择了要编辑的对象，编辑器就会打开一个属性对话框供用户编辑。

(4) 如果用户并未选择编辑对象，而是单击工具栏命令按钮，编辑器就会执行对应的命令。这个命令如果是需要用户设置参数的(例如服务模块、表格、表单等)，编辑器就会打开一个属性对话框供用户编辑，并且每个对象会被设置一个对应的ID(例如，插入的第N个地图模块的ID设置为Map_N)。如果不是，就直接执行。

(5) 编辑器将对应命令执行后的HTML代码写入编辑区，编辑区显示用户编辑的结果，最后把HTML文档和对应的DOM树保存到服务器端。

在上一个步骤中选择了要加入的服务模块，然后制作业务规则文件来组合这些服务。业务逻辑定制过程如图7所示。

图7 业务逻辑定制过程

一个业务规则文件包含多条业务规则，每条业务规则包含3个要素：源对象、事件、动作[12]。当源对象发生了某事件，就会触发指定的动作。例如当搜索服务“search_1”完成搜索，结果返回之后，触发执行绘图服务“Plot_1”，在地图服务“Map_1”上绘制散点图。业务规则以XML文件的格式保存。

〈rules〉

〈rule〉

〈sobj〉search_1〈/sobj〉

〈event〉complete〈/event〉

〈action〉Plot_1(Map_1, search_1.Data. coordinate, Scatter)〈/action〉

〈/rule〉

〈/rules〉

2.3 系统控制引擎

系统控制引擎负责按照用户定制的参数运行系统，包括用户界面和业务逻辑。用户界面数据(HTML文件)保存在用户的元数据表中，因此，系统初始化的时候载入即可,而业务逻辑控制是控制模块的核心。考虑到降低服务器负载便于和用户的交互，控制引擎设计在浏览器端运行，由JavaScript程序完成。控制引擎首先根据用户添加的服务模块载入对应的JavaScript库。然后绑定对应的DOM对象并初始化。接着根据业务规则文件按顺序调用相关服务模块，并监听用户的活动，按照业务规则文件设定的条件对用户活动作出响应[13-16]，如图8所示。

图8 控制引擎结构

对用户活动的监听是指对业务规则中指定DOM对象的监听。为了防止监听浏览器DOM对象的混淆，使用DOM level2事件的监听方法[17-18]：object.addEventListener("event",eventFunction,boolean);object即是业务规则中指定DOM对象，用getElementById(DOM_ID)获取。DOM_ID是指定DOM对象的ID。为了防止事件冒泡，boolean设置为false。

业务逻辑处理可以看做是一个中央流程，单线程的异步模式运行。根据制定的条件确定调用不同的服务模块， 这些条件可以是用户活动或者是上一次调用的服务的返回值。业务逻辑处理根据条件构造循环、声明变量、复制和赋予值、定义故障处理等操作。

考虑到JavaScript必须在一个页面运行，更换页面后不能持续运行。所以必须保持一个主页面运行控制引擎，其他的可变活动，放在iframe内运行。另外，考虑到浏览器意外关闭。将控制引擎的执行过程记录到cookie本地数据中。如果出现意外关闭浏览器等情况，可以从断点处继续执行。

3 实 例

3.1 可定制性验证

为了验证开发的SAAS模式WebGIS平台能否在运行时支持多个租户执行不同业务流程实例,不同流程实例之间能否隔离。在客户端模拟2个租户,租户分别设置配置方案,然后将这些配置方案存为不同的用户配置文件,实验环境配置如表1所示。

表1 实验环境配置

其中, 租户A需要一个园区规划的WebGIS平台，将园区三维地图瓦片上传到服务器端，调用地图瓦片，使用折线工具和标注工具绘制规划图，租户A的配置文件如表2所示，运行结果如图9所示。

图9 园区规划

租户B需要户外运动管理的WebGIS平台。由于人员众多，每次活动将参与人员分成几组，每组有个编号，由一个组长管理。每个组长的手机在系统注册并登录，这样系统可以随时获得组长的GPS位置。当租户B需要查找各个小组的当前位置并查看情况时。在搜索框内输入地理坐标的范围，就可以搜索范围内所有小组，并在地图上用标注显示。单击某个标注，调用语音视频通信服务，可以和组长视频通信，查看当前状况。租户B的配置文件如表3所示，运行结果如图10所示。

表2 租户A的配置文件

表3 租户B的配置文件

图10 户外管理

实验结果表明,开发的SAAS模式WebGIS平台能够根据租户配置文件派生出不同的流程实例,而且各个流程实例的执行是相互隔离的、互不影响。

3.2 系统性能评估

为了进一步评估SAAS模式WebGIS平台的服务性能，将传统SAAS模式和本文提出的模式做一个对比。

传统模式下，所有服务实例都是运行在服务器端(见图11)，本文提出的模式下，只有通用服务S0(初始化和数据访问)实例在服务器端运行，其他差异化服务实例在客户端运行，见图12。

图11 传统SAAS模式

图12 负载均衡SAAS模式

下面讨论两种模式下各个实例的响应时间的对比。

定义1服务器有P个，第j个服务器表示为Vj，它的计算机能力表示为Fvjj∈P。

定义2客户端有Q个，第i个客户端表示为ci它的计算机能力表示为Ecii∈Q。

为了简化计算，假设所有实例内的服务都是顺序执行。实例αb的服务集的工作量为

(1) 传统SAAS模式下，所有服务部署在服务器端。单位时间内到达的服务请求工作量

(3)

服务器平均处理速度=PF/G。

假设在未超负荷运行的情况下，根据排队论的Erlang C结论：

其中,Ec是Erlang C公式，表达式

(4)

所以，对于客户实例i总体的服务响应时间

(5)

1≤mi≤ni≤k

(2) 本文提出的SAAS模式，初始化服务S0部署在服务器端,其他服务部署在客户端。

单位时间内到达服务器的服务请求工作量

(6)

根据式(5)，服务器端处理时间：

所以总体的响应时间

(1≤mi≤ni≤k;i∈Q)

(7)

使用Matlab 2014b进行模拟评估，为了简化计算，假设服务器数量P=2个，每个服务器的计算能力Fvj=100(工作量/s)，每个客户端的计算能力Eci=20(工作量/s)，每个实例包含的服务数量K=5个，每个服务Sk的工作量都=1，所有客户端i请求速率R=1(次/s)。

表4 两种SAAS模式的响应时间

图13 两种SAAS模式的响应时间对比

由图13可知，当客户端较少时，传统的SAAS模式响应时间较快，随着用户端数量的增加，传统SAAS模式的响应时间会迅速增加，远远高于本文提出的SAAS模式响应时间。而本文提出的SAAS模式的响应时间非常平稳，基本不会随客户端数量发生变化。

4 结 语

采用面向服务架构，将用户常用功能分解并模块化，用户可以自由配置系统，将负载合理分配到服务器端和客户端执行，用户系统实例运行由流程控制引擎来控制。所以SAAS模式WebGIS系统的关键技术包括：SOA和负载均衡、系统可配置性、流程控制引擎、易用性。通过两个实例的建立，验证了系统关键技术的解决方案是有效的。

另外，由于WebGIS系统的需求繁多，系统开发人员不可能开发满足所有应用的服务模块，考虑以后提供系统接口，用户自己开发服务模块，并分享给其他用户使用。