An asynchronous Geoprocessing Workflow and its application to an Antarctic ozone monitoring and mapping service

Abstract

The integration of Sensor Web Enablement services with other Open Geospatial Consortium (OGC) Web Services as Geospatial Processing Workflows (GPW) is essential for future Sensor Web application scenarios. With the help of GPW technology, distributed and heterogeneous OGC Web Services can be organized and integrated as compound Web Service applications that can direct complicated earth observation tasks. Under the Sensor Web environment, asynchronous communications between Sensor Web Services are common. We have proposed an asynchronous GPW architecture for the integration of Sensor Web Services into a Web Service Business Process Execution Language workflow technology. We designed a Sensor Information Accessing and Processing workflow, an asynchronous GPW instance, to take an experiment of observing and mapping ozone over Antarctica. Based on our results, our proposed asynchronous workflow method shows the advantages of taking environmental monitoring and mapping tasks.

Keywords:

• Sensor Web
• OGC Web Service
• asynchronous workflow
• OMI
• ozone monitoring

1. Introduction

1.1. OGC Sensor Web Enablement (SWE)

Butler (2006) indicates that ‘scientists can ask new questions or test hypotheses under Sensor Web.’ The Sensor Web is a revolutionary concept that may achieve collaborative, coherent, consistent, and consolidated sensor data collection and fusion within a World Wide Web (WWW) environment. In that system, geophysical information or environmental conditions at various locations can be monitored by various types of sensors used in collaboration with each other, with the purpose of sensing, collecting, and processing the perceived object information in network coverage of the geographic area (Chhetri, Morrell, and Papandreou-Suppappola 2007).

The SWE specifications were formulated by the Open Geospatial Consortium (OGC) and the International Standardization Organization; they are the standards and protocols for the geospatial Sensor Web. The goal of SWE is to provide an integrated sensor network in which all types of remote sensing satellites, ground sensors, handheld devices, imaging devices, and repositories of observation data are discoverable, accessible, and, where applicable, controllable via Web technologies and standards. As a developing community, the SWE is adopting prevailing standard techniques and rejecting outdated ones. Currently, the main adopted or pending OGC standards in the SWE framework include Sensor Model Language (SensorML; Botts and Robin 2007), Observation and Measurements (O&M; Cox 2007a, 2007b), Sensor Planning Service (SPS; Simonis 2007), Sensor Observation Service (SOS; Na and Priest 2007), and PUCK (Tom 2012). SWE also covers other standards that are under discussion or in various stages of development, e.g. Event pattern Markup Language (Everding and Echterhoff 2008), Web Notification Service (WNS; Simonis and Echterhoff 2006), and the Sensor Alert Service (Simonis 2006).

1.2. Service chaining for geospatial Web Services

An important trend of geospatial information development is the increasing deployment of geospatial data and processes as online-accessible geospatial Web Services, which are enhancing the interoperability of geospatial information. The collaboration of geospatial Web Services as workflow could be briefly called Geospatial Processing Workflow or Geoprocessing Workflow (GPW). GPW can follow a Web Services orchestration process that could achieve the design and execution of a complex geospatial processing task across domains and applications (Butt and Li 2012). The orchestration of GPW is one of the promising major research areas for enabling Web-based geospatial information (Brauner et al. 2009).

Under the Sensor Web environment, the GPW technology is widely applied in the organizing of distributed Sensor Web Services and transactional processing services to generate live geospatial Sensor Web data service chains for environment monitoring, e.g. wildfire monitoring and hydrologic monitoring (Chen et al. 2010a; Zheng et al. 2013; Li et al. 2014). OWS-6 discusses interoperability among geoprocesses through service chaining, workflow, and Web Services. Yang, Chen, and Di (2011) present a RESTful-based Web resources interoperation architecture for collaborating heterogeneous workflow (Web Services) resources. In recent developments of OWS-7 and OWS-8, the GPW work model can play an important role in real-time or near real-time on-demand motion video change detection by using the existing Sensor Web Service (Chen et al. 2011). Thus, the GPW can stimulate new thinking and provide a method for environment monitoring through the discovery, retrieval, and processing of sensor observation information.

1.3. Problems and innovations

