Taverna Workflow Components are a system for creating shareable, reusable, encapsulated sub-workflows that perform clearly defined tasks while abstracting away from the details of how those tasks are performed. They are an integrated feature of Taverna Workbench 2.5.0 and Taverna Server 2.5.4.
As part of the BioVeL and SCAPE projects, we have developed a system of service components for Taverna. This consists of tools for the creation, management and use of workflow components, and a repository for the storage and sharing of those components. Workflow components within a given component family will work together cleanly, for example by adhering to a tidy type system and being well described.
A set of minimal functional requirements for service component management has been developed based upon previous component-related work carried out as part of the e-Lico project and also an examination of the needs of BioVeL and SCAPE.
These requirements include:
- The ability to create components
- The specification of the characteristics that are necessary for a set of components to ‘play’ together – called a ‘component profile’
- Creating a component so it complies with a given profile
- Checking that a component complies with a given profile
- Publishing a component
- Discovering a component
- Including a component in a workflow
- Executing the component within a workflow run
Example
This is an example workflow that includes components, with internal ports hidden for simplicity:
Without components, using the same view, it would instead look like this:
Including a component in a workflow
A component can be added into a Taverna workflow in the same way as an ordinary service, by dragging it from the service panel of the workbench into the workflow design view. Note that although it may be realized internally as a workflow, a user sees it as a ‘black box’ and cannot (normally) edit the component’s workflow.
It is intended that there will be consistency checks to ensure that components are only plugged together in a sensible manner, and for the discovery of and connection to suitable components based upon existing workflow structure.
Executing a component in a workflow run
When a component is invoked during a workflow run, the underlying workflow is called with the corresponding data. The results of the workflow are used as the output data for the component invocation. Note that the user sees the component invocation as a ‘black box’ and cannot see details of what happens inside.
Note that if you publish a workflow containing a component, you need to make sure that the component is publicly readable in a globally-accessible component registry; myExperiment is such a suitable registry.
Component creation
It was decided that the majority of the information necessary for a component will be specified as a Taverna workflow. This allows complex internal component functionality and removes the need for extensive new software to design components.
Component profile
A specification of the format for the component profile has been agreed. The format is in XML and an XML schema (xsd) has been created. An example component profile is available. Components that share a profile will be collected together into component families. A component profile editor is being developed.
The SCAPE project has an extended discussion of component profiles available.
Component creation against a profile
In order to conform to a component profile, it can be necessary to make semantic annotations parts of the corresponding workflow. For example, the annotation of the type of format in which data is output by a port or a service with the task it performs.
The component profile specifies the ontologies that will be used for the components within the family, the correspondence between object classes within a workflow (input port, service etc.) and the concepts within the ontologies.
Checking a component against a profile
Although the components will be modified using a chosen profile, it is unlikely that the components can be assured as being ‘correct by construction’. For this reason, a separate component validator is being implemented. The component validator is included within myExperiment.
Publishing a component
Since components are realized as ‘extensions’ to Taverna workflows, it was decided that rather than using a separate component repository, the extensive capabilities of myExperiment would be used. Thus a component is currently published and shared on myExperiment as (a pack containing) a workflow. The components themselves are items within a pack corresponding to the component family.
To facilitate the development of components, a workflow can also be saved to the user’s local machine.
When a user publishes a component either to myExperiment or to their local file system, their service panel is updated to reflect the new component.
Discovering a component
Since component families are realized as packs on myExperiment (or by analogous structures in the user’s file system), we use the existing Taverna code to talk to the myExperiment REST interface to give users access to families of components. Users can then see the discovered families of components via the Taverna Workbench service panel, and the components within those families. A component can then be added to a workflow.
