High Level Requirement Specification

Executing Dynamic Services

Overview

When services are well defined and annotated it should be possible for the designer of the workflow to describe a service, and for Taverna to dymically discover and bind a given service that meets the description provided by the workflow designer.

Overall Goals

The ability to describe a required service, rather than manually select it from the Service panel within Taverna. The actual service should not be bound to the workflow until run-time, but the actual service used at runtime should be stated within the Provenance gathered.

Its possible an appropriate service cannot be found, and this should be conveyed back to the user a soon as possible. Because of this, service discovery should take place before the workflow runs, rather than attempting it as each service is encountered with the workflow.

The provenance gathered during the workflow execution should accurately record the actual service that was used (together with VersionLogging) for the provenance to be accurate and meaningful.

Assessment

Affected Components

Scufl Model, Taverna Workbench, Provenance, FETA

Key Tasks

• Service descriptions within Taverna, and recorded in the workflow Scufl Model.
• Service discovery at run-time.
• Handling being unable to find an appropriate service, and relaying this information back to the user asap.
• How to handle discovery of multiple service that suit the description, but are each differnt in nature ??
• Reporting to provenance gathering which service was actually used
• Modification to the Scufl Model for storing service description for discovery.

Appendix

Example – Runtime Service Binding

The dispatcher mechanism is also used to perform dynamic runtime binding to concrete services based on an abstract description. The set of worker implementations may include those marked as abstract – these may not be applied to jobs as is, but must be transformed into a concrete form first. By adding an additional enclosing layer either at the top level or below the failover layer in the example above, we can allow dynamic service binding. The layer in question would consume the set of worker implementations and either a job queue of a single job (no data processing is going to occur so it doesn’t care) and, for each implementation in the worker set marked as abstract, remove it and replace it with one or more concrete workers. This replacement operation would be driven by some kind of resource lookup, using a connection to a grid broker for example.

(Taverna v2 Aims and Vision, TomOinn^?)