基于开源REST架构的水利信息服务平台关键技术研究

张学宝，白 丹

（西安理工大学 水利水电学院，西安 710048）

目前，我国各水利主管部门在信息化建设中多采用试点分批建设模式，缺乏统一的系统规划、软件架构和技术标准，导致系统后期难以扩展和维护，信息共享和交换困难，系统的孤立性越来越突出。这些问题经过长期的积累，业务系统便成为了一个个“信息孤岛”[1,2]。如何消除系统之间的壁垒，实现水利业务系统的集成、数据交换、信息共享以及辅助决策将变得越来越重要[3-5]。为有效解决这个问题，水利部门需建立一个灵活的、易于扩展和遵循一致系统标准的应用架构。它既可以兼容现有的应用，又能够满足未来新的需求，实现水利业务的高度集成，使得基于不同GIS平台、不同硬件环境、不同语言实现的业务系统都能够很好的进行信息交换，让系统更具弹性，能更快响应业务需求变化[6]。

正是在这种需求之下，SOA（Service-Oriented Architecture，面向服务架构）应运而生。SOA是一种适用于分布式、变化环境的体系架构。它首先将系统功能定义为服务，服务之间通过中立的接口形式进行交互。接口独立于实现细节，便于异构分布式系统基于通用标准进行信息交换，它能够消除信息共享的瓶颈[7,8]。基于SOA架构的水利GIS系统主要针对传统组件式模型以及分布式对象模型（如DCOM、EJB、CORBA等）的不足，将Web上的数据资源和业务功能以数据服务和功能服务的形式加以发布和共享，以实现异构平台互操作。研究发现，基于SOAP、WSDL和WS-*规范的Web服务是实现SOA架构的标准技术，但是，水利信息服务是一种基于GIS技术的空间信息服务，传统基于SOAP协议的 Web服务技术并不能很好地支持水利GIS空间信息服务，它具有如下局限性：

1）SOAP协议栈问题。GIS数据与结构化数据具有很大的不同，比如具有空间参考、空间索引、海量存储等特点，传统的基于协议栈设计并不符合GIS[9]。

2）采用XML-RPC模型。XML-RPC协议比较复杂，客户端和服务器端须严格遵守WSDL接口标准，不满足高内聚、低耦合的设计要求，难以实现Web无缝扩展[10]。

3）基于SOAP的Web服务依赖于接口标准，使得每个SOAP消息必须使用定制的方法原型，需要定义独立的接口，这并不利于服务的互操作[11]。

4）基于SOAP的Web服务采用XML传输空间数据，存在大量数据冗余，不利于网络传输。

考虑到SOA架构技术是消除水利“信息孤岛”的有效途径之一，并且基于SOAP协议的Web服务技术不能有效支持空间信息服务，所以，采用何种架构技术实现面向服务型的水利信息服务平台是一个值得研究的课题。

1 REST架构

REST（Representational State Tran-sfer，表述性状态转移）的提出，为构建水利信息服务平台带来了契机。REST是一个软件架构风格，也是一系列原则组成的Web约束。它以服务器上具有唯一的标识符URI（Uniform Resource Identifier，统一资源描述符）作为出发点，URI的形式代表了资源的访问接口，客户端可以使用HTTP协议的几个标准方法（GET、POST、PUT、DELETE）访问和操作服务器上的资源。基于REST架构风格的Web服务完全根据HTTP、XML、JSON等标准构建，并通过URI操作服务器上的资源，易于实现跨平台、跨语言集成以及支持空间数据表述。REST目前已经成功应用到了Web服务开发和企业信息集成领域。其实，包括IT界巨头Yahoo、Google、Amazon等Web2.0公司都采用了 REST 架构技术，他们都放弃了传统的Web服务技术。Web服务是实现SOA架构的主要方法，然而，基于REST风格的Web服务构建却非常简单，并支持空间数据表述。因此，实现水利信息服务的关键是实现基于REST架构的空间信息服务。目前已经有大量开发框架支持REST开发，如Jersey、WCF REST等。

目前，研究基于REST架构风格的Web服务技术在水利信息服务领域的应用还很少。因此，本文主要探讨基于REST的“轻量级”Web服务技术在水利信息服务平台设计与实现中的应用，设计基于REST架构的水利信息服务平台，并研究该服务平台实现的关键技术。

REST架构原则[12]：

1）为所有资源定义ID。在REST架构中所有服务器资源都必须是可标识的，都应该有一个明确和不同的URI。如：http://www.hydro.com/water/map表示一张水系地图。

2）将所有事物链接起来。REST可以通过链接的形式实现信息导航，例如下面这个XML表述：

基于链接的设计，使得客户端能够通过链接，将应用从一个状态改变为另一个状态，即状态转移。

3）使用HTTP标准方法。服务器上资源的接口可以定义如下：

只要服务器上所有的资源都实现该接口，它们都将支持HTTP标准的几个方法。可以使用get方法检索一个表述，即对资源的描述。

