对于复杂的自然现象，单个模型已难以概括其物理机制^[1]。地学模型集成为研究地理系统中的复杂和跨学科问题提供了一条新途径。不同领域和框架下的地学模型在框架、系统、语法等方面存在很强的异构性，集成时面临着兼容性差等突出问题。随着网络和网络信息基础设施在地学研究中的推广应用，支持网络环境的地学模型集成亟待研究^[2]，并衍生出“模型网”的概念^[3]，即将网络作为模型集成交互的环境，实现“模型即服务”的理念。

在地学领域，地学模型可以概括为模拟、分析、评价和预测地学现象和过程的数量化方法。基于时间步长的地学模型模拟是随时间变化的地学现象，运行时执行多次。比如，流域径流模型在模拟流域出水口一年内每天的流量时，会以天为时间步长执行365次。此类模型在集成时，将涉及运行时交换数据，比如计算每天的出水量，就需要当天的降水、下渗等数据，这对模型的在线共享和集成提出了新的挑战。

基于组件和服务的模型集成方法是当今研究的热点。模型组件是采用面向对象方法，将模型按照特定的接口规范进行封装，得到可独立运行的功能单元，以实现模型的共享、重用和集成；基于组件的模型集成支持模型间基于时间步长的交互等复杂过程。国际万维网联盟W3C将网络服务定义为一个软件系统，用于支持网络中不同机器之间的互操作。网络服务具有封装性好、互操作性和可集成性高、松散耦合等特点^[4-5]；面向服务的模型集成是将模型的访问接口按照标准网络服务进行表达，通过服务链进行模型集成^{[3, 6]}；基于服务的模型集成为跨平台和异构环境的模型共享和互操作提供了应用前景^[7]。

目前, 模型的访问接口存在组件和服务并存的情况，例如在环境建模领域，基于组件的模型应用较为广泛；而在地理信息领域，则试图通过网络服务对环境模型进行封装，提供在线服务。本文提出的组件与服务耦合的地学模型集成方法，兼容不同接口协议的地学模型，实现跨协议的模型集成。将原型系统扩展为开源地学模型集成工具(GeoJModelBuilder)，并应用于具体案例中，以验证方法的可行性。

1 模型集成方法与技术

在概念上，模型集成可分为结构集成和过程集成^[8]。结构集成是合并两个或两个以上的模型, 得到一个采用同样表达方式的新模型，模型之间深度耦合；过程集成是将模型按顺序组织并指定交互参数，模型之间具有很好的独立性。基于组件和服务的模型集成方法大多采用过程集成方式。科学工作流为过程集成提供了方法支持，可用于地学模型的集成中^[9]。

1.1   基于组件技术的模型集成

基于组件方法的模型框架有地球系统模型框架^[10] (earth system modeling framework，ESMF)、开放建模接口^[11-12] (open modelling interface，OpenMI)以及适用于大规模科学领域的公共组件架构规范^[13](common component architecture，CCA)等。其中，OpenMI定义了模型间数据传递的标准，允许模型在运行时基于时间步长，采用“拉”的机制交换数据^[11]，受到了广泛关注^[2]。

ILinkableComponent和ILink是OpenMI中的两个核心接口，前者定义模型和模型支持的交换项等，创建符合OpenMI标准的模型，只需继承该接口即可；后者用于关联模型，并指定关联的输入项和输出项。模型初始化时，传入的参数可以是简单数值或文件路径，也可以是其他功能单元处理后的数据，比如空间信息处理服务返回的结果。模型运行时通过ILink接口请求某一时间某位置的数据，实现基于时间步长的运行。

与服务相比，组件的共享性差，运行时需依赖于特定的平台/环境。基于组件方法的模型集成往往借助于模型框架，比如OpenMI模型在集成时需使用OpenMI的开发工具包。不同模型框架的组件集成仍需要一定的额外工作，比如OpenMI模型需通过网络服务与ESMF模型集成^[7]。

1.2   面向服务的模型集成

“模型即服务”可极大提高模型的共享性和互操作性，用户只需了解服务接口，开发人员可根据实际需要自由选择模型框架、内部算法、开发语言、运行平台等。面向服务的模型集成是一种松散耦合的模型集成方法。

