High Level Requirement Specification

Long running workflows

Reference	Techreq.LongRunningWorkflows
Referenced Use-cases	LandscapeGenomics SystemsBiology MicroArray
Dependencies	ApiSep TavernaGridService CheckPoints TavernaPortlet
Champion	DavidWithers
Status	ALLOCATED to Stuart

	Taverna 1.3	Taverna 2.0
Priority	1
Rough estimate

Overview

Currently, to run a workflow over several weeks, the user must keep the Taverna GUI open and in the event of a disconnection, the workflow must be restarted. In order to better support long running workflows, the client/server architecture needs to be separated users need to be able to resume workflows from checkpoints.

This proposal encompasses several others; separation of the GUI from the enactor, the ability to submit and run workflows on a server (perhaps as a grid service), the ability to notify the user when a workflow has finished, the ability to provide CheckPoints and resume from a saved point in the event of a failure, a mechanism for transferring results back to the user (perhaps through the workbench)

Overall Goals

The goals of grid service and TavernaPortlet will meet the goals of this requirement.

Assessment

This is the real requirement behind the portlet, web service and api separation.

Affected Components

Taverna workbench, Enactor

Key Tasks

Appendix

• OMII component GridSAM is a job submission and monitoring web service that should be used as a starting point.
• Job Submission Description Language (JSDL) is the XML sent to GridSAM^?. We'll need to extend this to put in the workflow and workflow input data. We could possibly provide the inputs as a Baclava XML (input) document, and/or support some kind of referencing for either pipelining (between two workflows, for instance) or large data sets (OGSI-DAI).