4）资源的多重表述。对同样一个资源可以有多种表述形式，如HTML、JSON、XML、Image等，易于异构平台实现信息共享。

5）无状态。无状态指的是在服务器端不保持客户端的操作状态，比如使用Session保存状态信息，使得客户端不依赖于同一个服务器，这一点非常易于实现集群部署。

2 设计思想

依据REST架构原则以及软件设计方法，设计思路如下：

1）首先，实现各种基础组件，如缓存切片引擎组件、业务模型组件、水文分析组件和GIS引擎组件。其中，GIS引擎借助开源GIS项目，实现对底层基础地理和水利专题数据的访问支持，并提供投影变换、拓扑运算、空间查询、空间分析、数据可视化和地图制图等基本功能。

2）在基础组件之上设计和实现各类服务，如地图服务Map Server、几何服务GeometryServer、要素服务FeatureServer、水文服务HydroServer、缓存切片服务TiledServer、业务服务BusinessServer等。其中，地图服务主要实现地图浏览、空间查询、符号化和制图功能；几何服务主要实现各种几何运算，如几何求交、空间包含等；要素服务主要实现支持OGC SFS规范要素的更新和删除操作；水文服务主要实现等值面、等值线生成等服务；缓存切片服务主要实现地图缓存切片的读取和显示功能；业务服务主要支持业务功能原型。

3）提供这些服务对象的调度、管理、日志、安全和聚合等功能，如设计服务实例管理器，实现对各种服务的统一管理，如创建、启动、停止、删除、检索等。

4）REST服务接口层设计，将第2步中设计的各种服务对象按照REST架构风格进行封装，并以REST接口形式对外提供服务，服务协议遵循HTTP规范，交换信息以JSON、XML、HTML和Image等格式为准。

5）提供多种客户端开发API，如Flex API、Silverligth API和Javascript API等。

2.1 分层体系架构设计

分层是最主要的一种软件设计方法，依此，笔者设计了基于REST架构风格的多层水利信息服务平台，如图1所示。

图1 水利信息服务平台分层体系架构

平台从底向上主要划分了如下几个层次：

1）数据源层主要存储了水利各种空间和非空间数据，如水利基础地理数据、水利专题和业务数据。

2）组件层是平台的核心层，主要实现各类基础组件，如缓存切片引擎、GIS引擎、业务组件模型和水文分析等。

3）服务对象层是核心层的封装，它的粒度往往要大于组件层粒度，提供的接口也更易于使用，接口参数大都设计为支持可序列化操作的对象。该层设计和实现的好坏将大大影响平台的性能、安全和稳定。为了支持高并发用户访问，平台提供的各种服务必须是可池化的，这就要求平台需提供一个支持池化的机制来实现对服务的托管运行，当用户请求经过Web容器调度到达该层时，由服务实例管理器从池中取出一个空闲服务对象处理该请求，请求处理完毕后，自动将该实例返回池中；当池中没有空闲对象时，用户请求线程将会等待，直到有空闲对象或者超时结束。此外，服务对象对外提供的服务必须是经过身份认证的，未经授权的用户是不允许访问服务的。

4）REST服务接口层主要依据一致和简约的标准，以REST的形式对外提供各种服务对象的方法。该层主要为客户端API设计，是客户端程序和平台交互的唯一入口。

2.2 弹性云服务

水利信息服务平台主要面向网络用户提供水利空间信息服务，因此，平台必须支持高并发用户访问和支持高可扩展。以往的平台在支持高并发用户访问时，大都采用集群技术，即通过在两台或者多台物理机器上部署平台的物理拷贝，并通过集群软件或者硬件实现负载均衡和容灾处理，以支持多用户不间断并发访问。这种技术将逐渐被虚拟化技术和云计算技术代替。我们知道，判断云计算技术的一个原则就是是否支持弹性服务，所谓弹性服务就是根据用户请求量能够动态伸缩的服务。云计算平台提供了强大的资源池，这些资源主要以服务形式提供，如CPU、内存、存储和网络资源，但对于一个水利信息服务平台而言，它提供的服务还包括缓存切片服务、水文分析服务、水利专题制图服务、空间信息查询服务等。

为了使得水利信息服务平台支持弹性云计算，其必须具有自我感知能力，这也是一种自我诊断的能力。当大量用户访问水利信息服务时，它会触发系统预先设定的各种规则，进而，平台会自动调用云操作系统Cloud API创建预先安装该软件的虚拟机，并自动构建整个集群环境，整个过程不需要人的任何干预。图2显示了支持弹性云服务的技术架构，在这个云环境中，控制服务器提供了云操作API，如创建、启动、停止、删除虚拟机等。图2假定了在每台物理服务器中部署了4个虚拟机，每个虚拟机托管运行1个水利信息服务平台，平台通过服务监控模块实现对各种服务的监控和记录，当客户请求达到预先设定的规则时，监控引擎将自动执行预先装载的规则，调用云操作系统API，以实现对虚拟机的管理。整个过程演示了水利信息服务平台的自我弹性伸缩管理。

图2 弹性云服务技术架构