Under the Sensor Web environment, the Web Services often face the problem of asynchronous communication (Zyl, Simonis, and McFerren 2009). When we use workflow technology to integrate the asynchronous Web Services as an asynchronous GPW instance, the main obstacles arise from the two separate parts: the diverse asynchronous implementation methods in Web Services are hard to integrate into a GPW, and the different asynchronous models in Web Services are difficult to correlate.

At the transport level, a branch of an asynchronous transport standard, such as Java Message Service, Web Service Invocation Framework, Java API for XML Messaging, or Reliable HTTP (Zdun, Voelter, and Kircher 2004), can support the asynchronous communication of Web Services. At the message level, there are four main asynchronous communication methods: ‘fire and forget,’ publish/subscribe, polling, and result call-back. In most enterprise Web asynchronous applications, the asynchronous call-back message is used to invoke the asynchronous Web Service request/response. The asynchronous call-back invocation comes with a series of Web specifications, such as Simple Object Access Protocol (SOAP), Web Services addressing (WS-addressing), Web Services Description Language (WSDL), and so on.

Because there are various OGC Web Services in the service architecture, we need to design a unifying asynchronous correlation architecture that can achieve asynchronous communication between Web Services and the workflow engine. In this paper, we propose a Web Service Business Process Execution Language (BPEL) workflow architecture and WNS asynchronous communication method to correlate the OGC Web Services as an asynchronous GPW. The proposed method is significant in an asynchronous ozone monitoring process made up of a series of Sensor Web Services and other OGC services.

1.4. Organization

We describe our proposed Asynchronous GPW architectural components in Section 2. The implementation of asynchronous GPW is presented in Section 3. Section 4 gives a case study of asynchronous GPW in an Antarctic ozone data processing and mapping experiment. The benefits of the proposed method are discussed in Section 5. Finally, Section 6 summarizes this paper and presents the outlook for the future.

2. Asynchronous GPW design

2.1. Asynchronous GPW framework

A general asynchronous GPW architecture should be aware of the asynchronous communication in its Web Services part and of asynchronous invocation operations. As shown in Figure 1, the architecture of this proposed asynchronous GPW framework consists of three parts: a Web Services layer, an asynchronous correlation layer, and a Workflow layer. The Web Services layer is the collection of all Web Services resources related to the GPW instance. The asynchronous correlation layer is our asynchronous communication middleware that correlates work between Web Service layers and the Workflow layer. The Workflow layer is our workflow engines; each workflow engine has a Database Management System for managing the WSDL, the profiles of the Web Services and workflow process files, and a Web Portal for serving the workflow process as standard Web Services.

Figure 1. Asynchronous GPW architecture.

2.2. Asynchronous pattern of OGC Web Services

In a synchronous Web Service interaction model, a client issues a request to a Web Service and holds the thread, awaiting a response. This type of request-response communication model needs to contend with Web Service delays or failures (Brambilla, Guglielmetti, and Tziviskou 2005). Because most Sensor Web operations are time-consuming, the latest OGC 09-001 Service Model Implementation Standard specifies the SOAP mechanism to support asynchronous communication for all SWE Web Services. Most OGC Web Services are not designed with extensive asynchronous support to facilitate long-duration processing (Zhao, Di, and Yu 2012). Thus, the OGC Web Service does not list asynchronous support as standard configurations.

2.2.1. WNS-based asynchronous middleware

OGC develops the WNS standard as a generic asynchronous communication mechanism for OGC Web Services that need asynchronous support [Min 2008]. WNS supports two types of asynchronous communication methods for OGC Web Services without asynchronous support: one-way communication and two-way communication. The ‘one-way notification’ model simply passes notification messages for one-way communication. In the ‘two-way-communication’ pattern, WNS sends the message and can receive a ‘call-back’ response. Therefore, WNS can be useful when a Web Service is required to satisfy a client request and/or when significant delays are involved in satisfying the request.

Based on the WNS Web Service, we designed WNS asynchronous communication middleware. It has four functional components: Register, Invoker, Parser, and Call-back. The Register component notes the client's request and assigns it a correlation identifier (ID); the ID is unique so as to recognize the requestor when a response is returned. The Invoker component sends service requests to the server. Its initial request includes the requested server's URL, and the requested services are sent by the client through the Register. The initial request can also be used by the Parser in later action. The Parser component reads and interprets XML-based responses from the server and sends the results to the Invoker to poll the server again or to the Call-back component to process. The Call-back component sends the parsed response to the specified call-back URL with the unique task correlation ID.

