張學寶，白 丹

（西安理工大學 水利水電學院，西安 710048）

目前，我國各水利主管部門在信息化建設中多采用試點分批建設模式，缺乏統(tǒng)一的系統(tǒng)規(guī)劃、軟件架構(gòu)和技術(shù)標準，導致系統(tǒng)后期難以擴展和維護，信息共享和交換困難，系統(tǒng)的孤立性越來越突出。這些問題經(jīng)過長期的積累，業(yè)務系統(tǒng)便成為了一個個“信息孤島”[1,2]。如何消除系統(tǒng)之間的壁壘，實現(xiàn)水利業(yè)務系統(tǒng)的集成、數(shù)據(jù)交換、信息共享以及輔助決策將變得越來越重要[3-5]。為有效解決這個問題，水利部門需建立一個靈活的、易于擴展和遵循一致系統(tǒng)標準的應用架構(gòu)。它既可以兼容現(xiàn)有的應用，又能夠滿足未來新的需求，實現(xiàn)水利業(yè)務的高度集成，使得基于不同GIS平臺、不同硬件環(huán)境、不同語言實現(xiàn)的業(yè)務系統(tǒng)都能夠很好的進行信息交換，讓系統(tǒng)更具彈性，能更快響應業(yè)務需求變化[6]。

正是在這種需求之下，SOA（Service-Oriented Architecture，面向服務架構(gòu)）應運而生。SOA是一種適用于分布式、變化環(huán)境的體系架構(gòu)。它首先將系統(tǒng)功能定義為服務，服務之間通過中立的接口形式進行交互。接口獨立于實現(xiàn)細節(jié)，便于異構(gòu)分布式系統(tǒng)基于通用標準進行信息交換，它能夠消除信息共享的瓶頸[7,8]。基于SOA架構(gòu)的水利GIS系統(tǒng)主要針對傳統(tǒng)組件式模型以及分布式對象模型（如DCOM、EJB、CORBA等）的不足，將Web上的數(shù)據(jù)資源和業(yè)務功能以數(shù)據(jù)服務和功能服務的形式加以發(fā)布和共享，以實現(xiàn)異構(gòu)平臺互操作。研究發(fā)現(xiàn)，基于SOAP、WSDL和WS-*規(guī)范的Web服務是實現(xiàn)SOA架構(gòu)的標準技術(shù)，但是，水利信息服務是一種基于GIS技術(shù)的空間信息服務，傳統(tǒng)基于SOAP協(xié)議的 Web服務技術(shù)并不能很好地支持水利GIS空間信息服務，它具有如下局限性：

1）SOAP協(xié)議棧問題。GIS數(shù)據(jù)與結(jié)構(gòu)化數(shù)據(jù)具有很大的不同，比如具有空間參考、空間索引、海量存儲等特點，傳統(tǒng)的基于協(xié)議棧設計并不符合GIS[9]。

2）采用XML-RPC模型。XML-RPC協(xié)議比較復雜，客戶端和服務器端須嚴格遵守WSDL接口標準，不滿足高內(nèi)聚、低耦合的設計要求，難以實現(xiàn)Web無縫擴展[10]。

3）基于SOAP的Web服務依賴于接口標準，使得每個SOAP消息必須使用定制的方法原型，需要定義獨立的接口，這并不利于服務的互操作[11]。

4）基于SOAP的Web服務采用XML傳輸空間數(shù)據(jù)，存在大量數(shù)據(jù)冗余，不利于網(wǎng)絡傳輸。

考慮到SOA架構(gòu)技術(shù)是消除水利“信息孤島”的有效途徑之一，并且基于SOAP協(xié)議的Web服務技術(shù)不能有效支持空間信息服務，所以，采用何種架構(gòu)技術(shù)實現(xiàn)面向服務型的水利信息服務平臺是一個值得研究的課題。

1 REST架構(gòu)