3 平台关键技术

水利信息服务平台的设计与实现是一个庞大的系统工程，牵涉的技术非常多，如基础组件层的设计、服务对象层的设计，服务聚合层设计、服务管理层设计等。本文重点论述服务对象层、服务管理层和服务聚合层设计等关键技术。

3.1 服务对象及REST接口设计

服务对象又叫服务实例，主要对服务接口层负责。服务对象的实现是相当底层的GIS操作，如访问空间数据库、执行空间查询、进行拓扑运算和栅格分析以及制图可视化等。它们的实现可以依靠开源GIS项目，如GeoTools、GDALOGR、SharpMap等，在这些开源GIS类库基础上，通过适当粒度的组合、封装、扩展，构建服务组件。服务接口层依赖服务对象层。表1列出了平台设计的服务对象及其主要REST接口。

表1 服务实例及其主要REST接口

3.2 池化服务管理

池化服务管理主要提供了对服务实例的管理功能，如启动、停止、删除、查询和目录等。在服务管理层内部需要设计权限机制与池化服务管理机制。

权限机制采用基于角色-服务-操作的授权机制，它的基本元素为用户、角色、服务以及服务的操作。平台规定：一个用户必须属于一个或者多个角色，每个角色都授予了可访问的服务以及它支持的服务接口。基于这种粒度设计的服务安全体系可以显著提高系统的灵活性，比单纯基于角色-服务的安全体系要更强大。

池化机制是水利信息服务平台核心技术之一。服务管理层会在内部为每个服务提供一个服务池，在该池中会预先创建指定数目的服务实例。当用户访问某个实例时，服务管理器会从该服务对应的池中找到一个空闲的实例返回给REST层，当REST层处理完毕后，会将该实例返回资源池中以重复利用。这种机制显著提高了系统的性能，并在高并发用户访问情况下具有极大的优势。

3.3 弹性空间信息服务聚合

弹性空间信息服务聚合指动态对两个或者多个空间信息服务的叠加、组合，通过对服务实例的弹性调整，产生新的服务。聚合从实现层面来看，主要有两种，一种是客户端聚合，也叫Mashup；另一种是服务器端聚合，称之为Aggregator。关于客户端聚合技术（Mashup）已经有很多文献加以讨论[13]，本文重点分析服务器端聚合。考虑这样一种情形，不同行政级别的水利用户单位可能会搭建各自独立的水利信息服务平台，每个平台托管了本行政级别下水利专题空间信息服务，当用户想获取某个服务时，可能该服务在任何级别的平台中都没有直接发布，然而，它却可以通过对现有多级平台多类型服务进行适当的编排、组合和配置，就能衍生出来。因此不同类型、不同空间范围的服务聚合是一个平台必须考虑的问题，也是一个值得深入研究的课题。

为了有效实现弹性服务聚合功能，本文首先将其分拆为三个组成部分：

1）被聚合的服务，也就是具体的服务提供者或者服务处理者；

2）弹性聚合器，提供聚合逻辑，如服务叠加、编排、组合、检索等；

3）聚合后的服务，新产生的服务，包括它的类型和接口。

图3所示为笔者设计的服务聚合技术架构，从下向上依次为服务处理器（也叫服务提供者），提供具体的GIS功能服务；服务聚合处理器，实现对多个服务处理器的配置、编排，从而产生新的服务；弹性聚合管理器，集成了监控、安全、缓存、规则引擎、池化等多种技术，提供聚合服务的弹性管理功能，如日志、弹性调整、检索、删除、启动、停止等；服务接口层，基于REST或者OGC标准，对聚合后的服务以统一接口标准形式提供。

图3 弹性服务聚合技术架构

4 结语

SOA是一种企业级系统设计的成熟技术，基于统一的接口标准，能够有效降低客户端对服务器的理解，易于实现跨平台服务互操作以及对原有企业系统进行整合和信息共享。REST是一种遵循一定原则的软件架构风格，它能显著降低面向服务系统架构设计的复杂性。本文研究了基于REST架构风格的水利信息服务平台设计思路、框架以及关键技术。随着云计算技术推广应用，必然要求构建于云计算平台上的软件需要支持云架构，所提出的服务弹性调整方法以及基于多层的REST体系架构能够有效利用云端资源，实现自我弹性调整，实现真正的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的水利构件研究[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架构的服务集成技术的研究[J]. 计算机技术与发展, 2009, 19(7): 141-143.

[7]毛新生. SOA原理·方法·实践[M]. 北京: 电子工业出版社, 2007.

[8]郭文越, 陈虹, 刘万军. 基于SOA的数据共享与交换平台[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服务研究与实现[D].北京: 中国地质大学信息工程学院, 2008.

[12]Roy Thomas Fidding. 架构风格与基于网络的软件架构设计[DB/OL]. http://www.redsaga.com/opendoc/REST_cn.pdf, 2007.

[13]秦灵伶, 王文东, 贾霞. Mashup技术及其发展趋势[J].电信科学, 2009(9): 80-86.