2.2.2. SOAP-based asynchronous communication

The SOAP asynchronous support for OGC Web Services was adopted in two models: the publish/subscribe model and the SOAP binding model. The publish/subscribe model is distinguished from the request/reply and client/server models by the asynchronous delivery of messages and the ability for a subscriber to specify an ongoing (persistent) expression of interest. The SOAP binding model plays an important role in the communication mechanism for Web Services; it provides a standard packaging structure for transporting XML documents using a variety of standard Internet technologies, including SMTP, HTTP, and FTP.

Under the prevailing Service Oriented Architecture (SOA), the WS-* specifications are widely applied in augmenting support for Web Services' operation. The publish/subscribe model can be implemented with the WS-Notification standard, which can provide decoupling between notification publisher and subscriber. The HTTP POST/GET communication model is applied in all of OGC Web Service's operations. The SOAP binding in an HTTP request can be in both POST and GET requests. The WS-addressing standard can describe the call-back message in the ‘head’ part of a SOAP envelope, which inserts the asynchronous call-back information when requesting the service via an HTTP request.

2.3. Asynchronous GPW technology

2.3.1. OGC Web Services orchestration

Workflows, or chains of Web Services, have been widely applied in integration of geospatial Web Services for a high-level geoprocessing operations (Di 2005). Workflows are based on Web Services invocations and its descriptive language for organizing and coordinating these services. In an orchestration workflow model, all Web Services are directed by a central control process, which coordinates the execution of different operations in the Web Services. This orchestration workflow model will be effective in constructing an GPW:

1. The coordination of Web Services is centrally managed by a specific coordinator.

2. Web Services are loosely coupled and only invoked when they are occupied.

3. Alternative Web Services can be put in place in case the corresponding service is down.

Among various Web Service workflow standards, the BPEL is the prominent and dominating industry standard executable language for orchestrating Web Services into business processes. BPEL defines ‘receive,’ ‘reply,’ and ‘invoke’ for the control of basic workflow process unit ‘Activities’ that direct the interoperation of different Web Services. BPEL meets the demands of a programming language with some of its properties, such as loop (while), algorithm branch (switch), and definition of variables.

Under the organization of the BEPL script language, an entire workflow can be designed by orchestrating the Web Service operations in a particular order: a ‘partner link’ element that presents a Web Service receives messages from clients, and a message is passed from ‘Activities’ to a ‘partner link’; the message is controlled by a BPEL script. For example, partner link A (SOS) encodes as specified by OGC's O&M for observation data; after this activity, the data reference will be handled as a message and passed to partner link B (WPS) for later information processing. The BPEL workflow adopts a standard Web Service, so the BPEL process allows programmatic invocation and can be interpreted by other BPEL engines.

2.3.2. Asynchronous GPW operations

Here we illustrate how the BPEL script organizes the asynchronous OGC Web Services as an asynchronous workflow instance. For WNS-based asynchronous OGC Web Services, e.g. SPS 1.0 version, the BPEL workflow engine can invoke the SPS for the task and receive the one-way notification message after the task is finished; for the WNS-wrapped asynchronous OGC Web Service, e.g. WPS 1.0 version, the BPEL engine need adopts WNS as a two-way communication tool to deliver, receive, and process notifications to and from WPS. Delivery and asynchronous receipt notifications should be inserted into and handled properly by BPEL workflows to assure the proper flow of messages that control the execution of workflows. For the natively SOAP-based asynchronous OGC Web Service (the latest version of SWE Web Services such as SOS 2.0), the situation is much simpler. Most BPEL design tools and execution engines have built-in support for WS-addressing; thus, asynchronous Web Services can be invoked by setting the call-back URLs of workflow instances.

Figure 2 shows the invocation mechanism of WNS-based asynchronous SPS 1.0 operations in a workflow instance. After task enrolls in WNS, SPS invokes WNS to deliver a message when a sensor observation task is completed, whether it succeeds or fails. The notification is wrapped in a <NotificationMessage>. The process, expressed in BPEL, can react according to the notification. Figure 3 shows the BPEL invokes a WNS-wrapped WPS 1.0 instance: the Invoke module invokes the WPS's task; the parse module obtains and parses the response from WPS, and the service repeatedly invokes a middleware request with the same task identity until the entire WPS operation completes; then, an asynchronous notification of success is sent back to the client's registered call-back address by the notification module. Figure 4 shows the asynchronous invocation process of an SOS 2.0 instance that supports a SOAP binding HTTP operation. The BPEL engine acts as client to invoke the asynchronous SOS operation and receives the call-back message with WS-Address URL in SOAP ‘head’ element (Figure 4).