REST（Representational State Tran-sfer，表述性狀態(tài)轉(zhuǎn)移）的提出，為構(gòu)建水利信息服務平臺帶來了契機。REST是一個軟件架構(gòu)風格，也是一系列原則組成的Web約束。它以服務器上具有唯一的標識符URI（Uniform Resource Identifier，統(tǒng)一資源描述符）作為出發(fā)點，URI的形式代表了資源的訪問接口，客戶端可以使用HTTP協(xié)議的幾個標準方法（GET、POST、PUT、DELETE）訪問和操作服務器上的資源?；赗EST架構(gòu)風格的Web服務完全根據(jù)HTTP、XML、JSON等標準構(gòu)建，并通過URI操作服務器上的資源，易于實現(xiàn)跨平臺、跨語言集成以及支持空間數(shù)據(jù)表述。REST目前已經(jīng)成功應用到了Web服務開發(fā)和企業(yè)信息集成領域。其實，包括IT界巨頭Yahoo、Google、Amazon等Web2.0公司都采用了 REST 架構(gòu)技術(shù)，他們都放棄了傳統(tǒng)的Web服務技術(shù)。Web服務是實現(xiàn)SOA架構(gòu)的主要方法，然而，基于REST風格的Web服務構(gòu)建卻非常簡單，并支持空間數(shù)據(jù)表述。因此，實現(xiàn)水利信息服務的關(guān)鍵是實現(xiàn)基于REST架構(gòu)的空間信息服務。目前已經(jīng)有大量開發(fā)框架支持REST開發(fā)，如Jersey、WCF REST等。

目前，研究基于REST架構(gòu)風格的Web服務技術(shù)在水利信息服務領域的應用還很少。因此，本文主要探討基于REST的“輕量級”Web服務技術(shù)在水利信息服務平臺設計與實現(xiàn)中的應用，設計基于REST架構(gòu)的水利信息服務平臺，并研究該服務平臺實現(xiàn)的關(guān)鍵技術(shù)。

REST架構(gòu)原則[12]：

1）為所有資源定義ID。在REST架構(gòu)中所有服務器資源都必須是可標識的，都應該有一個明確和不同的URI。如：http://www.hydro.com/water/map表示一張水系地圖。

2）將所有事物鏈接起來。REST可以通過鏈接的形式實現(xiàn)信息導航，例如下面這個XML表述：

基于鏈接的設計，使得客戶端能夠通過鏈接，將應用從一個狀態(tài)改變?yōu)榱硪粋€狀態(tài)，即狀態(tài)轉(zhuǎn)移。

3）使用HTTP標準方法。服務器上資源的接口可以定義如下：

只要服務器上所有的資源都實現(xiàn)該接口，它們都將支持HTTP標準的幾個方法?？梢允褂胓et方法檢索一個表述，即對資源的描述。

4）資源的多重表述。對同樣一個資源可以有多種表述形式，如HTML、JSON、XML、Image等，易于異構(gòu)平臺實現(xiàn)信息共享。

5）無狀態(tài)。無狀態(tài)指的是在服務器端不保持客戶端的操作狀態(tài)，比如使用Session保存狀態(tài)信息，使得客戶端不依賴于同一個服務器，這一點非常易于實現(xiàn)集群部署。

2 設計思想

依據(jù)REST架構(gòu)原則以及軟件設計方法，設計思路如下：

1）首先，實現(xiàn)各種基礎組件，如緩存切片引擎組件、業(yè)務模型組件、水文分析組件和GIS引擎組件。其中，GIS引擎借助開源GIS項目，實現(xiàn)對底層基礎地理和水利專題數(shù)據(jù)的訪問支持，并提供投影變換、拓撲運算、空間查詢、空間分析、數(shù)據(jù)可視化和地圖制圖等基本功能。

2）在基礎組件之上設計和實現(xiàn)各類服務，如地圖服務Map Server、幾何服務GeometryServer、要素服務FeatureServer、水文服務HydroServer、緩存切片服務TiledServer、業(yè)務服務BusinessServer等。其中，地圖服務主要實現(xiàn)地圖瀏覽、空間查詢、符號化和制圖功能；幾何服務主要實現(xiàn)各種幾何運算，如幾何求交、空間包含等；要素服務主要實現(xiàn)支持OGC SFS規(guī)范要素的更新和刪除操作；水文服務主要實現(xiàn)等值面、等值線生成等服務；緩存切片服務主要實現(xiàn)地圖緩存切片的讀取和顯示功能；業(yè)務服務主要支持業(yè)務功能原型。

