Prototyping an open environment for sharing geographical analysis models on cloud computing platform

Abstract

The sharing of geographical analysis models is of crucial importance for simulating geographic processes and phenomena in the current geographical information systems (e.g. Digital Earth), but there remain some issues that have not been completely resolved. The challenges include, eliminating model heterogeneity and searching for suitable infrastructures to support the open sharing and effective execution of models. Taking advantage of cloud computing, this article aims to address the above issues and develop an open environment for geographical analysis model sharing. On the basis of the analysis of the applicability of cloud computing, the architecture of the open environment is proposed. More importantly, key strategies designed for heterogeneous model description, model encapsulating as well as model deploying and transparent accessing in the cloud are discussed in detail to establish such an environment. Finally, the prototype environment is implemented, and experiments were conducted to verify the environment's feasibility to support the sharing of geographical analysis models.

Keywords:

• geographical analysis models
• cloud computing
• open environment

1. Introduction

Solving comprehensive geographic problems (e.g. multi-scale problems, regional correlation problems) often requires the reuse or the integration of multi-disciplinary geographical model resources (Maguire et al. 2005). In such terms, current geographical information systems (e.g. Digital Earth and the Virtual Geographical Environment) have increased their focus on geographic analysis model base building, which provides a new possibility of model sharing and reuse (Crosier et al. 2003, Craglia et al. 2008, Yang et al. 2008, Lin et al. 2009, Lü 2011). The challenge is that although many excellent models have been built, without effective model sharing strategies, these models often work in isolation and cannot communicate with other models and disciplines. Users from different domains have difficulty in sharing their modelling ideas and therefore cannot conduct collaborative work to solve interdisciplinary problems. In addition to the self-characteristics of geographical analysis models, such as heterogeneity (including structural heterogeneity, data heterogeneity and execution environment heterogeneity), dispersion and privacy, other factors, including the lack of an infrastructure with extensive adaptability and relevant service strategies, have greatly affected the prediction capacity of modern geographical simulation (Goodchild et al. 1993, Ungerer and Goodchild 2002, Argent 2004, Yang et al. 2010). In this case, designing suitable strategies and frameworks for geographic analysis model sharing is undoubtedly becoming one of the inevitable requirements for current geographic research (Nativi et al. 2012).

Research on geographical analysis model sharing can be traced back to the development of spatial decision support systems when geographical model bases were first constructed (Muhanna 1993, Bennett 1997, Ascough et al. 2002). Although some disciplinary models are successfully integrated into these systems for geographic problem analysis and solving, such as sustainable management of land and water ecosystems (Rizzoli and Young 1997, Oxley et al. 2004, Matthies et al. 2007), they have generally been run on standalone computers or in closed networks and cannot be shared and integrated for multi-disciplinary simulations (Goodchild 2005).

More recently, different modelling and reuse frameworks have been developed to tackle the environmental problems (Morozov et al. 2006, Argent et al. 2006), including the Spatial Modelling Environment (SME) (Maxwell and Costanza 1997a, 1997b), the Interactive Component Modelling System (ICMS) (Reed et al. 1999), the Dynamic Information Architecture System (DIAS) (Campbell and Hummel 1998, Simunich et al. 2002), the Modular Modelling System (MMS) (Leavesley et al. 1996, Leavesley et al. 2002), ModCom (Hillyer et al. 2003), Tarsier (Watson and Rahman 2004), the Community Surface Dynamic Modelling System (CSDMS) (CSDMS Working Group 2004), the Earth System Modelling Framework (ESMF) (Hill et al. 2004), the Object Modelling System (OMS) (Ahuja et al. 2005), the Open Modelling Interface (OpenMI) (Blind and Gregersen 2005, Moore and Tindall 2005), the European Union's Program for Integrated Earth System Modelling (PRISM) (Valcke et al. 2006), the SEAMLESS-IF(Van Ittersum et al. 2008) and CAPRI (Britz et al. 2010). Although these frameworks are developed with valuable functionality, most of them are highly field-related and platform-related, which limits the breadth of application and increases the entry barriers of these systems (Nativi et al. 2012). On the other hand, few of these frameworks support model sharing and integration over the Internet (Feng et al. 2011).