Figure 2. Invoke WNS-based SPS 1.0 operations.

Figure 3. Invoke asynchronous WPS 1.0 operations with WNS.

Figure 4. Invoke asynchronous SOS 2.0 operations with SOAP.

3. Implementation of asynchronous GPW

3.1. Asynchronous SIAP instance design

In this part, we have designed a SIAP (Sensor Information accessing and processing) GPW instance to provide the operation of sensor planning, discovery, sensor data access, and data processing. We use Eclipse BPEL designer tool to build the whole processes by designing a diagram. The SIAP workflow instance consists of an instance each of SPS 1.0, SOS 2.0, and WPS 1.0.

As it is shown in Figure 5, the SIAP workflow steps are as follows: after user's observation request to active the SIAP instance, the observation parameters would be past to ‘GetFeasibility’ to check whether the task can be available, then the BPEL engine will trigger the SPS ‘Submit’ operation and receive the notification message from WNS when the sensor data are ready. The observation data are encoded by invoking the ‘InsertObservation’ operation of SOS. The information will then be inserted into a database that connects with the SOS service's ‘GetObservation’ operation. The WPS ‘Execute’ operation is then assigned for further processing, and the final processing result URL will be sent by WNS; the BPEL engine would parse the result URL and forward it to the user.

Figure 5. Diagram design of SIAP workflow.

3.2. Deploy the SIAP workflow with the OGC Web Services components

3.2.1. SPS for observation task planning

The SPS service authorizes the user to access sensor observation information in an area of interest or at a special time and can meet requests for dynamical sensor information retrieval. There are eight SPS operation interfaces: ‘GetCapabilities,’ ‘DescribleTasking,’ ‘Submit,’ ‘DescribleResultAccess,’ ‘GetFeasibility,’ ‘GetStatus,’ ‘Update’ and ‘Cancel.’ In the SPS 1.0 version, SOAP is not supported for the asynchronous operations.

The operations of SPS in BPEL workflow are as illustrated in Figure 6: the BPEL engine receives the task from user and then invokes ‘GetFeasibility’ operation to check whether the task can be done and then send the task information back. After the ‘GetFeasibility’ operation, the BPEL script will invoke the ‘Submit’ operation to start the planning task. After the task is finished, the URL formed message will be sent by WNS, and BEPL engine will receive the notification message.

Figure 6. List of SPS operations in BPEL.

In the SPS 1.0 instance, the WNS has built-in support for the asynchronous notification. The message can be interpreted in the BPEL engine.

3.2.2. SOS's operations for observation result storing and serving

SOS has three mandatory core operations (‘GetCapabilities,’ ‘DescribeSensor,’ and ‘GetObservation’) and two optional transactional operations (‘RegisterSensor’ and ‘InsertObservation’). The three mandatory core operations are used to help the consumer discover and retrieve sensors and observations; the two optional transactional operations are used to assist the provider to register sensors and observations. SOS 2.0 adopted Key Value Pair binding and SOAP binding for all operations. Thus, the BPEL engine can directly invoke the SOS's operation – no matter whether it is asynchronous or not.

In the SIAP workflow instance, BPEL engine invokes two SOS operations: ‘InsertObservation’ and ‘GetObservation.’ The asynchronism of SOS is mainly embodied in the ‘InsertObservation’ transaction operation. The SOS needs to store the observation data before serving it. The asynchronous SOS ‘InsertObservation’ operation had been illustrated in Figure 7. After that, the BPEL engine invokes the ‘GetObservation’ operation to direct the observation data to the WPS for the data processing operation.

Figure 7. List of asynchronous SOS operation in BPEL.

The SOS 2.0 instance will be invoked after the SPS ‘Submit’ task is finished. The SOS ‘InsertObservation’ is a typical asynchronous operation as the data transmission from Internet to the database often take a long time. BPEL support the both synchronous and asynchronous invoking through SOAP.

3.2.3. WPS for the data processing

