API Consumer
A kind of service that allows you to take an existing Java API and expose methods in that API as services in Taverna.
Beanshell
Beanshell is a Java scripting language. A Beanshell service in Taverna enables you to write simple Java code snippets and execute them as part of your workflows. Beanshells in Taverna typically perform data manipulation, parsing and formatting functions (so they are often types of shim services).
BioMart
A federated data warehouse and management system from the EBI (European Bioinformatics Institute) and the OiCR (Ontario Institute for Cancer Research). Biomart contains genomic, proteomic and any Biomart database if you provide the URL to the BioMart service interface (MartService). A BioMart service in Taverna allows you to query a BioMart database.
BioMoby
A collection of semantically described biological Web services. A BioMoby service in Taverna allows you to call a BioMoby Web service. Each BioMoby service is designed and registered to the BioMoby specification to improve interoperability between services. You can use the BioMoby annotations to discover which services consume the data types produced by other BioMoby services. BioMoby services differ from ordinary Web services in that these services consume and produce BioMoby objects, so in order to use a BioMoby service, you have to first define your data as a BioMoby object.
BioMoby object
BioMOBY objects represent valid data structures consumed and generated by BioMOBY services. Objects are serialised into XML as defined by the BioMOBY Object Ontology and add semantics layer to BioMoby Web services, despite not using the RDF or OWL standards.
Control layer
Taverna adds a control layer to every service in a workflow to provide users with more control over how a service is being invoked. This layer enables users to add a loop around a service in order to invoke it several times, until a certain condition is met. It also allows user to define how a service should handle incoming list items where 2 or more lists are being passed to the service on two or more different ports. In future, it will also include defining an alternate service of similar/equivalent functionality to replace the original one in a case of failure.
Control link
Enables you to set dependencies between services in a workflow that do not directly share data (i.e. that are not otherwise linked by passing data from one to the other directly or indirectly). A control link allows you to delay the invocation of a service until another has finished.
Configuration (of services)
All services in Taverna allow for some kind of configuration. Configuring String Constants is very simple and requires only setting the constant value. WSDL services only require configuring if they are secure, e.g. to specify authentication type they require. Other services, such as BioMart and Beanshells, require their input and output ports to be configured by the workflow designer after they are imported into a workflow. In the case of BioMart, inputs and outputs are determined by selecting database a query and filtering options from a configuration UI. For Beanshells, the script itself and the names of the input and output ports must be set in the configuration UI.
There is another level of service configuration that is the same for all services that deals with how the control layer around the service will execute in Taverna. These configurations can be used to specify whether users wants a service to be invoked several times in a loop, how they want the service to handle incoming lists of data, etc.
Cross product
Cross product is the term we use to describe a case in list handling where elements of 2 lists (of arbitrary depth) are being passed to two input ports of a service where at least one expects a list of lower depth than it receives. Say, we have an input ports port1 and port2 that expect single values but you pass them lists [a1, a2, a3] and [b1, b2, b3] respectively. If you specify the cross product as list handling type, the service will be invoked nine times where each element of the first list will be combined with each element of the second. In other words, inputs per iteration will look as follows:
| Port\Iteration |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
| port1 |
a1 |
a1 |
a1 |
a2 |
a2 |
a2 |
a3 |
a3 |
a3 |
| port2 |
b1 |
b2 |
b3 |
b1 |
b2 |
b3 |
b1 |
b2 |
b3 |
Basically, in cross product each element from the first list is combined with each element in the second list. See also dot product. Note that if you have 3 or more inputs as described above – you can use any combination of cross and dot products but you need to be careful of the order in which you apply them.
If Taverna needs to apply implicit iteration and you have not specified how you want input lists to be handled, then the configuration defaults to cross product.
Data Link
Enables the results (an output) from one service to be sent as the input of another.
Depth
Input and output ports of services may consume or produce single string values, lists, lists of lists, and so on. Therefore, as well as understanding the type of data that you are handling, you need to consider where this will appear in an output (for consumption by the next service in a workflow). A single value is considered to be of depth 0. A list of values is depth 1. A list of lists is depth 2, and so on.
Dot product
Dot product is the term we use to describe a case in list handling where elements of 2 lists (of arbitrary depth) are being passed to two input ports of a service where at least one expects a list of lower depth than it receives. Say, we have an input ports port1 and port2 that expect single values but you pass them lists [a1, a2, a3] and [b1, b2, b3] respectively. If you specify the dot product as list handling type, the service will be invoked three times:
- in the first one input port1 will get value a1 and input port2 will get value b1.
- in the second one input port1 will get value a2 and input port2 will get value b2.
- in the fist one input port1 will get value a3 and input port2 will get value b3.
Basically, in dot product elements at the same position in the list are combined – nth element of the first list will be send as an input together with the nth element of the second list. See also cross product. Note that if you have 3 or more inputs as described above – you can use any combination of dot and cross products but you need to be careful of the order in which you apply them.
List handling
List handling is a special control feature of Taverna that enables services that take, say, a single input value on a certain port to receive a list of that port without user having to worry about this “incompatibility”. Taverna will implicitly extract the single values and iterate over the list. More generally, if a service takes a list of depth n as an input and you pass it a list of depth n + m, Taverna’s list handling control will extract the innermost depth n lists and pass them to the service iterating over the n + m dimensional structure.
List handling control works the other way around, too. If your service expects an input of depth n, and you pass it an input of lower depth – Taverna will wrap the input into a list of correct depth. For example, a service expects a list and you pass if a single value called val, Taverna will wrap the single value and pass it as a list [val]. If a service expects a list of lists (i.e. a list of depth 2), Taverna will wrap the input value as [[val]].
This feature is also known as implicit iteration. It is more general than just control settings on a service – it applies to the whole workflow. If you supply a workflow with multiple items of data, Taverna will automatically take each piece of data in succession and feed it through the workflow. As results are produced, Taverna will also pass those results through the workflow if the next service also accepts individual values. This enables data streaming. If two or more streams of data are to be combined on two ports of a service (e.g. a service port expects a list rather than individual value), the default behaviour of Taverna is to combine them in an all against all fashion (see cross product). If you want to change this, you must change the list handling settings.
Taverna’s list handling feature enables you to define how inputs will be handled (combined) in cases where you do not pass the input of an expected depth to an input port. In such cases, users have an option to combine the input lists using the dot product or the cross product option. You can see a visual representation of what happens here.
Local Services
A Beanshell that is part of the Taverna distribution and helps with gluing services together. Local services (previously known as local workers) are a collection of data manipulation and formatting services (also known as Shims).
Merge
If the input for a particular service is to be combined from more than one upstream service, these inputs can be combined in a special merge operation. This allows you to feed the merged data in to the next service. Merges appear in the Workflow Diagram as circles, whereas services appear as rectangles. Taverna creates merges automatically if you create more than one data link to the same service input port or workflow output port.
Nested Workflow
A workflow within a workflow. In an abstract sense, a nested workflow is just another kind of service that can be added into a workflow, except that instead of it being a black box, it is a white box so you can see what is happening inside. It is often the case that a workflow designed for one purpose can be used again for other experiments and can be imported and added to another workflow. Nested workflows can be added to a workflow by dragging the nested workflow service description into the Workflow Diagram.
Port
In Taverna, a port is a connector, from an input or output of a service. Typically, an input port is either a data input or an input parameter setting. In a Web form, this would be equivalent to text boxes and configuration settings, and on a command line, this would be equivalent to parameter settings (flags). Output ports are the same. They allow you to pass the results of one service to others.
Provenance
Provenance is a history or a trace of (in this case) a workflow run. Workflow provenance data allows you to find out which workflows have been executed, with what data, and what the intermediate and final results were. It allows you to compare results between workflow runs and to confirm that all services have completed successfully during a run. It is also useful for debugging the design and development of your workflow.
Renderer
Taverna can display the results of a workflow in many different formats. As well as the standard formats (e.g. HTML, Text, XML etc), Taverna can display data using specialist formats. A renderer is a plugin that controls how to display data in these specialist formats. For example, Taverna can display 3D Jmol images of protein structures, images and XML trees.
RShell
A service that enables analyses using the R statistical package to be incorporated into the workflow.
Service
An instance of a service description within a workflow. The service instance may need to be configured before it can correctly call the corresponding service. A configured service does what it is configured to do for that particular run of the workflow.
Service in a workflow can also define the control layer around it, e.g. how the service handles lists and service looping.
Service description
A reusable way of defining a particular service. A service description allows a particular service that it describes to be added and consumed in workflows. Currently, there are service descriptions for Web services (WSDL), BioMart, BioMoby, Soaplab, R scripts, Beanshell scripts, API Consumer, Nested Workflow, Spreadsheet Import and String Constant services.
Service descriptions are added to Taverna by using various service providers, by clicking Import new services in Service Panel. Service providers return an individual service description or a set of service descriptions that match a particular search query. The returned service descriptions will appear in the Service Panel. Top-level folders in the Service Panel tree represent service providers that were used to add a particular service or set of services. Nodes in the Service Panel tree represent the actual service descriptions that can be dragged into the workflow diagram to create service instances and include them in a workflow. When a service instance is added to a workflow, it is simply called a service.
It is common for services to do more than one thing, so, in their unconfigured state, a service may have multiple potential uses. Configuration of a service in a workflow is done by clicking Configure in the service’s Details View or right-clicking the service in a diagram and selecting the Configure option from the pop-up menu. Configuring a service is optional – they would still run unconfigured using the default settings that come with the service description.
There are 2 special service description types: Service Templates and Local Services. They can be found at the top of the Service Panel tree. Service Templates include service descriptions for services that always must be configured prior to running. These are Beanshell, RShell, String Constant, Spreadsheet Import and Nested Workflow services. Local Services include preconfigured Beanshell descriptions that provide various useful and commonly used services, such as data, text and file manipulation. Once dragged into a diagram, local services can be further configured by the user to modify their original functionality.
Service provider
A service provider in Taverna is used to search for and/or add service descriptions of a particular type. For example, a BioMoby service provider will bring up all available BioMoby service descriptions into Taverna’s Service Panel from a BioMoby registry that you specify in the BioMoby service provider UI. WSDL service provider will add all methods (functions) that are available from a Web service which WSDL URL you specify in the WSDL service provider UI.
Service looping
In Taverna, service can be configured to be invoked repeatedly for a certain number of times or until some logical condition is met.
Scientific (domain) service
A service that performs analysis on data or sets of data.
Shim service
A service that does not perform a scientific function, but acts to ‘glue’ services together that otherwise have incompatible outputs/inputs. Shim services typically perform data manipulation, formatting, parsing or database mapping functions.
Soaplab
A tool for wrapping command-line and legacy programs automatically as Web services. Soaplab is particularly designed for people who prefer to program in perl or python. The services that soaplab produces are a kind of Web services, but they are slightly different in that: 1) the service provider can add more descriptions of how the service works 2) the service can be statefull (i.e. an analysis is submitted to a Soaplab service and it produces an identifier. Taverna can then keep checking this identifier for the status and for completion of the job). Soaplab services can be included in Taverna workflows.
String Constant
A String Constant service allows you to set a fixed-value input for a service or the whole workflow. This is useful for inputs that are fixed across multiple runs of the same workflow, and also for publishing your workflows since the string constant provides an example input for people wanting to try out the workflow. They can download it from myExperiment (http://www.myexperiment.org) and just run it with the string constant data instead of trying to find suitable input data.
Web services
A standardised way of programmatically integrating Web-based applications for machine to machine interaction over the network. Web services primarily use XML, SOAP and WSDL specifications and enable distributed data stores and analysis tools to be accessed and used from the scientists’ own desktop computers. Many types of Web service can be included in Taverna as services in workflow.
Workflow run
An execution of a single workflow instance. This information includes what input data was provided.
WSDL
Stands for Web Service Description Language. It is an XML format that is the interface to a Web service. It is the machine-readable description of the operations (or functions) offered by the service. Taverna can handle any Web service with a WSDL interface if you provide the URL to the WSDL file.
Workflow
A workflow enables the automation of in silico experiments (from small to very large-scale) and the formalisaton of experimental protocols. Taverna is a workflow management system and allows researchers to combine and co-ordinate distributed analysis tools and data resources into workflows. Taverna has access to over 3500 resources for use within workflows.
