Title: Workflow Components Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Taverna Workflow Components are a system for creating shareable, reusable, encapsulated sub-workflows that perform clearly defined tasks while abstracting the details of how those tasks are performed. They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4.
Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components, along with 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. These requirements are based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE.
The requirements include:
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:
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. 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 components are only plugged together in a sensible manner, and for the discovery of (and connection to) suitable components based upon existing workflow structure.
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. The user sees the component invocation as a ‘black box’ and cannot see details of what happens inside.
If you publish a workflow containing a component, you must make sure the component is publicly readable in a globally-accessible component registry; myExperiment is such a suitable registry.
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.
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.
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.
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.
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.
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.