开放地理空间信息联盟(Open Geospatial Consortium，OGC)是地球空间信息领域主要的国际标准化组织，基于HTTP协议制定了一系列标准规范用于促进空间信息服务的互操作，比如空间信息处理服务(web processing service，WPS)以标准化的方式在网络上共享空间信息处理功能。地学模型可发布为遵循WPS规范的在线服务^[3]，用于模型集成。随着传感器的广泛应用，观测数据已成为地学模型的重要数据源。OGC传感网实现(sensor web enablement, SWE)定义了一系列标准用于规范传感网中的信息模型和服务接口^[14]。其中，传感器观测服务(sensor observation service, SOS)用于获取传感器的观测数据和传感器的系统描述。

面向服务的模型集成主要面临两大难点：大数据网络传输效率低和许多地学模型间需要动态复杂的交互^[2]。基于HTTP协议的OGC WPS是无状态服务，虽然可以支持普通地学模型的网络共享和互操作，但用于发布和集成基于时间步长的地学模型时仍存在一定的局限性, 即无法维护模型状态信息，且频繁地建立连接会浪费带宽资源。

1.3   基于科学工作流技术的模型集成方法及工具

科学工作流技术是进行复杂科学计算时的一种有效的流程管理手段，具有数据集成、计算集成、分析集成等特点^[15]。科学工作流用来组合不同功能单元(如应用程序、组件、服务等)，并控制各功能单元间的数据依赖关系。流程组合方式可分为基于文本、图形以及语义的组合^[15]。基于文本的组合需用户直接对文本进行编辑；基于语义的流程组合是使用本体描述语言对组件和数据等进行语义描述，采用智能规划和智能推理技术进行流程构建^[16-17]；基于图形的组合支持拖拽工作流组件，并采用可视化的方式构建依赖关系，是目前应用最为广泛的一种流程组合方式，如Kepler^[18]、VisTrails^[19]、GeoJModelBuilder^[20]等工具。

现有的一些开放科学工作流工具如Kepler、VisTrails等面向通用领域，并非完全适用于地学应用。ArcGIS ModelBuilder和ERDAS IMAGINE Spatial Modeler是传统的空间信息处理建模工具，聚焦于各自平台算子的组合建模，无法集成网络环境下分散的空间信息资源和其他框架下的地学模型。OpenMI Configuration Editor专门用于集成符合OpenMI规范的组件模型，尚不支持普通的空间信息处理算法，无法发挥空间信息系统在数据分析处理方面强大的优势。GeoJModelBuilder是面向地学领域开源的空间信息处理建模工具，本文通过扩展该工具实现了一款基于科学工作流和基于组件与服务耦合的地学模型集成原型系统。

2 组件与服务耦合的地学模型集成方法与技术

本文采用的组件与服务耦合的地学模型集成方法与技术包括：基于WebSocket协议的地学模型发布与共享；科学工作流采用两层设计，屏蔽物理实现的不同，逻辑上保持一致；引入中间件技术，实现服务与组件之间的数据交互。

2.1   基于WebSocket的地学模型发布与共享

WebSocket协议构建于TCP协议之上，通过一次连接，客户端和服务器即可实现全双工通信，相对于HTTP协议有效提高了网络通信效率，客户端不再需要多次发出连接请求，建立了真正意义上的长连接。

OpenMI是应用较为广泛的组件模型框架，特别是在水文领域。本文介绍一种基于WebSocket发布OpenMI组件的方法(见图 1)，用于提高地学模型的共享性。OpenMI模型在执行时可分为3个阶段：初始化阶段、运行阶段和完成阶段^[8]。当组件载入内存后，进行初始化，包括数据预处理及确定输入输出项等；在运行阶段，模型基于时间步长完成模拟/计算；完成阶段用来结束模型运行，释放资源。

图  1  基于WebSocket协议发布OpenMI组件

Figure  1.  Publish OpenMI-Compliant Component as Service Using WebSocket Protocol

下载: 全尺寸图片 幻灯片