To share model resources as worldwide services, further solutions have been proposed based on Service-oriented architectures (SOA) (Tsou and Buttenfield 2003, Granell et al. 2010). It is said that there are at least two advantages in using SOA-based model sharing (Feng et al. 2011): one is that SOA can integrate data and models from anywhere in the world (Diaz et al. 2008) and the other one is that SOA-based model sharing can apply to various popular applications (Grimshaw et al. 2009). To make full use of SOA, the Open Geospatial Consortium and the Technical Committee 211 of the International Standards Organization (ISO/TC211) have established a series of specifications and standards for geographical information sharing Open GIS Consortium (OGC 2004, 2008). In addition, several researchers have investigated model sharing based on Simple Object Access Protocol and Web Services Description Language (SOAP/WSDL) (Fook et al. 2009), Web Processing Service (WPS) specifications (Feng et al. 2009, Feng et al. 2011) and ‘Model Web’, proposed by Geller and Turner (2007), Geller and Melton (2008) and Geller (2010). However, even with SOA, the efficiency of model resources sharing and the extensibility of model interoperability need to be further improved and related specifications still lack necessary constraints on the model data, the running behaviour and the life cycle.

In the IT domain, the demand for transparent use of computing and software resources has been promoting the development of the IT infrastructure. Cloud computing, which has developed rapidly in recent years, facilitates service-oriented resource sharing in a single large step. Compared with SOA, cloud computing is focused on realising Infrastructure as Service (IaaS) in the infrastructure layer, providing Platform as Service (PaaS) in the application infrastructure layer and user only pays attention to Software as Service (SaaS) in the application layer (Ahrens 2010, Armbrust 2010). All these improved features will create important opportunities for the services of geographical analysis model sharing (Yang et al. 2010, 2011).

In this article, we propose an open environment for the sharing of geographical analysis models based on the cloud computing architecture. With this environment, model owners can submit models more conveniently and model users can access the submitted models transparently and conduct further execution using computing resources provided by the cloud computing service. The remainder of the article is structured as follows: based on the analysis of the problems encountered in geographical analysis model sharing and the usability of cloud computing architecture, Section 2 proposes the architecture of the open environment for geographical analysis model sharing. In Section 3, a flexible strategy for describing heterogeneous models is introduced. On the basis of an analysis of the model execution service mode in the cloud, an encapsulation strategy for models is described in Section 4 and cloud deployment and service interaction strategies are described in Section 5. Section 6 introduces the realisation of the prototype system and related experiments. Finally, conclusions and discussions of the system's limitations are presented in Section 7.

2. Design of the architecture

2.1. Problems in geographical analysis model sharing

Generally, geographical analysis models can be represented as mathematical models and implemented as executable programmes with specific parameters and runtime platform requirements. Today, the main reasons for the current difficulty in geographical analysis model sharing can be summarised in the following points:

1.	Heterogeneity of model resources: Geographical analysis models vary greatly in modelling method, scale, data organisation and data structure; therefore, it is difficult to adopt fixed description models to represent these geographical analysis models. Moreover, the realisation of these models depends on the diverse hardware architectures, the software platforms and the programming languages, resulting in heterogeneity at the software level (Chen et al. 2009a). Due to the heterogeneity of model resources, it is difficult to share them as unified services.
2.	Dispersion of model resources: Although a large number of geographical models have been developed, they are often dispersed across different institutions or among different researchers. How to collect distributed models for open sharing (OS) is another problem.
3.	Intensive demand for computing resources: Model execution often involves mass geographical data processing and running of complex equations and long-sequence simulations, which requires a large amount of computing resources (NRC 2010). To support effective and distributed execution of the shared model, architecture with powerful computing resources is urgently needed.

2.2. Applicability of cloud computing in supporting the sharing of geographical analysis models

