High Level Requirement Specification

Ability to use Checkpoints within Taverna

Reference	Techreq.CheckPoints
Referenced Use-cases	OnDex
Dependencies
Champion	Tom Oinn
Status	DEFERRED

	Taverna 1.3	Taverna 2.0
Priority		6
Rough estimate	MONTH(S)	WEEK(S) (assuming Taverna2.0 architecture supports it)

Overview

Checkpoints extend the current implementation of breakpoints within Taverna. As well as being able to mark a breakpoint in a workflow, marking checkpoints causes the workflow to store its current state at the checkpoint. This would allow a workflow to be resumed from this saved state at a later date, useful in the event of failure or should something change that would make re-running the workflow from this point interesting.

As an expansion to this requirement the ability for Taverna to automatically 'Checkpoint' in the event of failure would be useful.

This has a likely impact on Provenance gathering, as the provenance gathered needs to be meaningful despite a workflow only being partially executed (either before or after the checkpoint).

Overall Goals

Allow the user to set 'checkpoints' within the workflow and mark them within the Scufl Model.

Whilst marking the checkpoint, guidelines should be provided to how the workflow state is serialized (e.g. to a database, or to a file). This mechanism should be flexible and extensible as it may differ depending upon how Taverna is deployed (e.g. running on the users desktop, or running on the TavernaPortlet).

Checkpoints should be honoured regardless of whether the workflow is running within the Taverna GUI or seperate to it.

Assessment

To progress this requirement, we'd have to go back to ondex and find out exactly how they intended to use this feature. The only requirement we can see at the moment would be to cancel a whole workflow which is covered by the new T2 architecture anyhow.

Affected Components

Taverna Workbench, Enactor, Provenance

Key Tasks

• Update UI to allow the marking of Checkpoints within the workflow.
• Design and implement a default mechanism and API for storing the workflow state, allowing the ability for new mechanisms to be added later (either by the Taverna development team or a third party). Typical examples are to a file, or to a database.
• Update the workflow model to allow its state to be perfectly retrieved or restored at any given moment.
• Update the workflow model to allow the inclusion of persistant, previously defined checkpoints
• Update the Enactor to allow a workflow to be run from a given point and a given workflow state.

Appendix