WebSocket API支持通过事件触发的形式调用服务器端：当连接创建时, “打开连接”方法被触发，初始化OpenMI组件，初始化参数通过键值对形式由客户端传入；当客户端向服务器请求特定时间、特定位置、特定类型的数据时，“收到消息”方法会被触发，驱动OpenMI组件基于时间歩长运行; 连接关闭时调用OpenMI的结束接口。

2.2   科学工作流的两层设计

科学计算流程抽象为形式化描述的过程，由子过程和活动组成(见图 2)。活动是过程执行中的功能单元(如服务和组件)，被抽象为“输入-处理-输出”形式。活动之间通过数据流关联，数据流中不仅记录了活动之间的数据交换，而且隐含了活动的执行顺序，比如活动A和活动B之间的数据流“AO₁#BI₁”指明活动A的输出O₁作为活动B的输入I₁，同时隐含地说明了执行顺序是由A到B。为实现多层抽象和支持多实例，与过程和活动抽象概念相对应，科学工作流中引入了过程实例和活动实例。过程与过程实例以及活动与活动实例都是一对多关系，活动实例与具体的功能单元为一对一关系(见图 2)。空间信息服务和OpenMI模型都是科学工作流中的具体功能单元。抽象与实例分离具有逻辑一致、物理分隔、易于共享和复用、执行前动态绑定(动态适应)、方便评估不同活动对流程的影响等优势。

图  2  科学工作流设计：抽象层和实例层

Figure  2.  Scientific Workflow Design: Abstract Layer and Concrete Layer

下载: 全尺寸图片 幻灯片

2.3   基于中间件的组件与服务集成

OGC WPS服务一般采用编制方式组合，服务间相互独立，由执行引擎控制流程顺序和数据交互。OpenMI组件之间的协作方式类似编排，模型间主动“拉”取数据，无需集中控制。OGC WPS服务与OpenMI组件之间以及WebSocket模型服务与OpenMI组件之间无法直接集成，本文根据服务与组件之间数据传递方式的不同，采用两种不同的中间件策略。

OpenMI中的参数可以分为两种类型：运行时参数和初始化参数。空间信息处理服务可以对数据进行预处理，然后将结果作为初始化参数传入组件^[20]。通常情况下空间信息处理服务的输入输出是数据的网络地址，本文提出由中间件负责数据的上传和下载，以解决服务与组件集成中数据存在形式上的不同(网络或本地)。如图 3(a)所示，OGC WPS服务与OpenMI组件耦合时, 执行引擎首先执行流程中的处理服务，然后将结果下载到本地作为初始化参数传入OpenMI组件。WebSocket地学模型服务与组件集成时，同样需要引入中间件技术。中间件继承ILinkableComponent接口，是一个符合OpenMI规范的模型组件，负责与WebSocket地学模型服务交互。图 3(b)是中间件与其他符合OpenMI规范的组件数据交互时序图。中间件负责将OpenMI接口转换为WebSocket服务请求，并将解析响应结果返回给其他组件, 实现了WebSocket地学模型服务与OpenMI组件的集成。

图  3  基于中间件的组件与服务交互时序图

Figure  3.  Calling Sequence Between Services and OpenMI-Compliant Component Based on Middleware

下载: 全尺寸图片 幻灯片

本文在两个方面对GeoJModelBuilder进行扩展，实现了OGC WPS、基于WebSocket的地学模型服务和OpenMI组件的集成, 具体做法为：为科学工作流添加抽象层，实现逻辑一致、物理分割；开发中间件，支持基于WebSocket的地学模型服务。科学工作流分为抽象层和实例层，将具体的物理实现(空间信息处理服务、本地算法、地学模型等)与业务逻辑分开。抽象层记录解决复杂问题需要的科学流程，包括处理步骤以及各个步骤之间的关联关系；实例层记录抽象步骤与具体功能单元的映射关系。

3 应用案例与实验评估

