The Use of Web 2.0 and Geoprocessing Services to Support Geoscientific Workflows Ziheng Sun*, Peng Yue State Key Laboratory for Information Engineering in Surveying, Mapping & Remote Sensing (LIESMARS), Wuhan University, Wuhan, Hubei, China * Corresponding author:
[email protected] Abstract—In a service-oriented geoscientific research environment, individual geospatial services must be chained together as scientific workflows to solve a complex geospatial problem. The emergence of various visual workflow designers, such as Taverna, GridNexus, Kepler, greatly facilitates the construction of geoscientific workflows. However, existing scientific workflow tools are mainly desktop-based. The emergence of Web 2.0 technology has shown promise to develop athe browser-based scientific workflow designer, which can bring rich experiences to users. This paper describes the design and implementation of a geoscientific workflow tool by integrating the Web 2.0 and geoprocessing services. The design of workflows is based on a three-phase procedure: process modeling, process instantiation, and workflow execution. The approach and experience provide valuable references for future development of Web-based geoscientific workflow systems. Keywords- Scientific Workflow; GIS; Web 2.0; Geoprocessing Services; Service Composition
I.
INTRODUCTION
Nowadays, new Web technologies are increasingly emerging. In a technique view,Web 2.0, a typical set of Web-based technologies including Asynchronous JavaScript (JS) and XML (AJAX), is being widely used to enhance the collaboration, creativity, and rich user experiences. The emergence of Web 2.0 marks an upgrading of Web ideological system, in which users’ participation and experience is better addressed. Meanwhile, recent development of Geographic Information System (GIS) has also shown the same situation, and several directions have appeared including Web GIS, 3D GIS, and Virtual GIS. With the development of Web and its wider popularization in GIS, how to combine GIS with Web2.0 effectively, now, is a research hotspot in Web GIS . There has been lots of Web-based geospatial information sharing and applications. Web Service technologies are already being widely used in geospatial domain for distributed geospatial data sharing and processing [1,2]. Some work has been conducted to develope various geoprocessing services by wrapping legacy geoprocessing functions in traditional desktop-based GIS software using Web Service technologies. Thus traditional functions of spatial analysis in GIS can be reused by invocation of a number of geoprocessing middleware services on the Web. However, there are still some open issues towards the wide applications of current geoprocessing services, including standardization of service interfaces, convenient integration of geoprocessing services.
This work was funded jointly by Project 40801153 supported by NSFC, 2009 ISPRS Scientific Initiative Project, 863 Program of China (2007AA120501, 2007AA12Z214), LIESMARS and SKLSE (Wuhan University) Special Research Fundings.
Because Web services are scattered and many services may be needed to solve complicated scientific problems, workflow technologies are used, which can unite dispersive services together to achieve more intricate goals [2]. In the e-business domain, workflow technologies have been mature. Service-oriented workflow languages that have been widely used include Web Services Flow Language (WSFL), Web Services Business Process Execution Language (WSBPEL), shortly known as BPEL. Tools that support these languages are also available, including ActiveBPEL, Oracle BPEL, Apache ODE. In scientific research domain, scientific workflow brings great convenience to researchers who always work in a virtual environment. In a service-oriented geoscientific research environment, individual geospatial services must be chained together as scientific workflows to solve a complex geospatial problem. Recent development of scientific workflow systems in the Cyberinfrastructure has provides several choices of scientific workflow tools, including Taverna, Triana, GridNexus, Kepler of NASA [3]. While these tools facilitate greatly the construction of scientific workflows, they are desktop-based systems and cannot support geospatial applications directly. In the field of GIS, the ArcGIS Model Builder can support the creation of geoprocessing workflows. However, it can only work in its proprietary environment. To address the current limitations of scientific workflow systems, this paper proposes a workflow approach to compose geoprocessing services and provides a browser-based scientific workflow tool that leverages Web 2.0 and geoprocessing services technologies. Such an approach and experiment pave the way to further optimize the composition of geospatial processing services. The geoprocessing workflow tool allows users to drag geoprocessing functions freely, and create geoprocessing workflow models. Using these designed geoprocessing models, the tool can map models into executable scientific workflow represented by BPEL. Therefore, the tool demonstrates the applicability of our approach. II. GEOPROCESSING WORKFLOW DESIGN The design of geoprocessing workflows is based on a three-phase procedure: process modeling, process instantiation, and workflow execution. The first phase is to construct a logical workflow, which consists of control flow and data flow among atomic processes. The second phase is to transform the logical workflow into a concrete workflow or an executable service chain. The result is represented using BPEL.
Fig.1. Functional design of geoprocessing workflow model builder
And the third phase is to execute BPEL in a workflow engine [4,5,6]. Fig.1 shows the functional design of geoprocessing workflow model builder. All available geoprocessing services can be considered as tools in a service toolkit. These service tools are described by service descriptions using XML, and visualized as tools in the client graphic user interface (GUI). Using tool descriptions, users can drag and drop tools to create models for geoprocessing workflow. These models are described using XML-based descriptions and can be mapped into concrete geoscientific workflows. Geoprocessing workflow model builder is made up of the following functional modules: 1) Client of geoprocessing workflow model builder. It allows the recording of users' operation, editing and visualizing the geoprocessing workflow that users want to construct in a user-friendly way. Users only need to understand the functionality, input, and output of each service tool, drag and drop tools, and compose these tools in a correct domain logic. This module can be further divided into three sub-modules. a) Visual modeling module. It provides a GUI to allow drag and compose geoprocessing models conveniently. b) Model encoding module. It recodes geoprocessing models based on the visual workflow model created by users in GUI, and encodes them using XML. c) Model editing module. It allows users to edit geoprocessing workflow models encoded in XML. 2) Model transformation module. It transforms geoprocessing workflow models into scientific workflows represented using BPEL. This module can be divided into three submodules. a) Workflow engine selection. It allows users to select
the specific workflow engine that can be used to run the concrete scientific workflow. Different workflow engines have their own configuration files for deployment. This module, therefore, determines what kind of configuration files to be created when transforming geoprocessing models into concrete workflows. b) Scientific workflow generation. It is responsible for instantiating geoprocessing workflow models into an executable scientific workflow. c) Creation of configuration files for the selected workflow engine. Corresponding to the workflow engine selected, this module creates the configuration files required to deploy generated workflows into the selected engine. 3) BPEL workflow module. It deploys the generated workflow package including concrete workflows and related configuration files into the selected workflow engine. The workflows deployed successfully, can then provide new services tailored to users’ needs. III.
SYSTEM DEVELOPMENT
A. Relevant Technology 1) AJAX AJAX is a new mode of Web development, which integrates several widely used Web technologies to realize high interactive Web application procedure. The core of AJAX is XMLHttpRequest which allows Web browser to communicate with server asynchronously. It can refresh only parts of the web page instead of the whole page to provide conditions for efficiency and stability of execution of Web applications. In the development of geoprocessing model builder, AJAX is used to realize GUI, and send users' requests to Web server and receive process results asynchronously.
2) JAVA servlet JAVA servlet is a small Java procedure running on server, which is especially used to receive users' requests sent from Web browser, process them and create responses in the run time. One servlet application can be implemented as a JAVA class, which specifies an interface. The servlet runs in Web servers such as Apache Tomcat. 3) BPEL BPEL is a workflow descriptive language based on XML, which supports Web service standards such as SOAP, WSDL. An executable BPEL process can provide the process description for a geoprocessing service chain based on a number of activities, partners and messages exchanged between these partners. Web services with which a BPEL process interact are associated as partner links using their accompanying WSDL. 4) OGC WPS The Open Geospatial Consortium (OGC) Web Processing
Service (WPS) specifies a standard interface and protocol to discover and execute distributed geoprocessing processes. A geoprocessing process could be any sort of GIS analysis functions. The three mandatory operations included in the standard WPS interface are GetCapabilities, DescribeProcess, and Execute [7]. B. Implementation The geoprocessing model builder is implemented as a Web application. The functional modules mentioned in Section 2 have been implemented in either Web client or Web server applications. The Web client is written by JavaScript and used to interact with users, collect information on users’ actions and save them in XML file as abstract models of geoprocessing workflow. The Web server applications are responsible for both geoprocessing model transformation and workflow executions. They exchange messages with Web clients and processing Web requests. The overall system architecture is illustrated in Fig.2.
Fig.2. System architecture of geoprocessing model builder tool
The system uses available geoprocessing services as the fundamental tools. Descriptions for geoprocessing services are retrieved by either sending metadata queries to the Catalogue Service for the Web (CSW) or loaded from local caches. The services registered in CSW are OGC WPS-compliant geoprocessing services. An example of the service description is shown in Fig.3. Over one hundred geoprocessing services are already available in GeoPW. GeoPW is an open WPS service toolkit developed by State Key Laboratory for Information Engineering in Surveying, Mapping and Remote Sensing (LIEMARS), Wuhan University, China. Therefore, these geoprocessing services serve as the service toolkit. The GUI is developed using AJAX technology. Geoprocessing 1 2
http://www.extjs.com http://www.draw2d.org/draw2d
model information is extracted from visually constructed geoprocessing workflow models. Currently, there are many JS graphic libraries that can be used. Among those, ExtJS1 (A JavaScript library for framework and RIA platform) and Draw2DJS2 are widely applied to develop visual client interface. This work adopts both of the two JS library to realize the GUI of the geoprocessing model builder. The client GUI has three main pages: graphic model builder, abstract model manager, and deployed workflow manager, which can help users to drag and compose atomic services into a geoprocessing workflow model, describe it using XML and manage the generated abstract models.
Fig.3. Extracted service information
As the programming code running on client is compiled in JavaScript and it is difficult to import JAR libraryies when external functions are needed, JAVA Servlet is used. The Web applications developed at the Web server define service interfaces by using JAVA Servlet technology and implement
the model transformation and deployment of workflow packages using JAVA classes. Specific syntactic elements in BPEL such as partnerlinks are automatically added in the final workflow by semantic meaning conveyed in the abstract model. The modules implemented by using JAVA Servlet make them Web accessible and loosely-coupled. These models then act as services. Using these services, abstract models can therefore be materialized into executable workflows on invocation of services. The workflow package can be submitted to the service to deploy itself into a running workflow engine to provide additional complex geoprocessing service [8].
Fig.4. Flood analyze scientific theory's sketch figure
IV. RUNNING EXAMPLE A flood analysis example is used to demonstrate the approach proposed in this paper. The flood analysis example selects six images in three periods——before, in, after the flood. Two images in different wave bands for each period are needed, such as the first and second wave band images of MODIS in this example. In accordance with time, these images are divided into three groups. Each group goes through NDVI computation, binary, and coloring processes to evaluate
the range of flood in each period. Then three images in different periods are blended to get the resulting image for flood analysis. Because three images have different colors, the distinctions between three periods will be clearly displayed when they are blended (Fig 4.) [9]. Fig.5 shows the visual workflow model constructed in the GUI.The model is mapped into a concrete scientific workflow represented using BPEL and deployed into the ActiveBPEL workflow engine (Fig.6.). Users can invoke the workflows successfully deployed.
Fig.5. Geoprocessing service workflow model of flood Analyze
The invocation result is shown in Fig.7. The situation of flood in different periods can be observed clearly in the final image. V.
CONCLUSION
This paper describes the design and implementation of a geoscientific workflow tool by integrating the Web 2.0 and geoprocessing services. The design of workflows is based on a three-phase procedure: process modeling, process instantiation,
Fig.6. The graphical view of flood analyze's workflow model
and workflow execution. AJAX technology is used to develop user interface for construction of the logical flow. Users can drag and drop atomic processes manually in the Web browser-based user interface. The process instantiation and workflow execution are carried out on loosely-coupled services, so that the implementation is flexible and easily maintainable. The approach and experience provide valuable references for future development of Web-based geoscientific workflow systems.
Fig.7. Flood analyze result image and graphic symbol
ACKNOWLEDGEMENTS This work would not have been possible without the support of many persons.Thanks very much to my tutor,Professor Peng Yue, who gives me so many advices and directs me to a more available way. Also thanks to some of my classmats, Mr.Sun,Ms Wang and Ms Fang, who offered me help on solving technology and other problems.Finally,thanks to my parents,and numerous friends who accompany with to go through this long course and always provides me with support and love. REFERENCES [1]
[2]
G. Allen, G. Lemoine, F. Thoorens and L. Bruzzone, "Towards an integrated GIS-based coastal forecast workflow," IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing, vol.2(1), pp. 33-46, 2009. J. Lim, K. Lee, "Constructing composite web services from natural language requests," WebSemantics: Science, Services and Agents on the World Wide Web 8, pp. 1-13, 2010.
[3]
[4]
[5]
[6]
[7] [8]
[9]
R. Barga, J. Jackson, N. Araujo, "The Trident Scientific Workflow Workbench," In Proceedings of the 2008 Fourth IEEE International Conference on Escience , IEEE Computer Society, pp. 317-318, 2008. L. Di, P. Zhao, W. Han, Y. Wei, X. Li, "Web Service-based GeoBrain Online Analysis System (GeOnAS)," Proceedings of NASA Earth Science Technology Conference 2007, June 19-21,2007, College Park, MD,USA. G. Allen, P. Bogden, G. Creager, C. Dekate, C. Jesch, H, Kaiser, J, McLaren, W. Perrie, G.W. Stone and X. Zhang, "Towards an integrated GIS-based coastal forecast workflow," Concurrency and Computation: Practice and Experience, vol.20, pp. 1637-1651, 2008. P. Mangan, S. Sadiq, "On building workflow models for flexible processes," Australian Computer Science Communications,vol.24(2), pp. 103-109, 2002. OGC, OpenGIS Simple Features Specification For SQL Revision 1.1, Open GIS Consortium, 1999. M. Kradolfer, A. Geppert, "Dynamic Workflow Schema Evolution Based on Workflow Type Versioning and Workflow Migration," COOPIS,Proceedings of the Fourth IECIS International Conference on Cooperative Information Systems, pp. 104-115, 1999. A. Bradley, K. Potter, T. Price, P. Cooper, J Steffen, D. Franz, "Flood analysis in dupage country using hydrological simulation program-fortran model," Transportation Research Record, no.1471, pp. 41-46, 1994.