3）提供這些服務對象的調(diào)度、管理、日志、安全和聚合等功能，如設計服務實例管理器，實現(xiàn)對各種服務的統(tǒng)一管理，如創(chuàng)建、啟動、停止、刪除、檢索等。

4）REST服務接口層設計，將第2步中設計的各種服務對象按照REST架構(gòu)風格進行封裝，并以REST接口形式對外提供服務，服務協(xié)議遵循HTTP規(guī)范，交換信息以JSON、XML、HTML和Image等格式為準。

5）提供多種客戶端開發(fā)API，如Flex API、Silverligth API和Javascript API等。

2.1 分層體系架構(gòu)設計

分層是最主要的一種軟件設計方法，依此，筆者設計了基于REST架構(gòu)風格的多層水利信息服務平臺，如圖1所示。

圖1 水利信息服務平臺分層體系架構(gòu)

平臺從底向上主要劃分了如下幾個層次：

1）數(shù)據(jù)源層主要存儲了水利各種空間和非空間數(shù)據(jù)，如水利基礎地理數(shù)據(jù)、水利專題和業(yè)務數(shù)據(jù)。

2）組件層是平臺的核心層，主要實現(xiàn)各類基礎組件，如緩存切片引擎、GIS引擎、業(yè)務組件模型和水文分析等。

3）服務對象層是核心層的封裝，它的粒度往往要大于組件層粒度，提供的接口也更易于使用，接口參數(shù)大都設計為支持可序列化操作的對象。該層設計和實現(xiàn)的好壞將大大影響平臺的性能、安全和穩(wěn)定。為了支持高并發(fā)用戶訪問，平臺提供的各種服務必須是可池化的，這就要求平臺需提供一個支持池化的機制來實現(xiàn)對服務的托管運行，當用戶請求經(jīng)過Web容器調(diào)度到達該層時，由服務實例管理器從池中取出一個空閑服務對象處理該請求，請求處理完畢后，自動將該實例返回池中；當池中沒有空閑對象時，用戶請求線程將會等待，直到有空閑對象或者超時結(jié)束。此外，服務對象對外提供的服務必須是經(jīng)過身份認證的，未經(jīng)授權(quán)的用戶是不允許訪問服務的。

4）REST服務接口層主要依據(jù)一致和簡約的標準，以REST的形式對外提供各種服務對象的方法。該層主要為客戶端API設計，是客戶端程序和平臺交互的唯一入口。

2.2 彈性云服務

水利信息服務平臺主要面向網(wǎng)絡用戶提供水利空間信息服務，因此，平臺必須支持高并發(fā)用戶訪問和支持高可擴展。以往的平臺在支持高并發(fā)用戶訪問時，大都采用集群技術(shù)，即通過在兩臺或者多臺物理機器上部署平臺的物理拷貝，并通過集群軟件或者硬件實現(xiàn)負載均衡和容災處理，以支持多用戶不間斷并發(fā)訪問。這種技術(shù)將逐漸被虛擬化技術(shù)和云計算技術(shù)代替。我們知道，判斷云計算技術(shù)的一個原則就是是否支持彈性服務，所謂彈性服務就是根據(jù)用戶請求量能夠動態(tài)伸縮的服務。云計算平臺提供了強大的資源池，這些資源主要以服務形式提供，如CPU、內(nèi)存、存儲和網(wǎng)絡資源，但對于一個水利信息服務平臺而言，它提供的服務還包括緩存切片服務、水文分析服務、水利專題制圖服務、空間信息查詢服務等。

為了使得水利信息服務平臺支持彈性云計算，其必須具有自我感知能力，這也是一種自我診斷的能力。當大量用戶訪問水利信息服務時，它會觸發(fā)系統(tǒng)預先設定的各種規(guī)則，進而，平臺會自動調(diào)用云操作系統(tǒng)Cloud API創(chuàng)建預先安裝該軟件的虛擬機，并自動構(gòu)建整個集群環(huán)境，整個過程不需要人的任何干預。圖2顯示了支持彈性云服務的技術(shù)架構(gòu)，在這個云環(huán)境中，控制服務器提供了云操作API，如創(chuàng)建、啟動、停止、刪除虛擬機等。圖2假定了在每臺物理服務器中部署了4個虛擬機，每個虛擬機托管運行1個水利信息服務平臺，平臺通過服務監(jiān)控模塊實現(xiàn)對各種服務的監(jiān)控和記錄，當客戶請求達到預先設定的規(guī)則時，監(jiān)控引擎將自動執(zhí)行預先裝載的規(guī)則，調(diào)用云操作系統(tǒng)API，以實現(xiàn)對虛擬機的管理。整個過程演示了水利信息服務平臺的自我彈性伸縮管理。

