Skip to content
Permalink
Browse files

Taverna Component documentation

  • Loading branch information...
stain committed Jun 29, 2018
1 parent 00c2f06 commit 0f0b3b69892b281ac6c5cc485812b0c6220af99e
@@ -0,0 +1,26 @@
Title: Component profile editor
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.

The Taverna Component Profile Editor is a simple tool for editing and creating profiles for
[Taverna Components[(/documentation/components).
Component profiles define the required and supported interface of components;
they are not intended to be easily edited by normal users.
The editor guides an expert user as they define a profile,
showing features that they may use and providing assistance for defining semantic annotation requirements.

<div align="center"><img src="img/component-profile-editor.png" alt="Component Profile Editor" width="600" /></div>
@@ -0,0 +1,30 @@
Title: Component validator
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.

The Taverna Component Validator is a tool and library for checking whether a
[Taverna Component](/documentation/components) satisfies the component profile defined by the family of which it is a member.
It applies a number of checks to the component such that when they are all satisfied,
the component can be considered to be a high-quality member of the component family,
and provides human-readable descriptions of the conditions that are checked and whether they were satisfied or not.

![Summary of validity of a component, from myExperiment](img/ComponentValiditySummary.png)

We currently have the validator deployed on
[myExperiment.org](http://www.myexperiment.org) as an integrated feature of the metadata displayed about components.

![Detail of validity of a component, from myExperiment](img/ComponentValidityDetails.png)
Binary file not shown.
Binary file not shown.
BIN +74.3 KB doc/img/arch1.png
Binary file not shown.
BIN +93.3 KB doc/img/arch2.png
Binary file not shown.
BIN +11.6 KB doc/img/arch3.png
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN +44.7 KB doc/img/registry.png
Binary file not shown.
@@ -0,0 +1,161 @@
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.

[TOC]

## Overview
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.

## Requirements

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:

- 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

<img class="aligncenter" title="The Model of Components" src="img/registry.png" alt=""
width="433" height="251" />

## Workflows
### Example workflow with components

This is an example workflow that includes components, with internal ports hidden for simplicity:

<img class="alignnone" title="Componentized Workflow" src="img/component_b_1.png" alt=""
width="679" height="294" />

Without components, using the same view, it would instead look like this:

[<img class="aligncenter" title="Un-componentized Workflow" src="img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png)

### 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.
*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.*

<img class="aligncenter" src="img/arch3.png" alt="" width="500" height="401" />

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.

### 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.
*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.
## Components
### 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.

<img class="aligncenter" src="img/arch1.png" alt="" width="340" height="433" />

### 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](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml)
is available.
Components that share a profile will be collected together into component families.
A [component profile editor](/documentation/components/component-profile-editor)
is being developed.

<p style="text-align: center;">
<img class="aligncenter" src="img/arch2.png" alt="" width="359" height="412" />
</p>

The SCAPE project has an
[extended discussion of component profiles](https://github.com/openpreserve/scape-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](/documentation/components/component-validator)
is being implemented.
The component validator is included within
[myExperiment](http://www.myexperiment.org).

### 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.

0 comments on commit 0f0b3b6

Please sign in to comment.
You can’t perform that action at this time.