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系統的需求繁多，系統開發人員不可能開發滿足所有應用的服務模塊，考慮以后提供系統接口，用戶自己開發服務模塊，并分享給其他用戶使用。