通过选取基于TOPMODEL模型(topgraphy based hydrological model)^[21]的流域降雨径流模拟案例，验证基于组件与服务耦合的地学模型集成方法，演示基于时间步长的地学模型集成。TOPMODEL模型用地形指数、降水量、蒸发量等数据模拟流域降水径流量。地形指数计算由空间信息处理服务提供，该服务由GRASS GIS中的r.topindex功能实现；Hargreaves模型使用温度值计算蒸发量^[22]，它是OpenMI组件；TOPMODEL模型为WebSocket服务。本案例的实验区域、温度值和降水量等数据来自水文信息系统HydroDesktop平台提供的样例。图 4模拟了2008年的流域降雨径流流程(时间歩长为1 d)。扩展后的GeoJModelBuilder基于标准接口集成OpenMI组件、空间信息处理服务、WebSocket模型服务，充分发挥基于服务和基于组件这两种模型集成方法的各自优势。

图  4  流域降雨径流模拟数据和结果

Figure  4.  Input and Output of Watershed Runoff Simulation Based on TOPMODEL

下载: 全尺寸图片 幻灯片

本文对基于TOPMODEL水文模型的流域降雨径流模拟案例进行评估，对比分析WebSocket协议和HTTP协议在发布地学模型方面的优劣，以及随着地学模型单步执行时间的增加，网络传输对总体执行时间的影响。

实验环境：客户端的硬件配置为Intel(R) Core(TM) i7-4790M CPU 3.60 GHz, 8.00 GB RAM；服务器的配置为Intel(R) Xeon(R) CPU E5-2692 v2@2.20 GHz, 32 GB RAM；带宽为10.0 Mbps。在该案例中，温度值和降水量是以天为单位的观测数据，地形指数计算服务只执行一次，Hargreaves模型和TOPMODEL模型根据模拟的起始时间、结束时间和步长决定模拟的次数。例如，如果起始时间为2006年6月2日，结束时间为2007年3月28日，时间步长为1 d，则Hargreaves模型和TOPMODEL模型基于时间步长各执行300次，并存在300次的数据交互。

图 5(a)为分别使用HTTP协议和WebSocket协议实现TOPMODEL模型时，不同交互次数所对应的模型执行时间。可以看出，在多次交互的情况下，WebSocket地学模型的执行效率要优于HTTP协议, 随着交互次数的增加，WebSocket协议的优势越明显, 验证了在发布基于时间步长的地学模型时，WebSocket协议比HTTP协议更具优势。

图  5  基于WebSocket协议的地学模型评估

Figure  5.  Evaluation of Model Service Based on WebSocket Protocol

下载: 全尺寸图片 幻灯片

为评估网络传输对模型执行时间的影响，引入WebSocket模型服务与OpenMI模型组件执行时间的比值，该比值的大小取决于数据的网络传输时间和模型实际执行时间，比值越大, 代表网络传输消耗对总体性能的影响越大。为评估当模型计算量增大时，网络传输对整体运行性能的影响，本文模拟TOPMODEL模型单步计算时间来进行实验。在实验中，交互次数为500次，使用模型单步执行的平均时间来代表模型的计算量。如图 5(b)，在网络带宽一定的情况下，随着计算量的增大(单步执行时间变长)，比值逐渐趋近于1.00，说明WebSocket地学模型和OpenMI组件模型的执行时间越来越接近，也就是说网络传输对总时间的影响越来越低。

4 结语

本文提出了基于科学工作流的组件与服务耦合的地学模型集成方法，并在原型系统中验证了该方法的可行性。将OpenMI组件发布为WebSocket模型服务，实现了顾及地学模型执行特点、模型集成需求的在线共享；科学工作流采用两层设计，即抽象层和实例层，实现了逻辑一致、物理分隔。抽象层与实例层之间是一对多关系，支持科学工作流在执行前将抽象模型与具体实例自定义映射。通过引入中间件技术，实现了服务与组件之间的数据交互。

随着网络基础设施和新技术的发展，完全面向网络环境的地学模型集成将会受到更多关注，下一步研究将基于WebSocket协议，完全面向网络环境的复杂地学模型集成问题。在原型系统方面，由于GeoJModelBuilder支持的组件类型局限于OpenMI，尚不支持其他框架，后续将在GeoJModelBuilder基础上，研究如何基于XML和具有黏合功能的脚本语言，集成更多不同框架或者不同平台下的地学算法与模型。