Full Terms & Conditions of access and use can be found at http://www.tandfonline.com/action/journalInformation?journalCode=tagi20 Download by: [Wuhan University] Date: 15 November 2015, At: 06:30 Annals of GIS ISSN: 1947-5683 (Print) 1947-5691 (Online) Journal homepage: http://www.tandfonline.com/loi/tagi20 GeoSquare: collaborative geoprocessing models’ building, execution and sharing on Azure Cloud Huayi Wu, Lan You, Zhipeng Gui, Kai Hu & Ping Shen To cite this article: Huayi Wu, Lan You, Zhipeng Gui, Kai Hu & Ping Shen (2015) GeoSquare: collaborative geoprocessing models’ building, execution and sharing on Azure Cloud, Annals of GIS, 21:4, 287-300, DOI: 10.1080/19475683.2015.1098727 To link to this article: http://dx.doi.org/10.1080/19475683.2015.1098727 Published online: 07 Nov 2015. Submit your article to this journal Article views: 7 View related articles View Crossmark data Citing articles: 1 View citing articles
Transcript
Full Terms & Conditions of access and use can be found athttp://www.tandfonline.com/action/journalInformation?journalCode=tagi20
Download by: [Wuhan University] Date: 15 November 2015, At: 06:30
GeoSquare: collaborative geoprocessing models’building, execution and sharing on Azure Cloud
Huayi Wu, Lan You, Zhipeng Gui, Kai Hu & Ping Shen
To cite this article: Huayi Wu, Lan You, Zhipeng Gui, Kai Hu & Ping Shen (2015) GeoSquare:collaborative geoprocessing models’ building, execution and sharing on Azure Cloud, Annals ofGIS, 21:4, 287-300, DOI: 10.1080/19475683.2015.1098727
To link to this article: http://dx.doi.org/10.1080/19475683.2015.1098727
GeoSquare: collaborative geoprocessing models’ building, execution and sharing on AzureCloud
Huayi Wua,b, Lan Youc*, Zhipeng Guib,d, Kai Hua,b and Ping Shena,b
aLIESMARS, Wuhan University, Wuhan, Hubei Province, 430071, China; bFaculty of Computer Science and Information Engineering,Hubei University, Wuhan, Hubei Province, 430062, China; cSchool of Remote Sensing and Information Engineering, Wuhan University,Wuhan, Hubei Province, 430071, China; dCollaborative Innovation Center of Geospatial Technology, 129 Luoyu Road, Wuhan, Hubei
Province, 430079, China
(Received 5 August 2015; accepted 11 September 2015)
Collaborative geoprocessing models have become one of the major solutions to significantly enhance the capacity to deriveknowledge over a network, which are critical for the support of comprehensive analyses in a virtual geographic environ-ment (VGE). With the emergence and growing maturity of the cloud computing infrastructure, a cloud-based platform forcollaborative geoprocessing models promises to provide a pattern for the next generation of geoprocessing collaboration inthe GIS realm. However, the problems with the existing collaborative geoprocessing models remain numerous, includingthe following: heterogeneity in description specifications hinders different geoprocessing services in collaborative work; theheterogeneity in messages mechanisms makes the cooperation among the geoprocessing services difficult and an integratedgeoprocessing model framework centring on the collaborative model’s lifecycle is absent. To address these problems, thisarticle proposes a cloud-based framework for building, executing and sharing collaborative models called GeoSquare: (1) alifecycle model was designed for convenient and flexible collaborative geoprocessing; (2) a collaboration mechanism wasimplemented to solve specification heterogeneity; (3) a collaboration method and its proxy were used to resolve theheterogeneity in message communication and (4) to acquire better scalability, some elastic cloud features were utilized inthe framework. A GeoSquare prototype was implemented on the Microsoft Azure Cloud to demonstrate the applicabilityand availability. Results show that users can build, execute, publish and share collaborative geoprocessing models with highefficiency in GeoSquare. GeoSquare provides a novel collaborative geoprocessing pattern enabling further geographicresearch in a cloud infrastructure.
Since geodata has become available widely through spatialdata infrastructures (SDI) (Groot and McLaughlin 2000),web geoprocessing based on service collaboration hasbeen receiving increased attention for geoscientific knowl-edge discovery (Kiehle, Greve, and Heier 2007). By usingcollaborative workflow technologies, a series of geocom-putation and analysis services can be integrated into ageoprocessing model for dealing with more complextasks (Brauner et al. 2009). Collaborative geoprocessingmodels have become one of the major solutions to sig-nificantly enhance the capacity to derive geo-informationand knowledge over a network (Zhao, Di, and Yu 2012).Collaboration models and the design of related tools arecritical for the support of comprehensive analyses in avirtual geographic environment (VGE) (Lin et al. 2013).Improvement of the customizable workflow greatlyenhances the collaborative ability in a VGE (Lin, Chen,
and Lu 2013). At the same time, the emergence of thecloud computing is promoting a transformation from tra-ditional desktop geoprocessing to distributed collaborativegeoprocessing (Bian, Xincai, and Jian 2010). Therefore, acloud-based platform for building, executing and sharingcollaborative geoprocessing models promises to provide apattern for the next generation of geoprocessing collabora-tion in the GIS realm.
However, there are still some challenges concerningcollaborative geoprocessing models: the heterogeneity indescription specifications hinders the different geoproces-sing services from collaborative work in the geoprocessingmodels; the heterogeneity in message mechanisms makesthe cooperation among the geoprocessing services difficultand a cloud-based framework centring on the collaborativegeoprocessing model’s lifecycle is absent.
Some research on geospatial services framework hasbeen conducted. You et al. (2012) proposed a geospatialservices composition framework supporting real-time
monitoring. Sun, Yue, and Di (2012) introduced a task-oriented web geoprocessing system that leveraged web ser-vice and workflow technologies to design and execute tasks,and monitor and visualize the execution of tasks. SAW-GEOis a prototype framework combining a visual modellingsolution based on industry specifications and semantic rea-soning (Hobona, Fairbairn, and James 2007). Maosheng andTianhe (2012) suggested a semantic geospatial web servicesharing framework for finding, evaluating, accessing andusing services. Li et al. (2011), You et al. (2012), Wu et al.(2011) and Yang et al. (2011) focused on optimizing anintegrated framework for supporting geospatial services.Existing research however, has paid more attention to theconstructing of the geospatial services composition thancollaborative geoprocessing.
To address these problems, this article proposes acloud-based framework for building, executing and shar-ing collaborative geoprocessing models called GeoSquarecentred on the collaborative geoprocessing model life-cycle. It has the following features:
(1) A lifecycle of the collaborative geoprocessingmodel was designed in the proposed framework;divided into four stages. Centred on the lifecycle,this framework integrates several functions andmodules for convenient and flexible collaborativegeoprocessing.
(2) To enable the geoprocessing services for harmo-nious collaborative work, a mechanism was imple-mented to solve the specification heterogeneityproblem.
(3) Considering that message communication heteroge-neity is universal in collaborative geoprocessingmodels, a message proxy and collaborationmechanism was designed for GeoSquare.
(4) To deliver better scalability, some elastic featuresfound in the Azure Cloud were utilized in theproposed framework.
The remainder of this article is organized as follows.Section 2 discusses related work. Section 3 introducesthe architecture of the GeoSquare. Section 4 describesthe key technologies in GeoSquare framework that enablethe GIS resources to work collaboratively. In Section 5, aprototype of the GeoSquare is introduced in detail and isimplemented on Azure Cloud. Finally, Section 6 presentsconclusions and plans for future work.
2. Collaborative geoprocessing
Geoprocessing services are the web services encapsulatinggeocomputation algorithms, which can be shared over theinternet. As a means to promote the on-demand instanttransformation of geodata into knowledge in the web
environment, geoprocessing services have attracted attentionboth from industry and academia.
The World Wide Web Consortium (W3C) defines a Webservice generally as: a software system designed to supportinteroperable machine-to-machine interaction over a net-work (Wikipedia, 2015). There are a variety of specificationsassociated with web services in varying degrees of maturityand are maintained or supported by various standards bodiesand entities. These various specifications are the basic webservices framework established by the first-generation stan-dards as represented by WSDL (Web services descriptionlanguage), SOAP (Simple Object Access Protocol), UDDI(Universal Description, Discovery and Integration) andXML (Extensible Markup Language). Since these specifica-tions do not include the metadata and spatial informationstandards, the special problems inherent to GIS cannot beeasily resolved. The Open Geospatial Consortium (2007)(OGC) published the Web Processing Service (WPS) speci-fication 1.0.0, a tangible sign indicating that geoprocessingservices are becoming an integral part of standardizedGIServices. A number of geoprocessing service resourceswere thereafter published online to enable collaborative geo-processing over the network, such as the GeoBrainProcessing Web Services (Li et al. 2010), the AlgorithmDevelopment and Mining System (ADaM) (http://projects.itsc.uah.edu/datamining/adam/), OpenRS-Cloud (Guo et al.2010), and so on.
To build large-scale computational calculations ascomplex geospatial simulation models, scattered geopro-cessing services distributed on the web are integrated intoa geoprocessing services workflow (Brauner et al. 2009).Geoprocessing service collaboration can be realized as acollaborative geoprocessing chain model by using work-flow technologies (Peltz 2003). By collaborating scatteredindividual geoprocessing services into a geoprocessingmodel, the design and execution of a complex processingmodel across domains and applications is enabled. Thecollaborative geoprocessing model is important forgeoscience research and applications, since their complex-ity (the geodata and computation problem) often requiresthe functionality of a series of processes. A collaborativegeoprocessing model provides a flexible way of imple-menting cross-application, multi-resource and multi-stepcomplex geoprocessing.
Several research projects, different vendors and opensource projects carry out work in the context of colla-borative geoprocessing. Alameh (2003) proposed a webservices workflow model, allowing users to easily com-bine web services to create customized geospatial infor-mation applications. Deng et al. (2004) implemented aprototype system to build a geoprocessing workflow forimage processing. Di et al. (2006) and Granell, Gould,and Francisco (2005) proposed an abstract process anddevised elementary workflow patterns as a foundationfor reusing existing models and services in
geoprocessing applications. Gui, Wu, and Wang (2008)developed a data dependency relationship directed graphand block structure-based abstract geospatial servicechain model. Friis-Christensen et al. (2009) proposedthe concept of DGIP (Distributed GeographicInformation Processing) and explored different architec-tural patterns for collaborative geoprocessing services.The 52° North WPS workflow modeller (http://52north.org/wps) allows the modelling of collaborative geopro-cessing services by chaining OGC services. Wu et al.(2014) presented a FAST pattern for collaborative geo-processing in messages level. Gong et al. (2012) pro-posed a concept model of geospatial services webtowards integrated cyberinfrastructure for GIScience.This work on collaborative geoprocessing discussed,however, focused on the modelling mechanisms andservice composition in a geoprocessing services work-flow, but without considering how to make GISresources work collaboratively in harmony. With thebirth and gradual maturing of the cloud computinginfrastructure, geocomputation is shifting from tradi-tional desktop geoprocessing to distributed collaborativegeoprocessing. This article proposes a cloud-based plat-form for building, executing and sharing the collabora-tive geoprocessing models and enables geoprocessingservices with different specifications and message
mechanisms to cooperate with each other. It provides acloud-based framework prototype for future collabora-tive geoprocessing initiatives.
3. Architecture
Aiming to make the GIS resources (including geodata,geoprocessing services and models) work collaborativelywith high efficiency, this article proposed a cloud-basedframework for building, executing and sharing collabora-tive geoprocessing models – GeoSquare. The basic archi-tecture of GeoSquare is web service oriented. GeoSquaredemonstrates a feasible way to achieve a geoprocessingcomputing paradigm for the future. The framework designof GeoSquare is as shown in Figure 1.
As Figure 1 shows, the GeoSquare framework consistsof three tiers: the application tier, computation tier andresource tier. For the collaborative geoprocessing models,seven core components including georesource registrycentre, geoprocessing model builder, geoprocessingmodel executer, geoprocessing model monitor, geoproces-sing model visualizer, geoprocessing model publisher anduser management were designed in the application tier.The computation tier is in charge of making georesourceswork collaboratively, smoothly and efficiently at the
backend. The basis of the whole framework is theresources tier, which involves the management and orga-nization of the geodata, geoprocessing services and geo-processing models. The whole framework is built on theMicrosoft Azure Cloud.
3.1. GIS resource registry centre
The GIS resource registry centre is used to register andquery the metadata of different kinds of geodata, geopro-cessing services and models for further processing andutilization. The GIS resources are divided into threegroups (data, services and models). The geodata groupincludes vector data and image data that can be the inputdata for the geoprocessing model. The services grouprefers to the algorithms for dealing with geodata, usuallyencapsulated into two forms: as W3C web services andOGC WPS services. A series of geoprocessing servicescan be united into the geoprocessing model. The geopro-cessing models are categorized into a model group in theregistry centre.
3.2. Geoprocessing model builder
A geoprocessing model is a geoprocessing servicescomposition, which includes a series of steps for onecomplex geocomputation task. This module has thefunctionality to provide users a graphic user interface(GUI) to build new geoprocessing models or edit oldones. Users specify the properties of a model and designits structure, which can be sequential, parallel or condi-tional. The model element repository provides the com-ponents that will be available in a new geoprocessingmodel. By dragging and dropping a model element inthe model editor, a geoprocessing model can be builtvisually. When a geoprocessing model is finished, it canbe stored in the model repository for reuse at an anothertime. Users can either select an old model from themodel repository or create a new one. This method isflexible in that users can easily build a geoprocessingmodel using atomic geoprocessing services.
3.3. Geoprocessing model executer
This module is used to remotely invoke the geoprocessingmodel previously deployed in the collaborative engine.Once a geoprocessing model is invoked, a model instancewill be activated and executed in a sequence as defined inWS-BPEL. The collaborative engine in the computationtier is an execution engine for WS-BPEL workflows.
3.4. Geoprocessing model monitor
This module captures the runtime information of the geo-processing model from the status collector in the backend
and shows them to the users. The status collector in thecomputation tier is used to collect the information of themodel and update continually. The monitor acquires theupdated status by communicating with the status collectorperiodically. This approach allows users to view thedynamic process information in real time.
3.5. Geoprocessing result visualizer
Once the running process of the geoprocessing model isfinished, the results will be generated in the backend. Forusers to conveniently browse the result, a geoprocessingresult visualizer was designed in the application tier. Thismodule is in charge of visualizing processing resultsaccording to the result types. This module integrates theGoogle Earth for previewing the image data by its locationinformation. For the statistical results for numeric types ofoperations, this module provides a statistical chart method.For other result types, a general method is file download-ing and local viewing using third-party tools.
3.6. Geoprocessing model publisher
When a geoprocessing model is created in the modelbuilder, it must be published on one collaborative enginefor user invocation. This module is used to publish anexisting model on the execution engine, while the modelmetadata is registered in the resource registry centre.
3.7. User profiles
User profiles refer to the individual definitions manage-ment of private information, GIS resources hosting, shar-ing, usage and related privileges. In order to let usersdistributed on the internet share their collaborative geo-processing models in different scopes, there are threelevels of resource sharing scopes in user profiles includingpublic, group and private. Users can deliver the geodata ormodels to the public if they want. Also, GIS resources canbe shared within a specific scope when the user defines agroup. The private definition enables user host data, algo-rithms and models on the platform while only the ownercan use these resources. This method is flexible as userscan share their resources within different scopes asrequired.
4. Methodologies
In this section, the key technologies in GeoSquare plat-form for building, executing and sharing of the geoproces-sing models are described in detail.
290 H. Wu et al.
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
4.1. Lifecycle of collaborative geoprocessing models
From the user perspective, a general geoprocessing modellifecycle can be divided into the following four stages: (1)Design stage: search GIS resources, build collaborativegeoprocessing models and deploy the model to the serverengine. (2) Execution/monitor stage: run the deployedmodel on the collaborative engine while monitor the pro-cess status. (3) Optimization stage: view the processingresults and adjust the model if necessary. (4) Publish stage:register the geoprocessing model into the registry centre,put the model into repository and publish the model forother users.
Figure 2 shows the major operations and relevantmodules at each stage in the lifecycle of collaborativegeoprocessing models. The lower half of Figure 2 showsthe supporting function modules in the application tier; thegeoprocessing model can be executed and adjusted repeat-edly once it is built. When the optimization of the geo-processing model is finished, it can be put into the modelrepository and published to other users for reusing. Forusers with an interest in specific geoprocessing models,they can search the keywords in the registry centre and runthe model to process their own geodata. One geoproces-sing model can be reused without any modification andreedited iteratively as needed in any stage.
In this lifecycle model, the execution/monitor stage isthe key to collaborative geoprocessing. Heterogeneity inimplementation specifications and message transmissionmust be considered and solved during the collaborationprocess for different geoprocessing services. In the execu-tion/monitor stage, the message mediator and asynchro-nous agent in the computation tier are used to enable thegeoprocessing services to seamlessly work in collabora-tion. The related implementation details are introduced inthe following sections.
In this proposed lifecycle, the collaborative geoproces-sing model can be built, used and shared smoothly. TheGeoSquare platform is conceptualized and implementedaround this lifecycle model and integrates supporting toolsand functions for collaborative geoprocessing.
4.2. Collaboration mechanism for heterogeneity inspecification
Once a geoprocessing model is activated, the collaborationengine will invoke geoprocessing services in the sequenceas defined in model file. Generally, there are two maingeoprocessing services: common web services and WPSservices. The common geoprocessing web services utilizeWSDL specification to describe the function and operationdetails, while the WPS services publish their capabilitiesusing their capabilities documents. Since differencesbetween the two capabilities description specificationsexist, how to enable the two sorts of geoprocessing ser-vices to work collaboratively is the primary problem to besolved in a geoprocessing model. This article proposes acollaboration mechanism using WPS services as the com-mon geoprocessing service in the geoprocessing model.
The WPS capabilities descriptions and WSDL descrip-tions focus on different aspects. The WPS capabilitiesdocuments list the name of operations but do not includethe relevant parameters for invocation. If users want toinvoke a WPS services, the DescribeProcess functionmust be executed first to obtain the detailed invocationparameters. The WPS capabilities documents focus on themetadata description including layers, coordination, geo-graphical range, supporting formats and so on, but lackgrammar information. The WSDL description document isjust the opposite, it introduces the detailed input/outputdata as the grammar. For a collaborative geoprocessing
Figure 2. Lifecycle of collaborative geoprocessing models.
Annals of GIS 291
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
model, the WSDL specification is more convenient whenconstructing an invocation message. This proposed colla-boration mechanism firstly transforms the capabilitiesdescription of a WPS service to the WSDL description,and then invokes the WPS service as a common geopro-cessing service. Figure 3 shows an example of a transfor-mation from a Capabilities description to a WSDLdescription.
In Figure 3, the left-hand side shows the original WPScapabilities fragment and the right-hand side shows thecorresponding WSDL fragment after transformation. Itcan be seen that the original I/O parameters includingthe title and data structure have been mapped into thenew WSDL. In this transformation, the simple datatype
is still simple in new WSDL while the complex datatypebecomes a string datatype. An additional parameterWPSURL for each operation in the WPS capabilities docu-ment is added in the corresponding WSDL document andrefers to the actual address. In the newly created WSDLdescription, the information details are enough to invoke aWPS service. Thus, the collaboration engine can treat theWPS as the normal geoprocessing service when it invokesa WPS service in a geoprocessing model.
Figure 4 shows the collaboration mechanism betweenthe WPS and common geoprocessing services. The colla-boration engine can invoke a common geoprocessing ser-vice as described by a WSDL document, but cannotgenerate a WPS request directly. To solve this problem, a
Figure 3. A transformation example between WPS capabilities and WSDL description.
Figure 4. Collaboration mechanism between the WPS and common geoprocessing services.
292 H. Wu et al.
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
WPS mediator is designed to help the engine construct aWPS request. In Figure 4, a WPS mediator consists of fourcomponents: WPS request parsing, message transforma-tion, WPS response parsing and message forwarding. TheWPS request parsing component is used to capture therequest from the engine server. The message transformationcomponent converts the WSDL request format into theWPS request format, and also the WPS response formatinto the WSDL response. The message forwarding compo-nent involves in sending transformed messages (WPSrequests or WSDL responses) to the receivers (WPS serversor collaboration engines). All the WPS service requestsfrom the collaboration engine are first forwarded to theWPS mediator; then the WPS mediator deals with themuniformly.
This approach enables a common geoprocessing ser-vices and allows WPS services to seamlessly work colla-boratively in a geoprocessing services workflow.
4.3. Collaboration mechanism for heterogeneity incommunication
There are two general communication modes: synchro-nous message mechanism and asynchronous message
mechanism. The asynchronous mechanism is more suita-ble for large-scale geodata computation, while the syn-chronous mechanism works well with smaller projects.Usually, in a collaborative geoprocessing model, bothsynchronous services and asynchronous services areincluded.
To further detail the collaboration mechanism, a sim-ple image processing model was built including a MedianFilter geoprocessing service and a SVM geoprocessingservice. Figure 5a shows the geoprocessing workflowlogic. Figure 5b shows how the synchronous servicesand asynchronous services collaboratively work in thiscase. In Figure 5b, the geoprocessing model is describedin WS-BPEL specification. The Median Filter geoproces-sing service is asynchronous, while the SVM geoproces-sing service is synchronous. A pair of asynchronousmessages (invoke, receive actions) based on WS-Addressing defined in the geoprocessing model are usedto request the Median Filter service. An invoke actiondefined in the geoprocessing model is used to request theSVM service. All the messages from the collaborationengine are sent to the message proxy. Then, it forwardsthe requests to the actual services. The message proxy is incharge of identifying and forwarding messages. By
Figure 5. Collaboration among different communication mechanism.
Annals of GIS 293
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
distributing different request messages to the geoproces-sing services with different communication mechanisms,the message proxy enables the geoprocessing serviceswork together.
4.4. Scalable framework mechanism on Azure Cloud
Azure Cloud is a cloud computing platform and infra-structure created by Microsoft for building, deployingand managing applications and services through a globalnetwork of Microsoft-managed and Microsoft partnerhosted data centres (Microsoft 2015). It provides largeamounts of cloud storage and computing resources forhosting applications and services.
To implement a scalable geoprocessing mechanism,GeoSquare platform utilized some features in AzureCloud. It was built on the Azure Cloud infrastructure.Figure 6 shows the design for scalable geoprocessingmechanism in GeoSquare. Azure load balancer (ALB) isa load-balancing mechanism that acts as a proxy anddistributes network or application traffic across a numberof servers, which are used to increase the capacity (con-current users) and reliability of applications on AzureCloud. Considering the intensive computation featuresfound in most geoprocessing models, ALB was used inthree places of GeoSquare architecture. The collaborationengine pool hosts several engine servers for executinggeoprocessing models having identical configurations.All the geoprocessing models are put in the model
repository and are shared among the engine servers.When a user executes a geoprocessing model to dealwith the geodata, the invocation request will be deliveredto the ALB. Then the ALB will distribute the invocationto an available engine server that is idle. Since the enginepool on a cloud can host engine servers as needed, theengine pool can scale up as the number of the concurrentusers increases. The same mechanism is designed in asyn-chronous proxies and WPS mediators for elastic geopro-cessing needs when executing collaborative geoprocessingmodels. As shown in Figure 6, the ALB was designed inthe places where performance bottlenecks in the frame-work are likely to occur. The model repository and usersworkspaces were created based on Azure blob storage,providing elastic storage and acting as a file system withunlimited capacity. The queue feature in Azure Cloud is amessage mechanism that stores the messages as asequence. The preprocessing tasks queue is a task queuebased on a queue feature that hosts a sequence of proces-sing messages waiting to be executed. These elasticmechanisms enable GeoSquare to achieve robust extensi-bility and scalability.
5. Implementation
In order to verify the efficiency of the GeoSquare plat-form, a prototype for building, using and sharing colla-borative geoprocessing models was developed on theMicrosoft Azure Cloud. The application tier was
Figure 6. Scalable collaborative geoprocessing on Azure Cloud.
294 H. Wu et al.
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
developed on Eclipse 6.0 IDE. The GIS resources regis-try centre was built with the Ext Google Web Toolkit(GXT) (Google 2012). The geoprocessing model builderwas developed using Java RCP techniques. The geopro-cessing model visualizer was developed on the GoogleEarth API. The ActiveBpel engine (Endpoints 2004) wastaken as the collaborative engine for the geoprocessingmodels. The Java Servlet was used to implement theWPS mediator, status collector and asynchronous agent.All the GIS resources including geodata, geoprocessingservices and models were stored in the Azure blob sto-rage. The metadata of the GIS resources was organized inSQL Azure, which is a SQL server database on AzureCloud.
Figure 7 shows the main GUI of the GeoSquare. InFigure 7, the left panel is the GIS resources registry centrethat presents the GIS resources as a tree catalogue. Theright panel is the metadata viewer for the GIS resources inregistry centre that presents details and a snapshot. Whenbuilding collaborative geoprocessing models, users caneasily search the GIS resources by location or keywords.At the top-right corner, there is an entrance for user logins.Figure 8 shows the changes after a user logs in. Whenusers log in, they can share resources within three ranks:Public, Group and Private.
Figure 9 shows the geoprocessing model builder inwhich users can build a geoprocessing model composed ofseveral geoprocessing services and geodata. In Figure 9,the main part is the model editor and the right panelpresents the models resources stored in geoprocessingmodel repository.
Once a geoprocessing model has been built, it can beexecuted on the collaboration engine. Figure 10 shows the
GUI of geoprocessing model executer. The green bar ofeach geoprocessing service indicates the running status. Itcan be seen that all the geoprocessing services in thespatial filter model have finished their tasks.
The model’s execution results can be preprocessed forvisualization on virtual earth. Figure 11 visualizes theresult image on Google Earth using latitude and longitudeinformation.
After building and executing a collaborative geopro-cessing model, the owner can publish it to the registrycentre and share it with other collaborators. Figure 12shows the metadata of the geoprocessing model, whichincludes the name, provider, WSDL URL and otherdetails. These metadata provides enough details so thatother users can reedit and reuse the geoprocessing model.
As Figure 13 shown, a group can be created if the userwants to share models within a limited range. InFigure 14, the spatial filtering model in the user’s favour-ite folder can be shared within the spatial model group orall the public users. Through this method, the collabora-tive geoprocessing model can be shared within the freescope and improves model reuse efficiency.
6. Conclusions and future work
Aiming to make the GIS resources (including geodata,geoprocessing services and models) work collaborativelyat high efficiency, this article proposed a cloud-basedframework for building, executing and sharing collabora-tive geoprocessing models – GeoSquare. The GeoSquareplatform has following features that help to resolve pro-blems associated with collaborative geoprocessing.
Figure 7 GUI of GeoSquare.
Annals of GIS 295
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
Figure 8. Resource sharing ranks after users’ login.
Figure 9. Geoprocessing model builder.
296 H. Wu et al.
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
(1) A lifecycle for the collaborative geoprocessingmodel was proposed that adds flexibility and con-venience of the model framework. In this pro-posed lifecycle, a collaborative geoprocessingmodel can be built, used and shared smoothly.The GeoSquare lifecycle platform integrates sup-porting tools and functions necessary for a colla-borative geoprocessing model.
(2) To solve the problem of the specification heteroge-neity existing in the geoprocessing services, this
article proposed a collaboration mechanism toenable harmonious collaborative work. Throughtransforming the WPS capabilities to WSDL, theWPS can be invoked as common geoprocessingservices using the normal collaboration engine. AWPS mediator was designed for the messageexchange between the collaboration engine and theWPS services. In this way, the two sorts of geopro-cessing services can be united to work together inthe geoprocessing model.
Figure 11. Geoprocessing results visualizer.
Figure 10. Geoprocessing model executer.
Annals of GIS 297
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
(3) A collaborative approach to solve the heterogeneityproblem in message communication common to allcollaborative geoprocessing models was designedin GeoSquare. By adding a message proxy, all therequests coming from an engine server werehandled uniformly and distributed to the corre-sponding services whether asynchronous or not.
The message proxy enabled the geoprocessing ser-vices in different communication mechanisms towork well with each other in a way that promotesthe compatibility of the framework.
(4) To achieve improved scalability, some features ofthe Azure Cloud were utilized in GeoSquare. TheALB mechanism was used to balance the
Figure 13. Creating a group for sharing models.
Figure 12. Publishing the model on GeoSquare.
298 H. Wu et al.
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
processing loads in collaboration engines, mes-sage proxies and WPS mediators to satisfyincreased processing demands. The geoprocessingmodels were stored centrally in the Azure blob, afile system with unlimited capacity. Because ofusing the elastic cloud features, the proposed plat-form obtained more scalability for extensibilityneeds likely to occur in the future.
The prototype of the GeoSquare on Azure Cloud demon-strates that users can build, execute, publish and share thecollaborative geoprocessing models at high efficiency inGeoSquare. The integrated modelling environment pro-vides tools to create a new model or edit an old one.The collaboration mechanisms make geoprocessing ser-vices with different description specifications or commu-nication messages work collaboratively in a geoprocessingmodel. Furthermore, some assistant modules such as themodel monitor results visualizer and user profiles areintegrated in GeoSquare, prompting users to smoothlydeal with geoprocessing tasks. GeoSquare provides anovel collaborative geoprocessing pattern for further geo-graphic research on the cloud infrastructure. Futureresearch in this framework will emphasize: (1) continuallyimproving the flexibility and availability of the frameworkand (2) further clarifying the collaborative geoprocessingmodels classification.
Disclosure statementNo potential conflict of interest was reported by the authors.
FundingThis work was supported by the National Natural ScienceFoundation of China under Grants [41401464], [41371372];and MSRA [PO# 96161227].
ReferencesAlameh, N. 2003. “Chaining Geographic Information Web
Services.” Internet Computing, IEEE 7: 22–29.Bian, W., W. Xincai, and H. Jian. 2010. “Geospatial Data
Services within Cloud Computing Environment.”International Conference on Audio Language and ImageProcessing (ICALIP), Shanghai, November 23–25, 1577–1584. (IEEE Catalog Number: CFP1050D-ART and ISBN:978-1-4244-5858-5.).
Brauner, J., T. Foerster, B. Schaeffer, and B. Baranski. 2009.“Towards a Research Agenda for Geoprocessing Services.”12th AGILE International Conference on GeographicInformation Science 1: 1–12.
Deng, M., P. Zhao, Y. Liu, A. Chen, and L. Di. 2004. “TheDevelopment of a Prototype Geospatial Web Service Systemfor Remote Sensing Data.” The International Archives ofPhotogrammetry, Remote Sensing, and Spatial InformationSciences 30 (Part 2): 1–5.
Di, L., P. Zhao, W. Yang, and P. Yue. 2006. “Ontology-DrivenAutomatic Geospatial-Processing Modeling Based on Web-Service Chaining.” Proceedings of the Sixth Annual NASA
Figure 14. Sharing the geoprocessing models within a group.
Annals of GIS 299
Dow
nloa
ded
by [
Wuh
an U
nive
rsity
] at
06:
30 1
5 N
ovem
ber
2015
Earth Science Technology Conference, College Partk, MD,June 27–29.
Endpoints, A. 2004. ActiveBPEL.Friis-Christensen, A., R. Lucchi, M. Lutz, and N. Ostländer. 2009.
“Service Chaining Architectures for Applications ImplementingDistributed Geographic Information Processing.” InternationalJournal of Geographical Information Science 23: 561–580.doi:10.1080/13658810802665570.
Gong, J., H. Wu, T. Zhang, Z. Gui, Z. Li, L. You, S. Shen, et al.2012. “Geospatial Service Web: Towards IntegratedCyberinfrastructure for GIScience.” Geo-spatial InformationScience 15 (2): 73–84. doi:10.1080/10095020.2012.714098
Google 2012. GXT.Granell, C., M. Gould, and R. Francisco. 2005. “Service
Composition for SDIs: Integrated Components Creation.”Proceedings of the Sixteenth International Workshop onDatabase and Expert Systems Applications, Copenhagen,Denmark, August 26, 475–479. IEEE.
Groot, R., and J. D. McLaughlin. 2000. Geospatial DataInfrastructure: Concepts, Cases, and Good Practice.Oxford: Oxford University Press.
Gui, Z., H. Wu, and Z. Wang. 2008. “A Data DependencyRelationship Directed Graph and Block Structures BasedAbstract Geospatial Information Service Chain Model.”Proceedings of the Fourth International Conference onNetworked Computing and Advanced InformationManagement, Gyeongju, Korea, 2–4 September.
Guo, W., J. Gong, W. Jiang, Y. Liu, and B. She. 2010. “OpenRS-Cloud: A Remote Sensing Image Processing Platform Based onCloud Computing Environment.” Science China TechnologicalSciences 53: 221–230. doi:10.1007/s11431-010-3234-y.
Hobona, G., D. Fairbairn, and P. James. 2007. “Semantically-Assisted Geospatial Workflow Design.” In Proceedings ofthe 15th Annual ACM International Symposium on Advancesin Geographic Information Systems, 26. Seattle, WA: ACM.
Kiehle, C., K. Greve, and C. Heier. 2007. “Requirements forNext Generation Spatial Data Infrastructures-StandardizedWeb Based Geoprocessing and Web ServiceOrchestration.” Transactions in GIS 11: 819–834.doi:10.1111/tgis.2007.11.issue-6.
Li, X., L. Di, W. Han, P. Zhao, and U. Dadi. 2010. “SharingGeoscience Algorithms in a Web Service-OrientedEnvironment (GRASS GIS Example).” Computers &Geosciences 36: 1060–1068. doi:10.1016/j.cageo.2010.03.004.
Li, Z., C. P. Yang, H. Wu, W. Li, and L. Miao. 2011. “AnOptimized Framework for Seamlessly Integrating OGCWeb Services to Support Geospatial Sciences.”
International Journal of Geographical Information Science25: 595–613. doi:10.1080/13658816.2010.484811.
Lin, H., M. Chen, and G. Lu. 2013. “Virtual GeographicEnvironment: A Workspace for Computer-AidedGeographic Experiments.” Annals of the Association ofAmerican Geographers 103: 465–482. doi:10.1080/00045608.2012.689234.
Lin, H., M. Chen, and G. Lu et al. 2013. “Virtual GeographicEnvironments (VGEs): A New Generation of GeographicAnalysis Tool.” Earth-Science Reviews 126:74–84.
Maosheng, H., and C. H. I. Tianhe 2012. “Semantic GeographicWeb Service Sharing Framework.” In Recent Advances inComputer Science and Information Engineering, edited byZ. Qian, L. Cao, and W. Su, et al., 553–559. Berlin: Springer.
Microsoft. 2015. Microsoft Azure.Open Geospatial Consortium. 2007. OpenGIS Web Processing
Service version 1.0.0. Open Geospatial Consortium (OGC).Peltz, C. 2003. “Web Services Orchestration and Choreography.”
Computer 36: 46–52.Sun, Z., P. Yue, and L. Di. 2012. “Geopwtmanager: A Task-
Oriented Web Geoprocessing System.” Computers &Geosciences 47: 34–45. doi:10.1016/j.cageo.2011.11.031.
Wikipedia 2015. Web services.Wu, H., Z. Li, H. Zhang, C. Yang, and S. Shen. 2011.
“Monitoring and Evaluating the Quality of Web MapService Resources for Optimizing Map Compositionover the Internet to Support Decision Making.”Computers & Geosciences 37: 485–494. doi:10.1016/j.cageo.2010.05.026.
Wu, H., L. You, Z. Gui, S. Gao, Z. Li, and J. Yu. 2014.“FAST: A Fully Asynchronous and Status-TrackingPattern for Geoprocessing Services Orchestration.”Computers & Geosciences 70: 213–228. doi:10.1016/j.cageo.2014.06.005.
Yang, C., H. Wu, Q. Huang, Z. Li, and J. Li. 2011. “UsingSpatial Principles to Optimize Distributed Computing forEnabling the Physical Science Discoveries.” Proceedings ofthe National Academy of Sciences 108: 5498–5503.doi:10.1073/pnas.0909315108.
You, L., Z. Gui, W. Guo, S. Shen, and H. Wu. 2012. “AGeospatial Web Services Composition FrameworkSupporting Real-Time Status Monitoring.” InternationalSociety for Photogrammetry and Remote Sensing I–4: 175–179. doi:10.5194/isprsannals-I-4-175-2012.
Zhao, P., L. Di, andG.Yu. 2012. “BuildingAsynchronousGeospatialProcessing Workflows with Web Services.” Computers &Geosciences 39: 34–41. doi:10.1016/j.cageo.2011.06.006.
