Construct & Deploy Workflow

Back to the Transverse Technology Use Cases list.

Brief description

Role and purpose: this use case describes the conditions and steps to configure and deploy workflows, consisting of one or more services.
The complete use case document can be downloaded from here (file size 3.6MB, MS Word document). 

Basic flow of events


 Construct and Deploy Workflow


 This is a walkthrough for designing a workflow, deploying a workflow, and executing a workflow. The document aim at capturing the alternative approaches to design, deploy, and execute a workflow. The workflow can be described in Business Execution Language (BPEL), Sensor Markup Language (SensorML), and any other script languages. The first case shows the workflow defined by using Business Processing Execution Language (BPEL). Two designing approaches are to be accounted for. One is the concrete BPEL workflow that can be designed using standard BPEL designer, such the Oracle BPEL designer. Another is the abstract model. Semantic was supported through geospatial ontology. The abstract model is then instantiated through an instantiation service to create the working workflow on the fly. The use case for the desinging, deploying, and exceuting of a concrete workflow is completely discussed here.

 Actors and Interfaces


1.       A scientist – In this case, the severe weather algorithm and knowledge were developed by a domain scientist.

2.       A developer – The developer was responsible for the architecture design and implementations of geospatial Web services and chaining them together to form a workflow to accomplish the processes of complexity by aggregating relatively simple components.

3.       A workflow visual design tool – Normally, visual design environment is desirable during the design phase of workflows. The major benefit is the tight link between architecture models and the actual codes generated under the visual models. This gives a feeling of seeing what you are modeling.

4.       A workflow engine – The workflow engine is the engine which executes the scripts generated using the workflow models.


1.       Scripting language - This use case is based on the approach of using Business Process Execution Language as the workflow scripting language.

2.       Web services – A Web service should described by a Web Service Description Language (WSDL).

3.       Web Processing Service – This is a geospatial Web service with standard OGC-specific interfaces.

4.       Web Coverage Service – This is a geospatial Web service with standard OGC-specific interfaces.

5.       Web Feature Service – This is a geospatial Web service with standard OGC-specific interfaces.
6.     Web Map Service – This can be seen as a simple support of browser-based thin client.

Initial Status and preconditions

  • Data – Data or observations from sensors are rudimentary format and projection. Further processing is required to generate useful information for decision-makers.
  • Algorithms – The algorithms may be in abstract description. The algorithms needs to be implemented as geospatial Web Processing Processes in order to re-use them in different workflows.
  • Standard Web Services - Individual working Web services. For the specific use case of severe weather detection, we have a Web Feature Service that supports transaction, a Web Coverage Service for serving GOES data, a Web Processing Service for the severe weather event detection algorithms.


(basic flow steps)

The following are the main three stages.

Stage 1: Designing the service using a BPEL designer
Stage 2: Deploying the workflow into a BPEL engine
Stage 3: Executing the workflow
The workflow can embed the steps to inject the results into standard, persistent storage services through their transaction capabilities, such as Web Feature Service (WFS) and Web Coverage Service (WCS). Web Map Service can access the data from WFS or WCS to generate maps and display the results in browsers.
The details and scripts can be found at here (file size 3.6MB, MS Word document).

 Post Condition

1.       Data are served through standard geospatial Web services. The data are managed by WCS and WFS
2.       Algorithms are wrapped into a standard process and managed under the Web Processing Service.
3.       A composite service (or a workflow) can be executed.
4.       The results are described in Geography Markup Language (GML) that can be shared across and supported widely by software platform.    

Alternative flows of events


Special Requirements