The OGC WPS 1.0 service is a standardized interface that can be observed as an online-accessible GIS program for providing Web-based GIS computing resources. WPS can be configured to offer any GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. WPS has three operations: ‘GetCapabilities,’ ‘DescribeProcess,’ and ‘Execute.’ In this workflow instance, as it is shown in Figure 8, the WPS ‘Execute’ operation is invoked to process the data ‘assigned’ from SOS ‘GetObservation.’ The WNS offered the notification to the workflow engine after the WPS task is finished.

Figure 8. List of asynchronous WPS operation in BPEL.

The WPS 1.0 standard is lack of status check, so the WPS needs the WNS to polling the task status and report the BPEL engine when the task is finished.

After correlating all the services part, the BPEL engine would publish SIAP workflow WSDL file. The WSDL file of ‘SIAP’ workflow will define the receiving activity and messages based on the SIAP BPEL script file. The complete WSDL file of the SIAP workflow, as it is shown in Figure 9, presents the invoking interfaces of SIAP workflow, thus, the SIAP workflow can be invoked in HTTP method (like invoke a Web Service) or inserted in another workflow process.

Figure 9. WSDL description of SIAP workflow.

The WSDL description of SIAP shows the operation interfaces and parameters, which are essential when integrating the workflow instance into another process.

4. Case study: Antarctic ozone monitoring and mapping experiment

4.1. The Antarctica ozone hole monitoring mission

Snow-packed Antarctica is the coldest, driest, and most inaccessible continent on earth (Chen et al. 2010b). Recent studies have shown that, in the late twentieth century, depletion of stratospheric ozone by anthropogenic halogen compounds has affected the south hemisphere surface climate by forcing sea level pressure to decrease in high latitudes and to increase in mid latitudes (Thompson and Solomon 2002). Ozone plays an important role in atmosphere oxidation chemistry; it has harmful effects on both animal and plant life and contributes significantly to greenhouse gases. Climate records reveal warming trends in Antarctic regions that are more pronounced than in any other environment on earth.

The upper atmosphere in the Antarctica area has dramatic seasonal changes in ozone concentration. In the winter months, especially September and October, the concentration of ozone is extremely low, and its absence forms a large area called the ‘ozone hole.’ Under normal stratospheric weather conditions, the area of the ozone hole can be expected to vary between 8.9 and 9.3 million square miles, equal in size to South America. The largest ozone hole ever observed occurred on 24 September 2006, at 10.6 million square miles.

In our experiment, we adopted the Ozone Monitoring Instrument (OMI) sensor as our ozone observation data source. The OMI sensor on board the AURA satellite platform provides global scale coverage of ozone columns information. The OMI sensor data products are classifying in 4 levels: Level 1B, Level 2, Level 2G, and Level 3. In our experiment, the Level 3 data with a spatial resolution of 0.25 deg* 0.25 deg (13 km*24 km) is adopted. The AURA satellite is a near-earth satellite; it takes approximately 100 minutes to circle the earth and repeats one observation circle in 16 days. Due to limitations of the satellite scan area and range, some regions are not available for everyday monitoring even though the regions are under the satellite's track.

4.2. SIAP driven Antarctica ozone monitoring and mapping experiment

After integrating SPS, SOS, and WPS as our SIAP workflow instance, we used the BPEL service to direct our ozone monitoring experiment. The proposed SIAP workflow should direct an asynchronous and automatic ozone monitoring and mapping task containing three operation steps as follows:

4.2.1. Asynchronous ozone observation mission

First, we build our request to direct the SIAP operation. As Figure 6 shows, we submit an ozone observation request to the BPEL service page with the below parameters: ‘Sensor ID = urn:ogc:object:feature:Sensor:AURA:omi; Data Product = Level3; Data Format = KML; BBOX = –180, –90, 180, 90, Date = 20130917; Email = [email protected].’ These parameters, except ‘Data Format,’ will be interpreted in the JSP page and then trigger the BPEL engine to invoke the SPS ‘Submit’ operation. The ‘Data Format’ parameter will be applied in the WPS ‘Execute’ operation (Figure 10). The experiment date is 16 September 2013, and we expect the result to be forwarded to our email address asynchronously.

Figure 10. User request to trigger the Antarctica ozone monitoring workflow.

4.2.2. Access the ozone data

