Dynamic and Interactive Execution and Visualization of Distributed Workflows
The Grid 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 GWES coordinates the composition and execution process of Grid or SOA workflows. It implements a highly dynamic workflow concept by means of the Grid Workflow Description Language (GWorkflowDL), which is based upon the theory of high-level Petri nets. It provides interfaces to the Web Portal and to a command line client for user interaction and to the low-level Grid Middleware for the invocation of application operations.
The main purpose of the Grid Workflow Execution Service and its client interfaces is to enable users to automatically execute workflows on distributed resources without being bothered with implementation-specific details, putting more attention to the functionality of the workflow itself. Therefore the Grid Workflow Execution service provides methods to initiate and analyze Grid workflows, and to coordinate and optimize the execution of these workflows on distributed and inhomogeneous resources regarding the control as well as the data flow. Abstract operations are automatically mapped onto matching software and hardware resources, triggering web service operations, remote executions of programs, or file transfers. The workflow service supports pure Web Services and Globus Toolkit 4, and it is easily extendible for further execution platforms, such as UNICORE, Condor, GRIA, and SUN Grid Engine, allowing reusing existing workflows on different Grid middleware.
For further information about the Grid Workflow Execution Service please refer to:
The Grid Workflow Execution Service is deployed as a standard Web Service, so it seamlessly integrates into common system architectures. There is a strict separation of the enactment machine and its client interfaces. The graphical user interface is realized by a set of Java Applets and Servlets which can be easily integrated in generic or application-specific web portals. In addition there exists a command line client program that implements the full set of workflow management features and which simplifies the integration into legacy frameworks.
These are the basic steps for deploying the GWES as a Web Service:
${CATALINA_HOME} to the top level folder of Tomcatgwes.properties, rft.properties and log4j.properties
in the folder ${CATALINA_HOME}/webapps/gwes/WEB-INF/classesgwes and corresponding users to the tomcat users file at ${CATALINA_HOME}/conf/tomcat-users.xmlThe GWES supports TSL/SSL security with client authorization based on X509 certificates. The security layer is optional, so if the GWES clients and server are behind a firewall you may prefer the default configuration without security layer. Please note, that the documentation about the GWES security is not part of the open source distribution. If you need assistance in setting up the security layer, please contact andreas.hoheisel@first.fraunhofer.de.
Depending on your requirements, you may need to deploy and configure additional services, such as the eXist database, the Resource Matcher, the Resource Updater and the Linux Toolbox. For details please refer to the GWES User Manual or contact Fraunhofer FIRST to get an offer for the configuration of your system.
The main scientific achievements include the definition of a theoretically well founded Workflow Description Language, which is very simple but expressiveness at the same time, using the well-known concept of high-level Petri nets. With this approach we are able to model arbitrary algorithms, including parallel branches or loops. Transitions can possess conditions that we express using the XPath 1.0 syntax.
In order to make the workflows persistent, the execution service uses a native XML database for storing snapshots of the workflows including the workflow's state, which is represented by the marking of the corresponding Petri net. The system provides a simple and robust checkpoint-restore functionality and the user may initiate each of these snapshots as a new workflow instance. Another scientific achievement is the overall concept of iteratively mapping abstract workflows onto concrete resources, taking into account the most current monitoring information. Each of the abstraction levels uses the same workflow description language, so it is possible to mix several levels of abstraction in one workflow.