Cloud computing is the integration of several advanced IT and ideas, including supercomputing technology, network communication technology, virtualisation technology and SOA. Simultaneously, cloud computing has also established a clear business model and won support from many enterprises, governments and academic communities (Buyya et al. 2008). The current providers of cloud services include Amazon EC2 (http://aws.amazon.com/ec2), Google Docs (http://docs.google.com), Apple iCloud (http://www.apple.com/icloud) and Windows Azure (http://www.microsoft.com/windowsazure). In reference to the five characteristics of cloud computing (The Higher ED CIO 2011), several points can be summarised to indicate that cloud computing can effectively support the construction of an open environment for the sharing of heterogeneous geographical analysis models.

1.	Transparency and openness. The adoption of stratified service mechanisms (e.g. IaaS, PaaS and SaaS) renders cloud computing transparent and open, which will provide the opportunity for model providers and users to focus on their own business at the application level, rather than on how to deploy or execute models.
2.	Extensible service. With a huge pool of available computing resources and its extensible architecture, cloud computing is capable of providing sufficient computing resources for the solution of computer-intensive geographical problems.
3.	Adaptability based on virtualisation technology. Virtualisation technology enables cloud computing service providers to offer the required runtime environment dynamically (including specific hardware architecture, operating systems and runtime environments) for heterogeneous geographical model execution.
4.	Alternative services. Because enterprises, scientific research institutions and government agencies have increasingly participated in cloud computing, users may freely and alternatively choose service providers based on their needs in the future.

2.3. Architecture of the open environment

Based on the above analyses, we designed an open environment that supports the sharing of both models and computing resources, making use of cloud computing. Its architecture is presented in Figure 1, including two basic platforms: the Open Sharing Platform for Geographical Models (OSP4GM) and the Cloud Computing Platform for Geographical Models (CCP4GM).

Figure 1.  Architecture of the open environment for the sharing of heterogeneous geographical models based on cloud computing.

OSP4GM is the basic platform for model sharing and consists of a set of resource libraries, services and interfaces with the functions of model and computer resource management, model deployment management and model execution management. CCP4GM is responsible for providing computing resources with functions including model execution container creation, model deployment and model execution.

There are also two kinds of actors in this environment. The model providers are responsible for providing the model resources; they can encapsulate heterogeneous models using relevant tools to form standardised model component packages. Moreover, models can be updated or deleted via OSP4GM. After they submit the models, the model users can search and invoke model services via OSP4GM. The requested models are then executed on CCP4GM.

To make full use of the features of cloud computing as well as realise this architecture, several key strategies should be designed. First, to reduce the heterogeneity of models and clearly express the model data and the runtime behaviours, a flexible strategy for the model description is necessary. Second, the strategy for heterogeneous geographical model encapsulation equips models with standardised interfaces; it will contribute to forming model components in the cloud environment and enable modes to be transparently accessed. Third, the cloud deployment and interaction strategy benefits the model execution using virtualisation technology; it will realise the computer resource sharing in the cloud environment. A detailed discussion of the design of these strategies is presented in the next three sections.

3. Description strategy for geographical analysis models

Geographical analysis models are the abstractions of geographical information and geographical processes. The data retrieval and processing steps require knowledge of specific domains. Moreover, when a comprehensive problem is analysed, several geographical models must be integrated and implemented collaboratively. In this case, a flexible description mechanism related to the model data and the execution behaviour will create a foundation for model information exchange and component interface design, further to contribute to model reuse and sharing.

3.1. Data description strategy

Due to the complexity of geographical problems and the diversity of modelling methods, different models have their own data requirements, which involve different contents and can be represented as different data models and formats. It is difficult to design a fixed data model to organise all of the geographical model data (Argent 2004).

To solve this problem, a flexible data description and exchange schema would greatly contribute to the description ability for heterogeneous models (Chen et al. 2011). The target of designing such a schema is not to provide a fixed description about the model data requirement or to focus on building a unified library for model contents (e.g. semantic library), but to provide an open description mechanism to help model providers express and exchange model information in a structured and explicit way. In this way, the data structure can be well defined first. Then, by importing of the shared semantic library or the knowledge base, related tags can be attached to the data structure visually and conveniently, and finally, the model-related data can be expressed with exact meanings.

Referenced by former studies in this aspect, which have generally employed XML and its extension language as the basic description language (Adams 2009, Athanasis et al. 2009), the UDXDL (Universal Data eXchange Definition Language) is proposed in this article. The difference is that we have designed a data representation model as its core concept. The data representation model was first proposed in the Source for Environmental Data Representation & Interchange technologies (SEDRIS technologies) (http://www.sedris.org/), and later studied primarily in the simulation field (Macchi and Sims 2002, Bhatt et al. 2004, Campos and Hull 2004, Bhatt et al. 2005), rather than the geographic modelling field (Chen et al. 2009b). In this case, we designed our data representation model for geographic model data description, which titled the UDX model written in XML to form UDXDL. The UDX model consists of two parts: the UDX object model, which is used to express the data structure and the semantically enhanced schema, which is used to attach UDX objects with semantics. With the UDX model, geographical model data containing semantics and constraints can be expressed through combinations and iterations of different basic elements of the two parts.

3.1.1. UDX object model

Generally, geographical data are organised based on several rules. (1) Simple variables and variable sets are the most common basic elements. (2) A hierarchical structure and a two-dimensional table structure are the most general forms of data organisation. Moreover, the relational model, which is essentially organised based on a two-dimensional table, has been demonstrated to enable the expression of complex data relationships (Rafanelli 2003). (3) Naming is the simplest way to distinguish data contents. The names of data items, data tables and data structures contain certain intelligible information. (4) The meaning of a data structure generally relies on its explanation. For example, a point sequence can be viewed as a LineString or a Ring. With additional triangle information, a point sequence can also represent the nodes in a Triangulated Irregular Network (TIN). Based on the above analysis, a UDX object model was designed. Its Unified Modeling Language (UML) class diagram is shown in Figure 2.

Figure 2.  UML class diagram of the UDX object model.

The UDX object model includes two types of basic construction elements: the nodes and the kernel. Each node has a name, a kernel, and 0 to n child nodes. The kernel dictates each node's behaviour, its contained data and its type. The kernel subclasses include the value kernel, the array kernel and the container behaviour-type kernel.

The template types for the value kernel and the array kernel are entitled KnValueT and KnArrayT. KnValueT is used to store simple value data types, whereas KnArrayT stores arrays of simple value data types. The simple value types that can be stored in KnValueT include Int, Float, String and Vector (such as Vector2D, Vector3D and Vector4D, which are designed specifically for spatial data). When the kernel of a specific node is a value kernel or an array kernel, this node cannot have any child nodes.

When a node contains the container behaviour-type kernel, it does not store data; instead, the enumeration types of a container behaviour-type kernel indicate the types of its child nodes, which include Structure, List, KeyValue and Table, and can be described as follows. (1) Structure: The kernel-subordinated node is structurally similar to the type of the programming language; this type of node may contain child nodes with any kernel. (2) List: The child nodes of the kernel-subordinated node have the same node hierarchy. (3) KeyValue: The kernel-subordinated node has two array-type child nodes of the same length, and the two corresponding array elements form key-value mappings. The first array element indicates the keys and the second indicates the values. (4) Table: The kernel-subordinated node has several child nodes, which are array-type nodes with the same number of elements. All child nodes constitute a two-dimensional table with the elements at the same positions forming the rows of the table.

Examples of a data representation using the UDX object model are shown in Figure 3. Figure 3(a) shows a TIN. The Points child node indicates that the Vector2D array is used to express all of the point sequences; the Triangles child node indicates that the sequence of triangles is composed of points, and the array elements are used to represent the index of vertex. Figure 3(b) demonstrates a polygon. The Patches child node indicates the ring structures of polygons, and the value of each array element is used to represent the number of points contained in each ring. Figure 3(c) shows a grid Digital Elevation Model (DEM). XCount and YCount represent rows and columns of the DEM, and ZValues represents the elevation points. Figure 3(d) shows an expansion of the grid DEM structure with additional information concerning the DEM's Origin and Span.

Figure 3.  Examples of data representation using the UDX object model.

3.1.2. Semantically enhanced schema

Semantic information is used to give meaning to the data. Conveying semantic information in an explicit way will greatly facilitate model sharing and assist in intelligent parameter matching, model connection and data validation. However, this information is difficult to express directly using data structures and parameters in data files. As an example, Figure 4 is a representation of data for a water flow problem; input data are shown on the left, and their meanings are illustrated graphically in the right hand side sub-figure.

Figure 4.  Semantics explanation of data.

For example, data item ‘5’ indicates extensive information, such as (1) the unit of flow velocity is m/s rather than km/h, (2) the input data are the flow velocities rather than the pollutant concentrations or the temperatures and (3) the data describe the flow velocity for water flowing through cross-section A at time t0.

Although the UDX object model can be used to express complex data structures and contents, it cannot express the semantic information implied in the data. To address this shortcoming, a flexible semantic supplement strategy is important for geographic data description. Since the 1990s, with the aim of reducing the cognitive differences among geographic experts of multiple domains, related research on geographical ontology and cognition was conducted and applied to the semantic description of geographic data; to date, many achievements have been recorded (Kuhn 1994, Mark et al. 1999, Mennis et al. 2000, Kuhn 2001, 2002, 2003, 2005, Visser et al. 2002, Galton 2003, Smart et al. 2004, Abdelmoty et al. 2005). However, due to the complexity of geographic data and the difference of geographic cognition, the study of semantic abstract and expression of geographic data is still in its infancy and the problem of semantic heterogeneity has yet to be completely resolved (Donato 2010).

Referenced by SEDRIS, this article does not focus on the study of the semantic or geographic ontology, but provides a mechanism to clearly express the semantic so that both users and providers can share the semantic explicitly to help reduce the heterogeneity of the data. To establish a solid foundation for the sharing of geographic model data, the semantically enhanced schema was realised using XML, with four parts considered as follows: (1) measurement units and a spatial reference system (SRS); (2) meaning of data, such as soil porosity and flow velocity; (3) general data representation methods in specific domains (e.g. a TIN structure is generally defined with node sets and triangle sets); and (4) constraints between data structures (e.g. the number of triangle vertex indexes in a TIN must be no greater than the number of points in the point sequences). Figure 5(a) shows the design of the schema, and Figure 5(b) shows an example that can be used to illustrate the data used for Gaussian diffusion with semantic tags. In this case, the exact contents of the semantic can be imported by some mature semantic libraries according to the different classification; semantic tags can be attached to the UDX object model using Key-Value mode. For example, ArcGIS (http://www.esri.com/software/arcgis/index.html) or SEDRIS's (http://www.sedris.org/) SRS can be imported as the spatial reference tags of the data, while the Unit system of Ptolemy (http://ptolemy.eecs.berkeley.edu/) can be imported for unit tags.

Figure 5.  Semantically enhanced schema for UDX.

By embedding the semantic information into the UDX object model, the UDX model can be formed and employed to represent both data values and semantics. In this way, various types of semantic information can be attached to nodes with different types of kernels. For example, Unit/SRS and semantic information can be attached to nodes with value-type kernels, whereas data structure template information can be attached to nodes with structure-type kernels.

3.2. Behaviour description strategy

3.2.1. Analysis of model execution behaviour

Although the internal structures of geographical analysis models are generally complicated, their external interfaces are relatively simple. In the present case, with respect to the users, the geographical analysis model can be regarded as a black box, and the model's behaviour can thus be considered as interactions between the model and the users. Therefore, a strategy for the description of the model behaviour was developed according to two interaction types: simple interaction behaviour and complex interaction behaviour.

The description of the simple interaction behaviour is used to express the execution behaviour of the model with only one data processing flow or calculation process. The single process may include data submission by the user, model calculation, or the presentation of results. The model does not interact with other models or users throughout the process.

3.2.2. Description of the complex interaction behaviour

The complex interaction behaviour, which is usually used in simulating complex geographical processes, refers to execution processes that require multiple interactions with the external environment. These interactions include file reading and writing, requests user interventions and interoperation with other models.

To describe such complex interaction processes, a state machine-event response (SM-ER) model has been designed (see Figure 6). Because the SM is used in this model, whereas user interactions are represented by responses to different events, the model is defined as an SM-ER model.

Figure 6.  SM-ER model designed for describing complex interaction behaviour.

The concept of the SM-ER model is shown in Figure 6(a). After the model is launched, the SM-ER model begins to change state with its own simulation logic and triggers different events (e.g. requesting or providing data) until the entire simulation is completed. In this case, the whole process can be regarded as transitions from one state to another in which the interaction is realised by sending interaction events and waiting for external responses.

Figure 6(b) shows the UML model of the SM-ER model. The Behavioural object is the top-level one, which includes State sets and Transition sets. The Transition set describes the source and the target of the state transition and the conditions. The State set includes a name and its associated events, which are comprised of three fields: Name, RequestData and ResponseData. RequestData is designed to describe a request for data from the outside as an external input; ResponseData is used to describe the data submitted to the outside as an output. Therefore, if an Event contains RequestData, the model is requesting a user input; if ResponseData is contained in the Event, the model is providing data as an output.

Because the SM-ER model can represent either a strict execution order or a data requirement, combined with the UDX model, it can clearly reflect the execution process and benefit collaborative interactions between the models and the external environment.

4. Model encapsulation strategy based on cloud computing

According to the architecture proposed in Figure 1, the description strategy for the model resources designed in the previous section helps to reduce the heterogeneity in the model itself. However, model execution usually relies on a particular platform. To address the problem of platform heterogeneity, it was necessary to design a related encapsulation strategy to enable transparent access to models in the cloud.

4.1. Model execution service based on virtualisation technology

Virtualisation technology establishes a critical foundation for the realisation of cloud computing. Using this technology, different hardware platforms can be virtualised by the same hardware environment and can further be used for deploying a compatible OS and installing corresponding software environments (Siddhisena et al. 2011). Based on the characteristics of virtualisation technology, model execution containers and model message routers were designed to support model execution services (see Figure 7).

Figure 7.  Model execution service based on virtualisation technology.

A model execution container serves as the host for a model that is running on a virtual platform. To isolate different models, the model execution container creates separate sessions for each service and creates session stubs for models interacting with the external environment. The model message routers run on independent servers in CCP4GM and are responsible for forwarding messages between the model execution containers via a high-speed communication mechanism in a cloud computing environment.

4.2. Model encapsulation strategy

4.2.1. Model component interface design

The model runs in a sandbox environment provided by a model execution container. Therefore, the interfaces between the models and the containers must follow a set of standards. A model created according to these interface standards is called a standardised model component (Larson et al. 2004). Figure 8 shows the abstract model of the interface standards, which includes three abstract interfaces: IModelSessionStub, the interface of a model session stub for interactions between the model code and the outside environment, which is responsible for releasing events and states during model execution. IProcedureModelCore and ISimulateModelCore are the last two interfaces, representing the interfaces in simple and complex interaction models, respectively, as described in Section 3.2. Model providers can encapsulate model codes into standardised model components based on the definitions of these interfaces.

Figure 8.  The abstract model of the interface standards for the model components.

An object with an IModelSessionStub interface communicates with the external environment following the SM-ER model (see Section 3.2.2). The definitions of its functions are as follows (with parameters omitted): (1) SwitchState. This function is used to notify the external that the model has changed its state. (2) CreateUDX. This function is used to create an empty data object expressed by the UDX model, which can be used to transfer data of the model. (3) FireResponseEvent. This function is used to invoke an event in the client, but the provision of response data expressed by the UDX model is required by the client. (4) FireNoResponseEvent. This function is used to invoke an event in the client that contains the model's calculation results expressed by the UDX model. (5) FireException. This function is used to report runtime exceptions to the client.

The model with the IProcedureModelCore interface includes initialisation and running functions. When the running function is called, the model accepts the input data for calculation. Then, the results are returned as another data form created by the UDX model.

In addition to the Initialise and Run functions, a model with an ISimulateModelCore interface also contains a Kill function to stop a running process. This model interacts with IModelSessionStub in a model execution session. The process is shown in Figure 9.

Figure 9.  The process of model interaction with the outside environment.

(1) A model execution session calls the Initialise function to initialise the model; (2) the Run function is called to launch the model; (3) the model invokes the SwitchState function to notify the client to enter State0; (4) the model triggers the GetParamevent and requests data from the client; (5) the model begins the calculations; (6) the model requests the IModelSessionStub to create data objects expressed by the UDX model; (7) the model fills the data objects based on the calculation results; and (8) a ReturnResult event is triggered to return the calculation results. The steps are repeated until model execution is completed.

4.2.2. Heterogeneous model encapsulation strategy

Heterogeneous model encapsulation involves encapsulating the original heterogeneous model code into model components that can be hosted in a model execution container. Two issues arise in this process: whether the model code must be modified and whether the model runs in a host process as an independent process.

(1) The purpose of encapsulating the model code is to realise the model stub to achieve interactions between the model and the external environment. There are two cases related to this aspect: modifying the source code and keeping source code intact (see Figure 10).

Figure 10.  Two modes for model encapsulation by modifying model code.

If a model's source code can be accessed, the model encapsulation can be realised by modifying the source code, into which a session stub is inserted. In this case, a session stub interface should be realised using the same programming language as the model's source code. After the source code is modified, the model components can be obtained by re-compiling and re-linking.

If a model's source code cannot be accessed or is unsuitable to modify, a session stub cannot be inserted directly. However, models typically interact with the external environment through Input/Output (IO) interfaces, whose operation can eventually be converted into Application Programming Interface (API) calls. Therefore, binary interception with hook technology (Hunt and Brubacher 1999) can be adopted to intercept IO calls, in order to transfer IO operations into session stub calls.

(2) The executable programme of model components is in the form of either library files or executable files. The former runs in the host process, whereas the latter can only run as an independent process. In this case, objects with IProcedureModelCore or ISimulateModelCore interfaces are designed differently according to the different running modes (see Figure 11). The core object designed for the latter is only a proxy for the model code and interacts with the real model through a communication mechanism (e.g. inter-process communication channels).

Figure 11.  Two process modes of model execution.

Based on the above analysis, the selection of an encapsulation method is essentially related to the form of the model's code. The model can be easily modified if the source code is available and can also be easily encapsulated by the execution of either an in-process mode or an out-of-process mode. Without the model's source code, the execution of an in-process mode can be used for encapsulation in the case of library files; however, for executable files, only execution in an out-of-process mode is suitable. Generally, execution in an out-of-process mode provides better stability and safety, whereas an in-process mode consumes fewer system resources and can be launched quickly.

5. Cloud deployment and service interaction strategies

5.1. Description of deployment configuration

After models are encapsulated into model components, model components must be packaged and deployed in the cloud for transparent access. Figure 12 shows an example of a deployment package.

Figure 12.  Model deployment package and its composition.

The package includes the model components and the model deployment configuration documentation, which is designed to describe information related to the model deployment, access and execution. It includes the following items: (1) a Model node to contain top-level elements, including a model IDentity (ID) name and other information; (2) a Meta node to describe metadata information, including the author, classification, keywords and other information, which contributes to the convenient discovery of the models; (3) a UDXs node to describe the data required for the model running as expressed in UDXSL; (4) a Behaviour node to define the executable behaviour of the model; and (5) a Deployment node to describe model deployment information. This type of node includes the following child nodes: (1) a Platform node to define the executing environment of the model; (2) a Module node to describe the module information for the model deployment; and (3) an Entry node to describe the entry information to launch the model code.

5.2. Registration and deployment strategy of computing and model resources

After the model deployment packages are built, the model and computing resources are bound by the collaboration of OSP4GM and CCP4GM. Finally, executable model services can be provided. OSP4GM is responsible for model and computing resource management as well as deployment coordination along with the core functions of modelling resource registration, computing resource registration, model deployment and service creation. CCP4GM is responsible for physical deployment and execution along with the core functions of model deployment management and model service creation (see Figure 13).

Figure 13.  Registration and deployment of model and computing resources.

The collaboration process between OSP4GM and CCP4GM is discussed here:

1.	Model submission. Model providers submit model deployment packages through a model resource management interface. OSP4GM is responsible for the integrity verification of the deployment package, an analysis of the configuration information, the creation of a model index and the registration of the metadata. OSP4GM is also responsible for saving the packages in a model resource library for subsequent deployment.
2.	Computing resource management. CCP4GM provides computing resources based on virtualisation technology. A deployment management node and several virtual computing nodes constitute a dynamic virtual computing resource pool. The deployment management node is responsible for creating virtual computing nodes, deploying model execution containers, adjusting computing resources and dynamically updating the registration information of virtual computing resources. This node also maintains a list of computing resources and registers them with OSP4GM. OSP4GM then dynamically requests for the allocation of computing resources based on the registered information. As described in Section 4.1, each computing node in CCP4GM is an independent virtual computer that provides an execution container for a heterogeneous model.
3.	Model deployment. Model components are deployed to the corresponding model execution containers by a model deployment engine according to the description in the model deployment package. Four steps are involved in this process: computing resource discovery, model resource push, model component deployment and deployment information registration. The deployment information is recorded into the model and the computing resource binding list in OSP4GM.
4.	Model service creation and transparent resource deployment. The model service creation engine is responsible for searching for model services, matching them with execution containers and creating model-running cases. OSP4GM-based model service creation is a transparent process including computing resource allocation, model deployment and model service creation, as shown in Figure 14.

Figure 14.  Transparent creation of model service.

During the entire process, deployment registration information is queried in OSP4GM. If there exists a model execution container already hosting a model in the CCP4GM cloud, OSP4GM directly requests the corresponding instances; otherwise, the model deployment process is launched. If no corresponding model execution container is found during the model deployment process, a model execution container is created based on the model deployment configuration files. To improve the response speed for the model service creation, a pre-deployment mechanism is adopted.

6. Experiment

6.1. Experiment environment

We established a simulative experiment environment based on an Inspur^TM NX7140 cluster, which contains 28 blades (with 256 cores, 1 Terabyte (TB) of Random Access Memory (RAM) and 256 TB of hard disk space) and a VMW are ESX Server, which is a virtualisation programme that was installed to simulate an experimental environment consisting of 11 virtual computers (see Figure 15).

Figure 15.  Configuration of experimental environment.

In this environment, a virtual computer called the mds_portal was used to deploy the OSP4GM server, with the CCP4GM functionality consisting of two components: mds_c1 and mds_c2. As an example, mds_c1 contains a management node named mds_c1_mgr and four other computing nodes, mds_c1_n1 to mds_c1_n4. In addition to managing these internal nodes, the mds_c1_mgr node communicates with the mds_ portal through an external network. Model deployment and message routing services in the cloud were provided by the mds_c1_mgr node; the model execution containers were deployed at the computing nodes (mds_c1_n1 to mds_c1_n4).

6.2. The construction of geographical model sharing environment

On the basis of the framework described in Section 2.3, the OSP4GM and CCP4GM platforms were realised. OSP4GM contains several different interfaces and website user interfaces, which are shown in Figure 16. With reference to the Volunteer mode (Goodchild 2009, 2010), each user is not only able to contribute descriptive information resources, including units, semantics and abstract structure UDX model through services provided by the OSP4GM portal but is also able to submit, search and use model component resources.

Figure 16.  Main interfaces of model sharing environment.

Model execution containers, a message router and a computing resource deployment management server were realised for the CCP4GM. The model execution container was designed to support the encapsulation of two types of modes, which were implemented in.NET or C/C++. The message router implementation is based on Microsoft IIS 7.0/ASP.NET and can interact with an external environment solely via the HTTP protocol. The computing resource deployment management server works with the model execution container to deploy models from the OSP4GM.

In addition to the construction of basic platforms, experimental resource libraries, including a unit library, a semantic library and a data structure library, were established to help users more clearly describe the models they contributed or required. The unit library was based on the GB-3100-3102/ISO-1000:1992 standard, which includes more than 400 standard units. The semantic library was based on the Dictionary of Modern Geography (Zuo 2009) and was also integrated with the NASA Semantic Web for Earth and Environmental Terminology (SWEET) ontology library (Raskin and Pan 2005). Moreover, a relatively comprehensive general semantic library in the field of geographical modelling and simulation was constructed through association with Wikipedia entries. Furthermore, a model classification system was constructed based on the Scientific Classification System of the Earth (Chen 1998) for model indexing. All of these resources can be added by users if they cannot be found in the environment.

6.3. Practical verification of the geographical analysis model sharing environment

To verify the practicability of the environment, the project group organised a testing team with two types of volunteers: a team of model collectors and providers and a team of model users. The former was responsible for model collection, encapsulation, registration and submission using the OSP4GM, whereas the latter was responsible for geographical process simulation using the models deployed in the cloud.

A representative experimental model library was constructed from the contributions of the model collector and provider team. By referring to the Resources and Environment Models Manual (Yue 2003) and 62 analytic models in the fields of atmospheric science, hydrology, meteorology and others, the team realised or reconstructed most of the models and created more than 2000 model components, which were later encapsulated using the strategies previously described in Section 4.

In terms of the implementation process, with the objective of encouraging and helping model owners share their models, a corresponding model description tool and encapsulation tool were developed based on the well-designed strategies of model description and heterogeneous model encapsulation (see Figure 17). The model description tool enables interactive definition of the UDX data description and running behaviour of the models. Tool (a) is responsible for data structure defining and then attaching related semantics tags to data by dragging these tags into data elements in the formed date structure. Tool b takes charge of data editing as well as model behaviour editing. Tool c is the model encapsulation tool. It can automatically generate the conversion code between UDX and the data type of the models that use a text file as the IO, and it can also generate the interaction code between the models and the IModelStub interface based on the model behaviour. However, improvements to the encapsulation tool are needed because it does not support the encapsulation process of models with other forms of inputs and outputs, and requires the manual interaction of the users.

Figure 17.  Strategies realisation and accordingly tools.

After the models were encapsulated, they were uploaded to the OSP4GM with their descriptions, as described in Section 3, and then deployed in the CCP4GM. Figure 18 shows the deployment of several models. Figure 18(a) shows the model lists and Figure 18(b) shows the configuration information as well as the model execution container of the model component.

Figure 18.  Model resource library and model deployment.

Based on the models provided above, the user team searched and transparently used the deployed models with the computing resources provided by mds_c1 and mds_c2 in the CCP4GM. Figure 19 shows the results of invoking the model service in the cloud. The results in Figure 19(a) are from a geographical simulation of a Gaussian dispersion model, which was used to simulate the diffusion and concentration distribution of a point source of atmospheric pollution. Figure 19(b) shows the results of an improved simulation model for groundwater processes with complex interactions. This model was used to simulate changes in groundwater levels and recharge in a long-time sequence, which required users to input parameters to derive the running process.

Figure 19.  Model execution in the cloud environment.

7. Conclusions and future research

The purpose of this study is to build an open environment for geographical analysis model sharing based on cloud computing environment and to construct a volunteer-style sharing mode for modelling and computing resources. Our main focus was on model description, model encapsulation and cloud deployment. The major achievements are summarised as follows:

1.	A systematic analysis was conducted on the characteristics of geographical analysis models, especially the difficulties in resource sharing due to heterogeneity. An open environment for the sharing of geographical analysis models based on cloud computing architecture was designed and developed, which can effectively integrate distributed model resources and computing resources, bridging the gap between model providers, computing resource providers and model users.
2.	Several key strategies were designed for model description, model encapsulation, model deployment and transparent access, to lay a foundation for environment construction. The results indicate that these well-designed strategies can meet the requirements for model sharing, the unified description of models' data and execution behaviour, as well as operating environment-oriented encapsulation and automated cloud deployment and operation.
3.	A relevant experimental environment was established and experiments were conducted to verify the functionality of the framework. The results of the experiments show that this open environment was designed with strong adaptability and extendibility to assist with the sharing of geographical models.

However, as the environment is only a prototype, future research are needed in several aspects:

1.	More efficient tools are needed for implementing the three strategies. For example, the current encapsulation tool can only encapsulate models with text file for the input and output, and requires manual interaction of its users.
2.	Many different standards (e.g. the OGC Geography Markup Language, WPS) have been established for geographical information sharing. The compatibility of these standards lays a critical foundation for the successful promotion of the strategies proposed in this article.
3.	Due to the limitations of our experimental conditions, our experiments were performed in a simulated virtual environment rather than a real and well-deployed cloud environment. Thus, further research is required on system security and load balancing in the cloud environment.
4.	Computing resources on the Internet have various qualities of service which has not been seriously considered in this research. Thus, spatiotemporal principles (Yang et al. 2011) are required to optimise the computing resources; most of all, the execution time and space correlation properties of geographical models, calculating resources allocation by intelligently scheduling model resources, computing resources and data resources have to be investigated to provide optimal services.

Acknowledgements

We appreciate the detailed suggestions and comments from the editor and the anonymous reviewers. The work described in this article was supported by the Key Program of National Natural Science Foundation of China (Grant No. 40730527), the National Natural Science Foundation of China (Grant No. 41001223, Grant No.41101439) and the open fund from the Guangdong Key Laboratory for Urbanization and Geo-simulation in Sun Yat-sen University.