After the SPS's operation is finished, the SOS is invoked for accessing and publishing OMI data. After accessing the ozone data in the FTP server of the NASA Earth Observing System and Data Information System, the O& M and SensorML languages will be applied to describe the sensor information and the observation information, respectively; then the ozone data will be wrapped into the SOS database by the ‘InsertObservation’ operation, and the BPEL engine can invoke the ‘GetObservation’ operation to deliver the ozone data to the WPS for data processing.

4.2.3. Ozone data processing

In this system, the Geospatial Data Abstraction Library program is deployed in our WPS instance; it can provide various geospatial data processing operations. The WPS ‘Execute’ operation will translate the original GTIFF format ozone data to the KML format, and we can use Google Earth to visualize our processing result (shown in Figure 7). We can see the southern hemisphere (Figure 11), where the Antarctic Ozone Hole extends to cover even some area of South America.

Figure 11. South hemisphere ozone amount in 17 September 2013 (measured by OMI on-board sensor).

5. Discussion

The integration of SWE services as GPWs is a complicated but useful and important heuristic routine in nearly every phase of Open Web Service Technical Committee (TC) meetings. Many demonstrations have been carried out to show the superiority of the Web Service chain architecture: it is automated, reusable, service-sharing, and so on. In the Sensor Web environment, Web Services' temporal accuracy is uncertain; the Web Service chaining process needs support for asynchronous operation. In this paper, we discuss the basis of the technique and the operational method of organizing OGC Web Services as asynchronous GPW, which can be applied in the integration of Web Service operations for the integrated earth observation scenario.

5.1. Asynchronous support for OGC Web Services

The OGC Web Service standards support different types of earth observation operations and data resources. Within the Sensor Web environment, asynchrony is much discussed in a data-abundant, mass-processing, and Web Service world; this means that Web Services often involve asynchronous working conditions. For those OGC Web Services without asynchronous invocation support, we have developed WNS-based asynchronous middleware to direct asynchronous communication between the service and the user. Additionally, we introduced an asynchronous implementation method in the latest version of SWE services. With asynchronous support, OGC Services can operate time-consuming earth observation tasks via either notification or invocation.

In our ozone monitoring and mapping experiment, we used three instances of OGC Web Services to illustrate the working steps of a typical earth observation task: an SPS instance for ozone observation planning, an SOS for ozone information access, and a WPS for data processing. With asynchronous support, whether from WNS or SOAP, OGC Web Services can be correlated asynchronously in a GPW.

5.2. The BPEL-based GPW for an integrated earth observation scenario

When facing an integrated earth observation scenario, combining geospatial services is one of the promising major research areas for enabling Web-based geospatial information (Brauner et al. 2009). In this paper, we have adopted OGC Web Service interfaces and information models for retrieving and processing remote sensing data. The BPEL workflow standard helps the user or developer combine Web Services freely, yet in a loosely coupled way, to develop customized geospatial information applications.

The BPEL engine can direct the services' operations as a whole and can provide on-demand data service and can interact and chain together other services through standard operations. The current BPEL workflow orchestration model is a best practice for the collaboration of OGC Web Services despite some technical problems; for example, XML Schema definitions of WSDL lack a raw binary format to accept binary data (Yu et al. 2010). The BPEL-organized workflow also has a full description of WSDL and WS-addressing support, which can let the workflow combine and reuse existing Web Services for higher level, cross-organizational Web Services for various applications.

6. Conclusions and outlook

As Web Service technology develops, various OGC SWE Web Services and other OGC Web Services can be integrated via workflow techniques to provide a multifunction geospatial information operation. However, differences in service communication mechanisms, functions, and operations make it difficult to develop an asynchronous geospatial workflow to meet the requests of a real-time or near real-time environment monitoring task. This paper proposes a general asynchronous Sensor Web workflow pattern that can coordinate various distributed geospatial Web Services as a whole. The workflow exploits the proposed asynchronous processing functions in a dynamic Antarctica ozone observation experiment.

The development of semantic Web Service technology reveals the capability of the automatic discovery, access, and integration of Web Services as a Web Service chain (Yue et al. 2007). BPEL, as a business workflow, has advantages in intelligent process orchestration and smart logic control for complex processes and, therefore, is suitable for building a GPW. Still, there are other workflow standards or Web Service specifications that can adapt to the Web Service chaining scenarios. How to deploy diverse workflow resources for ontology interoperation among different architectures is still an outstanding issue; our future work will focus on the study of the ontology description of workflow resources and workflow collaboration under the resource-oriented architecture.