圖2 彈性云服務技術(shù)架構(gòu)

3 平臺關(guān)鍵技術(shù)

水利信息服務平臺的設計與實現(xiàn)是一個龐大的系統(tǒng)工程，牽涉的技術(shù)非常多，如基礎組件層的設計、服務對象層的設計，服務聚合層設計、服務管理層設計等。本文重點論述服務對象層、服務管理層和服務聚合層設計等關(guān)鍵技術(shù)。

3.1 服務對象及REST接口設計

服務對象又叫服務實例，主要對服務接口層負責。服務對象的實現(xiàn)是相當?shù)讓拥腉IS操作，如訪問空間數(shù)據(jù)庫、執(zhí)行空間查詢、進行拓撲運算和柵格分析以及制圖可視化等。它們的實現(xiàn)可以依靠開源GIS項目，如GeoTools、GDALOGR、SharpMap等，在這些開源GIS類庫基礎上，通過適當粒度的組合、封裝、擴展，構(gòu)建服務組件。服務接口層依賴服務對象層。表1列出了平臺設計的服務對象及其主要REST接口。

表1 服務實例及其主要REST接口

3.2 池化服務管理

池化服務管理主要提供了對服務實例的管理功能，如啟動、停止、刪除、查詢和目錄等。在服務管理層內(nèi)部需要設計權(quán)限機制與池化服務管理機制。

權(quán)限機制采用基于角色-服務-操作的授權(quán)機制，它的基本元素為用戶、角色、服務以及服務的操作。平臺規(guī)定：一個用戶必須屬于一個或者多個角色，每個角色都授予了可訪問的服務以及它支持的服務接口。基于這種粒度設計的服務安全體系可以顯著提高系統(tǒng)的靈活性，比單純基于角色-服務的安全體系要更強大。

池化機制是水利信息服務平臺核心技術(shù)之一。服務管理層會在內(nèi)部為每個服務提供一個服務池，在該池中會預先創(chuàng)建指定數(shù)目的服務實例。當用戶訪問某個實例時，服務管理器會從該服務對應的池中找到一個空閑的實例返回給REST層，當REST層處理完畢后，會將該實例返回資源池中以重復利用。這種機制顯著提高了系統(tǒng)的性能，并在高并發(fā)用戶訪問情況下具有極大的優(yōu)勢。

3.3 彈性空間信息服務聚合

彈性空間信息服務聚合指動態(tài)對兩個或者多個空間信息服務的疊加、組合，通過對服務實例的彈性調(diào)整，產(chǎn)生新的服務。聚合從實現(xiàn)層面來看，主要有兩種，一種是客戶端聚合，也叫Mashup；另一種是服務器端聚合，稱之為Aggregator。關(guān)于客戶端聚合技術(shù)（Mashup）已經(jīng)有很多文獻加以討論[13]，本文重點分析服務器端聚合?？紤]這樣一種情形，不同行政級別的水利用戶單位可能會搭建各自獨立的水利信息服務平臺，每個平臺托管了本行政級別下水利專題空間信息服務，當用戶想獲取某個服務時，可能該服務在任何級別的平臺中都沒有直接發(fā)布，然而，它卻可以通過對現(xiàn)有多級平臺多類型服務進行適當?shù)木幣?、組合和配置，就能衍生出來。因此不同類型、不同空間范圍的服務聚合是一個平臺必須考慮的問題，也是一個值得深入研究的課題。

為了有效實現(xiàn)彈性服務聚合功能，本文首先將其分拆為三個組成部分：

1）被聚合的服務，也就是具體的服務提供者或者服務處理者；

2）彈性聚合器，提供聚合邏輯，如服務疊加、編排、組合、檢索等；

