Generic Workflow Execution Service
Up-to-date information about the Generic Workflow Execution Service is availabe at the 
GWES software development site
Objective
The Generic Workflow Execution Service (GWES) is the workflow enactment engine originally implemented for the Fraunhofer Resource Grid, redesigned within the K-Wf Grid project, and enhanced for Enterprise Grids, Instant-Grid, MediGRID, BauVOGrid, TextGrid, and PneumoGRID. The Generic Workflow Execution Service is formaly known as "Grid Workflow Execution Service". With the implementation of a plugin concept for arbitrary workflow activities, it has now a broader area of application, not limited to the orchestration of Grid and Web Services. The GWES coordinates the composition and execution process of workflows in arbitrary distributed systems, such as SOA, Cluster, Grid, or Cloud environments. It implements a highly dynamic workflow concept by means of the Generic Workflow Description Language (GWorkflowDL), which is based upon the theory of high-level Petri nets. It provides interfaces to Web Portal frameworks and to a command line client for user interaction and to the low-level Middleware for the invocation of application operations.
Technology and Standards
The GWES is implemented using the programming language Java. The GWES parses
GWorkflowDL documents.
The GWES is based on the experience of the implementation and operation of the
Grid Job Handler developed within the
Fraunhofer Resource Grid by Fraunhofer FIRST in the years 2001 until 2004. The GWES constitutes a complete redesign of the main functionalities of the
Grid Job Handler with some major extensions and modifications regarding:
- Usage of the GWorkflowDL instead of the GJobDL
- Support of several levels of abstraction
- Delegation of the refinement and concretion process to the WCT, AAB, and the Scheduler
- Support of user interaction during creation and execution of the workflow
- WSRF-compliant
- Build on top of Globus Toolkit 4
Internal Mechanisms
The GWES possesses the following internal mechanisms and features:
- Analysis and verification of the workflow descriptions (e.g. endless loops, deadlocks, etc.).
- Act as a workflow engine, cycling through the workflow graph, searching for activated transitions, and triggering related activities.
- Optionally provide workflow checkpoint, restart, and rollback capabilities as long as the underlying application Web Service operations support transaction safety. The users may use the workflow rollback feature when creating or modifying workflows.
- Detection of conflicts within the workflow and delegation of workflow building decisions to the user via the Grid Workflow User Interface (GWUI) in case of conflicts or annotations that request user decisions.
- Invocation of the Workflow Composition Tool (WCT) if abstract workflow elements need to be mapped onto operations of Web Service classes.
- Invocation of the Automatic Application Builder (AAB) if operations of Web Service classes need to be mapped onto lists of concrete Web Service operations.
- Invocation of the Scheduler if a list of concrete Web Service operations needs to be mapped onto one instance of Web Service operation.
- Reliable invocation of target Web Service operations including fault management.
- Transfer of data from one Web Service to another as specified in the Grid workflow description.
- Controlling the execution of the Web Service operations and throwing workflow-related events to the Event System.
Whereas for the envisioned pilot operations it will be enough to have one centralized instance of the GWES, in principle it is possible to have multiple instances deployed on different sites realizing a distributed workflow enactment system, where each instance controls a separate sub-workflow of a Grid workflow. This is possible because the GWES itself can be regarded as an arbitrary Web Service application that may be invoked within a Grid workflow.
References
Yagsi
m.frincu