High Level Requirement Specification

GUI/API separation

Reference	Techreq.ApiSep
Referenced Use-cases	OnDex LandscapeGenomics SystemsBiology NanoCmos MicroArray
Dependencies
Champion	DavidWithers
Status	PLANNED for 1.5

	Taverna 1.3	Taverna 2.0
Priority	2
Rough estimate	WEEK	ONGOING AS PART OF DESIGN PROCESS

Overview

A proposal to separate the GUI and the API, therefore allowing workflow invocation that is GUI independent. The workflow enactor could become a WSRF compliant service hosted within the OMII container. This not only means invocation is independent of the GUI and is able to be invoked by a scheduler, but also that invocation within the OMII container will benefit from the OMII security and authentication.

Overall Goals

Currently, the design and enactment of workflows in Taverna is mediated by the workbench. Results of distributed analyses are returned to the user�s desktop through the Taverna GUI which is required to be kept running. If a workflow is to run for several hours/days or weeks, this becomes impractical. Decoupling workflow enactment from workflow design will enable users to submit long-running workflows to a server.

The API should be extensible to allow a user with a knowledge of Java to easily adapt and extend the Taverna workflow enactment to meet their needs.

The API should include a flexible mechanism for gathering workflow results created during the workflow enactment (Provenace).

Since the workflows could be running remotely without direct control from the user, particular attention should be paid to ensure solid and meaningful error handling and reporting.

Assessment

High priority as it is a necessary change to allow better support for long running workflows. However, it exists for 1.4. Will continue to exist as currently scheduled work in 1.5 and we simply need to ensure that the unit tests come across into the test harness with the new enactor.

Workflows can be enacted from the API independently of the GUI. The WorkflowLauncher^? class provides a simple mechanism for doing this. However, any code that uses taverna's enactor would also depend on some gui code. This is mainly because the processors are implemented as modules that combine enactment and gui code.

Affected Components

Taverna workbench, Provenance

Key Tasks

• Define API
• Build Unit tests to 'lock' API
• For Taverna 1.3, refactor and implement API. This will probably involve writing 'wrapper' classes to enclose existing functionality.
• Generate functional tests that invoke some workflows outside of the Gui.

Appendix