3）聚合后的服務，新產(chǎn)生的服務，包括它的類型和接口。

圖3所示為筆者設計的服務聚合技術(shù)架構(gòu)，從下向上依次為服務處理器（也叫服務提供者），提供具體的GIS功能服務；服務聚合處理器，實現(xiàn)對多個服務處理器的配置、編排，從而產(chǎn)生新的服務；彈性聚合管理器，集成了監(jiān)控、安全、緩存、規(guī)則引擎、池化等多種技術(shù)，提供聚合服務的彈性管理功能，如日志、彈性調(diào)整、檢索、刪除、啟動、停止等；服務接口層，基于REST或者OGC標準，對聚合后的服務以統(tǒng)一接口標準形式提供。

圖3 彈性服務聚合技術(shù)架構(gòu)

4 結(jié)語

SOA是一種企業(yè)級系統(tǒng)設計的成熟技術(shù)，基于統(tǒng)一的接口標準，能夠有效降低客戶端對服務器的理解，易于實現(xiàn)跨平臺服務互操作以及對原有企業(yè)系統(tǒng)進行整合和信息共享。REST是一種遵循一定原則的軟件架構(gòu)風格，它能顯著降低面向服務系統(tǒng)架構(gòu)設計的復雜性。本文研究了基于REST架構(gòu)風格的水利信息服務平臺設計思路、框架以及關(guān)鍵技術(shù)。隨著云計算技術(shù)推廣應用，必然要求構(gòu)建于云計算平臺上的軟件需要支持云架構(gòu)，所提出的服務彈性調(diào)整方法以及基于多層的REST體系架構(gòu)能夠有效利用云端資源，實現(xiàn)自我彈性調(diào)整，實現(xiàn)真正的Paas(Platform as a service，平臺即服務)。

[1]LI Jianxin, ZHANG Rui. Design and Applicati-on of Software Architecture Based On SOA in the Water Resources Field[C]//Haihe River Water Conservancy Commission, 2009 : 202-211.

[2]馬增輝, 解建倉, 張永進, 等. 基于SOA的水利構(gòu)件研究[J]. 西安理工大學學報, 2008, 24(4): 415-420.

[3]Los Alamitos. Clements PC From Subroutines to Subsystems: Component-based Software Development Component-Based Software Engineering: Selected from the Software Engineering Institude[C] //CA: IEEE Computer Society Press. USA, 1996: 3-6.

[4]Demers F, Malenfant J. Reflection in Logic, Functional and Object-Oriented Programming, A Short Comparative Study[C] //Proceedings of the IJCAI' 95 Workshop on Refl ection and Meta level Architectures and their Applications in AI, Montr' s eal, Canda, 1995: 29-38.

[5]Clemens S, Dominik G, Stephan M. Component-Software:Beyond Object-Oriented Programming[M]. USA: Pearson Education Limited, 2003: 301-320.

[6]林懷恭, 聶瑞華, 羅輝瓊. 基于SOA架構(gòu)的服務集成技術(shù)的研究[J]. 計算機技術(shù)與發(fā)展, 2009, 19(7): 141-143.

[7]毛新生. SOA原理·方法·實踐[M]. 北京: 電子工業(yè)出版社, 2007.

[8]郭文越, 陳虹, 劉萬軍. 基于SOA的數(shù)據(jù)共享與交換平臺[J]. 計算機工程, 2010, 36(19): 280-282.

[9]姚鶴嶺. GIS Web服務研究[M]. 鄭州: 黃河水利出版社,2007.

[10]許卓明, 栗明, 董逸生. 基于RPC和基于REST的web服務交互模型比較分析[J]. 計算機工程, 2003, 29(20): 6-8.

[11]詹騫. 基于AJAX_REST的GIS Web服務研究與實現(xiàn)[D].北京: 中國地質(zhì)大學信息工程學院, 2008.

[12]Roy Thomas Fidding. 架構(gòu)風格與基于網(wǎng)絡的軟件架構(gòu)設計[DB/OL]. http://www.redsaga.com/opendoc/REST_cn.pdf, 2007.

[13]秦靈伶, 王文東, 賈霞. Mashup技術(shù)及其發(fā)展趨勢[J].電信科學, 2009(9): 80-86.