FAQ

However, very often services provided by different third party providers are not compatible with each other. Taverna provides certain local “shimming” services to help incompatible services inter-operate inside a workflow.

Hide

Taverna supports different types of Web services, including WSDL-based, SoapLab, BioMoby and BioMart services.

For a list of known biological Web services that typical Taverna users are encountering, see the BioCatalogue.

Hide

myExperiment is a repository for workflows. There are also various groups on the site devoted to particular subjects. Many of the workflows are available for download and reuse.

myExperiment can be searched via the Web site or through the Taverna Workbench. The Taverna 2.1 Workbench has a built-in myExperiment perspective where many of the myExperiment features are available. In the Taverna 1.7.x Workbench, the myExperiment perspective is available through a separate plugin that can be installed from the Workbench.

If you cannot find anything suitable on myExperiment, you could also try e-mailing the support@mygrid.org.uk or the taverna-users mailing list and ask if anyone knows how to solve your problem.

You can find many different workflows on the myExperiment Web site. There are also groups on the site devoted to particular subjects.

If you cannot find a suitable workflow on myExperiment, then you can ask on the taverna-users mailing list.

Hide

myGrid is the name of the project. Taverna is among the most popular pieces of software that have been produced as part of the project. Development of Taverna is currently the main focus point of the myGrid project.

Hide

Taverna is used by a large number (more than 350 at the last count) of academic and commercial organizations throughout the world.

Some examples of the Taverna use can be found here, both for particular subjects and also for how it is being used.

There are also a large number of groups devoted to particular subjects on the workflow-sharing myExperiment Web site. If you cannot find an appropriate group on myExperiment, then you can start your own there.

You can also ask on the taverna-users mailing list to see if anyone else is working in a similar area.

Hide

There are two main differences between Kepler and Taverna: (1) the models of computation they use and (2) the user communities being served.

1. Kepler works based on the concept of “directors”, which dictate the models of execution used within a workflow. Taverna uses one particular model of computation, based on the lambda calculus, whereas in Kepler users have a range of models of computation available.
2. The Taverna team has primarily focused on supporting the Life Sciences community (biology, chemistry and medical imaging), whereas in Kepler the emphasis so far has been on ecology and geology.

Hide

myGrid has ontologies for semantic service discovery (the myGrid ontology) and for managing process provenance (the workflow run ontology). They have in general been authored in OWL using Protégé 4.

The latest version of the myGrid ontology is available here. The myGrid domain ontology for bioinformatics services is also available separately here.

The myGrid ontology is used within Feta (our service discovery tool) and by the BioCatalogue (a curated catalogue of Life Science Web services).

Feta allows services to be identified by their functions or properties, for example, inputs/outputs, underlying data resources, methods or tasks. Feta can potentially be used to describe services in any domain, but initially, we have concentrated on the bioinformatics domain. Therefore, the myGrid ontology can be considered to be logically separated into an ontology of service properties and an ontology of bioinformatics tasks, functions and resources. We see other “domain” ontologies being added as and when they are developed, for example for chemoinformatics or medical imaging.

We have aligned our service description model with that of the Biomoby service description model so that Feta can search over both service registries. Please see the BioMoby Web site.

Feta can be downloaded as a plugin to the Taverna 1.7.x Workbench and used to search over services that have been annotated with the myGrid ontology. There is no Feta plugin for Taverna 2.1 Workbench, where the similar functionality will be provided by the BioCatalogue plugin.

BioCatalogue uses terms from the myGrid ontology to tag the catalogued services. In the future, BioCatalogue will support other ontologies as well, such as EDAM.

BioCatalogue plugin for Taverna 2.1 Workbench is planned for the second half of 2010. It will enable you to perform a full BioCatalogue search and pull all the service annotations. It will also enable you to add new annotations to services in BioCatalogue.

Hide

BPEL lacks many of Taverna’s features but presents the possibility of providing a standard runtime platform for a server side workflow engine. Taverna is designed to present a workflow model where entities within the workflow map as far as is possible onto entities within a scientist’s description of the eScience process the workflow defines. This leads to a dataflow view of the world – the workflow is constructed from data processing and data transport (processors and data links).

In contrast, BPEL is a process-centric model where the nodes in the workflows are activities and the “data” passed between them form a control system rather than being a genuine flow of messages. Alongside other facilities, such as Taverna’s implicit iteration mechanism (single node implicit parallelism, in BPEL this is a complete workflow in itself), the workflow models in Taverna can be extremely small for achieving very high grade of functionality. A workflow that looks simple in Taverna (a two stage pipeline, for example) can be orders of magnitude more complex in BPEL as the latter forces an explicit representation of the parallelism and data staging implicit to Taverna’s world view.

In addition to this Taverna is service agnostic – while some tools are available as SOAP services, many are not (and should not be – a data warehouse streaming gigabytes of data makes a poor Web service!). BPEL has a very fixed Web service world view, and whilst in a particular case that could be changed through vendor specific extensions you would then lose the multi-platform advantage. Taverna, in contrast, was designed to be entirely extensible in this area. If SOAP services were all replaced tomorrow with something completely different (say REST), Taverna would carry on working and we would adapt to the new “standard” within days.

However, if your application is such that you think you do require a BPEL Workflow Engine, then you should investigate the OMII-UK BPEL Designer.

Hide

There are alternative ways of creating workflows that can be run by Taverna 1.x. One of these is Seahawk from BioMoby.

Using the Seahawk applet, users can progress data between Moby services. The flow of the data between the services can be saved as a Taverna 1.x workflow. Such a workflow can then be run with Taverna 1.x. Saving and re-running the workflows allows the user’s work to be documented and repeated.

Taverna 2.1 workflow format differs from that of Taverna 1.x. We are currently working on defining a workflow language specification (called scufl2) and the API and a set of tools to manipulate it. It is currently scheduled for release in April 2010 (please see our Roadmap for details). The tools will then enable you generate workflows independently from the Workbench.

Hide

Post information on your bug to the appropriate (taverna-users or taverna-hackers) mailing list or send an e-mail to support@mygrid.org.uk.

Hide

When you start the Taverna Workbench, it automatically finds and loads the URLs of a default set of services that are commonly used (currently these services are mainly from the Life Sciences domain). You can search this default list by typing keywords into the Filter box at the top of the Service Panel in the Taverna 2.1 Workbench. In Taverna 1.7.x, you have a similar Search box above the Available Processors in the top left panel of the Workbench.

If you do not find anything suitable or if you need to know more about a service and how it works, you can search the BioCatalogue.

The BioCatalogue is a curated catalogue of Life Science services. It contains descriptions of services and their inputs and outputs along with examples of input and output data. It also monitors services and provides information on their availability.

In Taverna 1.7.x, you can also find services by exploiting their semantic annotations using Feta. Feta can retrieve services by name, type, task, inputs and outputs descriptions, etc. For more information on how to install and use the Feta plugin, consult the Taverna 1.7.2 User Manual. There is no Feta plugin for Taverna 2.1 Workbench, where the similar functionality will be provided by the BioCatalogue plugin. The plugin will be available in the second half of 2010.

Hide

In Taverna 2.1 Workbench, if you click on the Import new services button in the Service Panel, a drop-down for different types of services will appear. Select the one that corresponds to the new service and paste the Web address (URL) of the new service in the pop-up window. For example, to add the DDBJ Blast service, you would type the WSDL address (http://xml.nig.ac.jp/wsdl/Blast.wsdl) into the Import new services -> WSDL service box.

In Taverna 1.7.x Workbench, if you right-click on the Available Processors node in the processors tree, a drop-down for different types of processors will appear. Select the one that corresponds to the new processor and paste the Web address (URL) of the new service in the pop-up window. For example, to add the DDBJ Blast service, you would type the WSDL address (http://xml.nig.ac.jp/wsdl/Blast.wsdl) into the Available processors -> Add new WSDL scavanger box.

Hide

Taverna 2.1 Workbench has a simple drag-and-drop interface for connecting services together. Drag the services you require into the Workflow Diagram from the Service Panel and connect them up by selecting ports and drawing arrows between them. For a detailed description of how to build workflows and tips for good design, please see our tutorials.

In Taverna 1.7.2 Workbench, you can add a processor (i.e. service) to a workflow by dragging from the Available Processors list to the workflow tree in the Advanced Model Explorer, or by right-clicking it and selecting Add to model. For a detailed description of how to build workflows and tips for good design, please see our tutorials.

Hide

In Taverna 2.1, you can add a new input by right-clicking on the white space in the Workflow Diagram and selecting Insert -> Workflow input port, or by selecting the red triangle icon from the toolbar at the top of the Workbench.

In Taverna 1.7.2, you can add a new input by right-clicking on the Workflow inputs node in the Advanced Model Explorer tree, and select Create new input… option.

Hide

In Taverna 2.1, you can add a new output by right-clicking on the Workflow Diagram and selecting Insert -> Workflow output port, or by selecting the green triangle icon from the toolbar at the top of the Workbench.

In Taverna 1.7.2, you can add a new output by right-clicking on the Workflow outputs node in the Advanced Model Explorer tree, and select Create new output… option.

Hide

In Taverna 2.1, when you drag a BioMart service into the Workflow Diagram, a configuration window will appear. You can create inputs by defining Filters and outputs by defining Attributes. If you want to change these settings later, you can right-click on the service and select Configure BioMart query…

In Taverna 1.7.2, if you right-click a BioMart processor in the Advanced Model Explorer tree and select Configure BioMart query…, a configuration window will appear. You can create inputs by defining Filters and outputs by defining Attributes.

Hide

In Taverna 2.1, when you drag a Beanshell service into the Workflow Diagram, a configuration window will appear. Input and output ports can be created by selecting the input and output port tabs and adding them by name. The other tabs allow you to write a Beanshell script and set any dependencies you require. When you are writing your script, it is vital that the names of the ports match the input and output variables in your script. If you would like to change any of these settings later, right-click on the service and select Edit Beanshell script.

In Taverna 1.7.2, if you right-click a Beanshell processor in the Advanced Model Explorer tree and select Configure beanshell…, a configuration window will appear. Input and output ports can be created by selecting the input and output port tabs and adding them by name. The other tabs allow you to write a Beanshell script and set any dependencies you require. When you are writing your script, it is vital that the names of the ports match the input and output variables in your script.

If you would like to see some examples of Beanshells, you can find many workflows on myExperiment containing them. The Local Services/Local Widgets in Taverna are also Beanshells.

Hide

The RShell services work in the same way as the Beanshells, where you create your input and output ports and use the same names for variables in your scripts. In addition, you will have to add information about the connection settings for the RServe.

Hide

Some ports have default settings and some are optional, so you will not always have to set them all. It is sometimes difficult to determine which ports are required because service documentation varies a great deal. Look at the available descriptions in the BioCatalogue for more information.

Hide

In Taverna 2.1, you can set a constant value by right-clicking on the appropriate input port and selecting Constant value. Alternatively, you can drag in a String Constant from the Service Templates section of the Service Panel and connect it to the appropriate input port of your service.

In Taverna 1.7.2, you can set a default value for an input port of a processor by right-clicking the port node in the Advanced Model Explorer tree and selecting Set default value.

Hide

Taverna does not support looping in the sense that there are no cycles within a workflow graph.

Taverna 2.1 Workbench supports looping in the sense that it allows you to invoke a service until a particular condition is satisfied. For example, it allows you to poll an asynchronous service until the result is available. To create a loop on a service in Taverna 2.1, select the service in the Workflow Diagram and then click on the Details in the Workflow Explorer. Select Advanced and click Add looping. A pop-up window will then allow you to select an output port and the conditions of your loop.

Taverna 1.7.2 Workbench supports iteration over a set of independent jobs (and combinatios over this iteration so allowing “all against all” and similar strategies). Taverna’s capabilities correspond to a “for” loop with no side effects in an imperative language such as Java. It is possible to implement side effecting loops through external stores and nested workflows but this is not recommended – if you really need this then it is possible. Recursive invocation similarly can be hacked together but it is not “clean”.

Hide

In Taverna 2.1, you can add a workflow as a nested workflow by selecting Insert -> Nested Workflow from the top menu or right-clicking on the white space in the Workflow Diagram. Alternatively, you can merge a workflow with the current one by selecting Merge workflow from the Insert menu.

We recommend that you add a workflow as a nested workflow. This preserves the modularity and makes reuse and repurposing much easier. Credit and attribution of the original author are also clearer when you add another workflow this way.

In Taverna 1.7.2, you can import a workflow from File -> Import workflow into an existing workflow to effectively merge the two. To add nested workflow to your workflow click the Add nested workflow button in the Advanced Model Explorer.

Hide

Services that accept XML documents as inputs can be difficult to invoke without help constructing the XML. Taverna has splitter services that separate elements out in the XML so that users only have to add strings as inputs, and Taverna populates the schema behind the scenes.

To use the splitter services in Taverna 2.1 Workbench, click on the service and then select the Details tab in the Workflow Explorer. At the bottom of the details table, you can Add input XML splitter or Add output XML splitter. Sometimes, you will need to chain several splitters together to reach the necessary elements in the XML.

In Taverna 1.7.2 Workbench, right-click the input or an output port of a WSDL processor you want to add a splitter to and select Add XML splitter… from the pop-up menu.

Hide

Taverna has an implicit iteration system, which means that you do not normally need to worry about handling iterations. If you provide Taverna with a collection of data, the workflow will iterate over each item automatically. If, however, one of your services combines two or more inputs, you need to specify how Taverna should combine these inputs in the event of iterating over multiple values.

You can specify a cross product iteration, which combines everything in one list with everything in the other (all against all), or you can specify a dot product iteration, which combines item 1 of list 1 with item 1 of list 2, and so on (row against row). The default behaviour is to combine lists using a cross product.

Hide

Cross and dot product (in Taverna speek) denote different techniques used to feed services in workflows with input data when the depth of provided input data does not correspond to the depth expected by the service. See the question on iteration and list handling for more details.

Hide

We would generally recommend against using a local tool as this can break the portability of your workflow and prevent you from sharing it. You should instead consider wrapping your tool as a Web service, or using Taverna’s Beanshell service.

If you need to use a local tool, then you can consider using either:

• the Execute Command Line App local Java service/widget (see the FAQ on using the Execute Command Line Application tool), or
• the API Consumer tool – a Java-based tool that allows the selection of subsets of Java APIs that may then be imported into Taverna Workbench and used as services within workflows.

Hide

A library can be added to the classpath of the Beanshell or API Consumer services/processors by putting the JAR files in the folder lib within your Taverna home directory, usually C:\Documents and settings\MyUsername\Application data\Taverna-x.y.z on Windows, ~/.taverna-x.y.z on Linux, and ~/Library/Application Support/Taverna-x.y.z on Mac OS X, where “x.y.z” is replaced by the appropriate Taverna version.

From the Taverna 2.1 Workbench, right click on, for example, a Beanshell service in the workflow, select Edit beanshell script…, go to Dependencies tab, and tick off which libraries to include in the classpath.

From the Taverna 1.7.x Workbench, right click on, for example, a Beanshell processor in the workflow tree in the Advanced Model Explorer, select Configure beanshell…, go to Dependencies tab, and tick off which libraries to include in the classpath.

Hide

Services within a Taverna workflow can be viewed as functions – that is to say you feed them a set of inputs, press “go” and get a set of results. A database in contrast just sits there until you query it so some kind of intermediate layer is required. There are a few different options:

• The most sophisticated is to use Taverna’s extension points to implement a full query interface including a server side query service and GUI plugins to build the query and present the user with database metadata to assist that. This is a lot of work; we maintain an example of this in the BioMart service.
• The second option is to create a standard SOAP (or other protocol) service that exposes a ‘canned query’ interface allowing a restricted subset of all possible queries at which point it just looks like another service and Taverna can invoke it as per usual.
• If your data is amenable to it, the third way is to make use of the existing BioMart service and expose your own data set as a BioMart (see http://www.biomart.org for more details).
• Fourthly, if there is a JDBC interface to the database then you can use the JDBC Local Java services/widgets.

Hide

Generally, we discourage the use of local tools in this way as your workflow will be highly specialised for your machine and setup. The Execute Command Line App, found under Available Services > Local Services > io in Taverna 2.1 and Available Processors > Local Services > Local Java Widgets > io in Taverna 1.7.2, will let you execute any command on the local system.

You will notice it has two inputs: command and args. This is the command to execute and its arguments, as a list. Let us assume you want to run a Perl script that you have already written. Say your Perl script is in /home/stain/src/blah.pl and it requires an argument gene, and it outputs useful stuff on standard out (i.e. you do not have to read any files produced). Then you do the following.

Add Execute Command Line App service/processor to your workflow. Set the constant (default) value of the input port command to /usr/bin/perl (replace with the location of Perl on your system).

If you need only one argument, you can right click on the input port args and set it as the constant (default) value for this port. Note that this argument will be passed in as if it was quoted on the command line. If you try for instance cp as command and file1 file2 as args, it would mean to copy the file named "file1 file2", including the space.

Since we need two arguments, we have to construct a list of arguments. We can use a String List Union local service/widget for this since we only need two arguments, found under Available Services > Local Services > text in Taverna 2.1 and Available Processors > Local Services > Local Java Widgets > text in Taverna 1.7.2. Add this service/processor to the workflow. Connect the union output of the list union to the args input of the script. Rename the services to, for example, Blah and Blah_args. Set the constant (default) value for list1 input port on Blah_args to “/home/stain/src/blah.pl”. Set the constant (default) value of list2 input port of Blah_args to “gene”. Note that this will work because Taverna will wrap the list1 and list2 arguments as two lists with one value each, output the union of the two lists, i.e. a list of two strings. (There are other ways to construct lists. One way would be to get it as a workflow input, but we assume here you do not want to have to specify the Perl script path every time you run the workflow.)

If you need an empty list (no arguments), or more than two arguments, unfortunately you would need to do this using a Beanshell script. For instance:

Say /home/stain/src/blah.pl contains:

Then running the workflow should yield a single output from service Blah as:

This would be the same as on the command line:

You might want to split the output by line so that you can get a list of lines, depending on what you want to do with the output.

Now, as you will probably find out, your script will not be in /home/stain/src/blah.pl, and if you are on Windows or some versions of Unix, your Perl will not be in /usr/bin/perl. In addition, if your script uses libraries from CPAN then those libraries might not have been installed. This is the main reason why we do not recommend this solution. Your workflow will not be portable and sharable. It will not be easy to run this workflow in a Remote Workflow Execution Service, and it will be difficult for your colleagues to use it. As for a scientific description of your workflow, it does not include what happens inside blah.pl script.

If you are just doing regular expressions, we recommend exploring the available Local “shim” services/widgets. Or writing a little Beanshell service if nothing suitable exists.

We would recommend you to expose your Perl script as a service so others can benefit as well.

Hide

In Taverna 2.1, you can use the Execute Command Line App local service (Available Services  > Local Services > io > Execute Command Line App).

In Taverna 1.7.x, the equivalent is to use the Execute cmd-line app processor (Available Processors > Local Services > Local Java Widgets > io > Execute cmd-line app).

However, this is not recommended as it makes your workflow less portable. That is, to run your workflow you have to have Perl (and any libraries that your script requires) installed on the machine you are using, as well as the Perl script that the workflow references.

If your Perl script is fairly simple you may find a Local Java Service/Widget to do the same thing. If your Perl script is large/complex you may want to convert it into a web service.

Hide

If you want to examine SOAP messages sent from and received by Taverna, they are logged to taverna.log file in logs directory of your Taverna home directory.

You can see SOAP request and response messages in more detail by turning on DEBUG logging for the HTTPSender used by Axis. This is achieved by modifying the conf/log4j.properties in your Taverna installation directory (where runme.bat executable is, or on OS X in /Applications/Taverna.app/Contents/Resources/Java/) and adding the following 3 lines:

Bear in mind this will generate a lot of logging.

If you are a service developer using Axis and want to inspect the SOAP messages your service is sending and receiving, you might also want to check the SOAPMonitor utility provided by Axis.

Hide

You can use the Select and Ask local services/processors (Available Services  > Local Services > ui in Taverna 2.1, or Available Processors > Local Services > Local Java Widgets > ui in Taverna 1.7.2).

Select lets the user select from a list of options. Ask lets the user type in a value.

In Taverna 1.7.2, you can also use the Interaction Service.

Hide

Bundled with Taverna you will find a RShell service/processor under Local Services/Widgets. The processor works in a similar way to the Beanshell service: you specify input ports and output ports, which are available as variables inside the script. The script can either be edited directly in the service’s configuration or opened from a file.

However, the actual execution is done by sending the script to an R execution server. To use RShell you need to install (preferably locally) R, the R execution server called RServe, and the R-libraries needed, such as BioConductor. We recommend that you configure your RServe to run on localhost only, preferably as a separate user, and with access allowed using some non-important username/password.

There’s a short introduction available from University of Twente, although it is slightly outdated.

Hide

XSLT is a powerful tool for transforming one XML document into another. A typical example is to rewrite an XML returned from a database to a human-browsable (X)HTML representation.

Taverna comes with an XSLT processor, located under (Available Services  > Local Services > xml > Transform XML in Taverna 2.1, or Available Processors > Local Services > Local Java Widgets > xml > Transform XML in Taverna 1.7.2) .

The output can be retrieved both as a real value for your workflow and/or stored in a file.

You should try manually with a command line XSLT tool (like xsltproc) or similar before using it from Taverna, as XSLT might be a difficult language. One recommendation is to try to find an XSLT stylesheet that does almost what you want already, and then modify it to your needs.

Hide

XPath is a way to express a path to elements and parts of an XML document. Taverna provides a processor for this purpose, located under Local Services -> Local Java widgets -> xml > XPath From Text.

There is an XPath tutorial available online that might be helpful. Here we will just mention a simple example. Consider a service returns this XML:

<result>
    <users>
       <user>Katy</user>
       <user>Stian</user>
    </users>
    <groups>
      <group id="mygrid">
        <user>Katy</user>
        <user>Carole</user>
      </group>
    </groups>
</result>

Say we are only interested in getting the list {Katy, Stian} out of this document, i.e. the content of the user elements below users, but not the ones below group.

XPath allows you to express this in a path, similar to a path on a filesystem. The xpath:

would select those two user elements. In this case we specified the full path, which is normally the most precise, and avoids potential unrelated results such as the two other user tags belows. The xpath:

would select all user elements, and thus result in the list {Katy, Stian, Katy, Carole}. In many cases this short-form (the blank node between // means “below anything”) can be good enough, but as shown in this example, can be quite volatile if additional information is added to the XML at a later time.

Note that currently the processor in Taverna has an issue with XML documents with namespaces. A workaround is suggested, see TAV-492.

Hide

As a workflow runs, you can watch its progress in the Results Perspective. If your workflow is iterating over multiple data sets, you will see a count of the iterations as they are processed, and you will see when services have finished executing.

When the workflow is finished, results for each output port are visible from the tabs along the Results Perspective.

Hide

In Taverna 2.1, you can save all the results from a workflow run, all the results plus the input values, or a selection of results. If you click on the Save values button in the Results Perspective, a dialogue will open that will allow you to make a selection. Individual values can also be saved. Results can be saved in XML or Excel format.

In Taverna 1.7.2, you can either save an individual result or all of them in XML or Excel format. You can do this from the Results Perspective, by selecting the appropriate button at the top of the results tab for the workflow.

Hide

Taverna 2.1 Workbench has an integrated provenance collection facility. As a workflow runs, events are recorded from each service invocation. You can explore intermediate inputs and outputs by clicking on a service in the Results window. If there is iteration over the service, you can see individual invocations.

The provenance (intermediate values) viewer in Taverna 2.1 is useful for evaluating previous workflow runs and also for debugging workflows at the time of design.

In Taverna 1.7.2, there are Intermediate Inputs and Intermediate Outputs tabs in the Results Perspective that allow you to track intermediate values of processors in a workflow. You can also see the status of each processor (e.g. completed or failed). However, these values are lost after you close the Workbench as there is no provenance collection facility as in Taverna 2.1.

Hide

Error messages can be seen in the Results viewer of the Results Perspective. If there is a problem with an upstream service, the error is propagated through the workflow to the final output. If you need help with errors you receive, please e-mail the taverna-users list.

Hide

Taverna 2.1 uses MIME magic to “guess” the MIME type of the output, and based on that renders the result. This means that you do not have to specify the MIME type of the output port, as was the case in Taverna 1.x.

Taverna will always make available all possible renderers for a particular output result. For example, if your output is an XML text – you would be able to see the plain XML text as well as the XML tree.

In Taverna 1.7.2, you can manually add multiple MIME types to a workflow output port (to be used by the output renderers) by selecting the output and going to “Metadata for ‘myoutputport’” – under “MIME types”. For example, for SVG add

image/svg+xml

This should enable the SVG renderer for the output port. You might need to right click on the value in the left hand column and select “SVG” instead of “Text”.

Hide

Taverna 2.1 uses streams, which means that services which just “pipe through” items of a list can start processing (in parallel) when the first item has been outputted upstream. This can be compared to iterators in Java.

Taverna 1.7.2 does not use streaming nor pipeling, but will run tasks in parallel whenever it is possible. In fact you have to put effort into serialising execution if it is needed, by using Coordinate from option to run one processor only after another has finished.

As a dataflow oriented workflow language, SCUFL used by Taverna 1.x will run a processor at the point when all of its needed data is available. So if you as the workflow designer just worry about the dataflow, Taverna will usually handle the parallel calls.

What can cause problem is that not all data is available at the same time. For instance, a processor that takes three parameters as inputs, fed from three different processors upstream, will not execute until all of the three parameters are present.

Another issue has to do with lists. Although Taverna’s implicit iteration means that you can provide a list to a processor that only cares about single inputs (such as “Concatenate two strings”), the way the iteration is done in Taverna 1.x is such that the processor is temporarily transcribed into taking a list as input and producing a list as output.

As with any processor taking a list as an input, it cannot start until the full list has arrived from upstream. And the same applies to the output, the next processors downstream cannot start until the full result list has been returned. This makes sense for a processor that for instance is to find an average of the inputs, but is not really necessary for implicit iterations.

Hide

This depends. Why do you want to run it 100 times? If it is just a matter of looping you can implement this by putting your workflow as a nested workflow, and input to the workflow a list of 100 elements. (It does not matter what the elements are unless you are varying some parameter for each run.)

For instance this Beanshell (with output port called "n") creates a list of the numbers from 0 to 99:

ArrayList n = new ArrayList();
for (int i=0; i<100; i++) {
    n.add(i);
}

If the workflow in question takes quite a long time to complete, you might not want to use this approach as it would mean the workflow would take 100 times longer to complete.

Instead you might want to execute the workflow outside Taverna, and use shell scripting to control the output and the number of times to run the workflow.

Hide

Yes. You can run Taverna 1.7.x from the command line using the execution script.

You can also run your Taverna 1.7.x workflows on a Taverna Server hosted on another machine. The execution of the workflow can be initiated from within the Workbench using the remote execution plugin.

You can also run workflows on grids or include jobs on grids as services within a workflow.

For  Taverna 2.1, command line execution and remote execution facilities will be available in the first half of 2010.

Hide

When you read in a file by clicking Add file location(s) (in Taverna 2.1) or Load inputs (in Taverna 1.7.x) button from the Run workflow dialogue it will be loaded as one single input, even if it contains multiple lines, i.e. the workflow input will be a single string with many lines. You can actually select several files to add several inputs, each containing one or more lines.

Most services expects one input at a time, but your file contains several input values, one for each line. One way to get a list of inputs instead of a string with multiple lines is to add as a “shim” between the input to the workflow and where ever the input is destined, a little service/processor called Split string into string list by regular expression, found under Available Services > Local Services > text (in Taverna 2.1) or Available Processors > Local Services > Local Java Widgets > text (in Taverna 1.7.x).

Connect the workflow input in question to the service’s string input, and for the regex input, right click and set default value to \n (that is backslash n) – which means “new line”. You could try \r\n instead if your files are Windows-based and \n is causing you problems. If your file consists of lines of columns you can try to add a second splitter and split by space, \t tabulator or similar.

Connect the split output to the rest of the workflow instead of the original workflow input and remove the old connection.

Hide

The Fail_if_true and Fail_if_false processors, available under Available processors > Local services -> Local Java widgets -> conditional, have the functionality that they fail if the input is “true” or “false”, respectively. This can be combined with a “Coordinate from” on another processor that would then only run if the Fail_if… processor succeeds, i.e. does not fail (effectively branching the workflow).

In addition, a nested workflow can use the Fail_if… processors set as Critical and thereby conditionally fail the whole nested workflow. This combined with a retry policy for the nested workflow in the wrapping workflow can be used for typical ‘Wait until service says X’ loops, such as job submission systems.

The way these processors are implemented is simply to fail on purpose if the input condition matches. However, this means that a stack trace will be printed from the enactment engine every time a processor like this fails. Note that this does not neccessarily mean that the workflow failed. In fact, that part of the workflow is probably designed to fail.

We have still marked this as a bug, TAV-479, since we should not be outputting stack traces unless there is an actual error.

In Taverna 2.1, there are no service equivalents to Fail_if… processors from Taverna 1.x. Taverna 2.1 has a looping functionality that can help with job submission type services, where the workflow execution waits until a submitted  job has finished so there is no need to resort to failing processors. Branching as a kind of control logic may be implemented post 2.1, but at the moment there are no fixed plans as to when this will happen.

Hide

It is normally a good sign! By default, when using executeworkflow script,  the output of the workflow will be written to a directory named after the workflow file. So if you executed:

executeworkflow.sh my_workflow.xml

you should find a directory my_workflow.xml_output, containing at least progressReport.xml, and a directory structure for the workflow output.

Note that you can modify the output options, run with option -help for more information.

Hide

Taverna 1.x is unfortunately not very good at dealing with large data. You have two options – first is to redesign your services such that you pass references to data held elsewhere. This will generally benefit all your users as the efficiency hit you take when running large (>1MB) files through a SOAP service is pretty severe compared to the hundred or so bytes used by a reference to a data file (i.e. a HTTP URL).

Alternatively, you can use the Web service Data Proxy to dynamically rewrite the SOAP messages. It overcomes the problem of Web services that return large items of data causing Taverna 1.7.x to struggle or fail due to memory constraints. It solves this problem by allowing the user to select specific data elements for referencing, leading to the data to be stored on the proxy and the Web service SOAP response is rewritten to replace the data itself with a URL to the actual data. The Web service Data Proxy is available for download.

Many of the issues that make the Web service Data Proxy necessary for Taverna 1.7.x are overcome in Taverna 2.x. Taverna 2.x uses a more efficient mechanism for storing data and so can handle larger data sets.

Hide

There is no standard mechanism for creating a Web service from a workflow. However, there are ways to run a workflow on a Web service.

Several solutions for this have been made, one of them is the remote execution with the Taverna Server. This solution currently works only for Taverna 1.7.x workflows. The 2.x version of the Taverna Server is planned for the second half of 2010.

However – the remote executor service is designed for long-running workflow, so there is not a single “post and wait” method – you have to first upload your workflow, then your data (as a baclava document), then a job combining these two and putting it on the execution queue, then check the status of that job, check it again, check it again, ok, finished, then fetch the results (as a Baclava document).

The service uses Taverna 1.x under the hood, and the interface is a RESTful one. There is client libraries for Java, Python and Ruby. If you have a service, you can register it with myExperiment to execute workflows on your behalf.

As workflows are allowed to do all sorts of things, you should not have a general Web service open to the world to execute any random workflow. For instance, you could upload a workflow that contained a beanshell script that deleted all the files on the server. Or, a more likely way of abuse: start sending thousands of spam emails. There are two ways out of this:

• Limit which workflows to run – someone will pre-approve a workflow, or
• Limit which users are allowed to run workflows – someone will have to pre-approve the user

The execution service uses the second approach.

The Taverna team is investigating a service that takes an uploaded workflow, “approves” it, and then generates a WSDL interface for that particular workflow. The WSDL operation would then have input and output parameters matching the workflow input and output ports, so the caller would not need to know Baclava, what are the required ports, etc. – even that it is a Taverna workflow at all.

The caGrid team did a prototype that can do this “workflow as a service”. More details are available here.

Hide

An empty list usually means that for a given input, no results were found. For instance, if you have a service that looks up genes producing a certain protein, and you feed it with a list of 8 different protein identifiers, you might get back a list of lists of proteins. There would then normally be one list corresponding to each of the inputs, in order. If any of the inputs did not match in the database, the inner list will be empty.

In a complex workflow, these empty lists will not disappear by themselves, because they represent “no results”. So if you pass the result of the previously mentioned service into another service again, if Taverna iterates over the inputs, the service will not actually be called when it encounters the empty list, but a corresponding empty list will be added to the output.

This picture is of course complicated by that some services actually read whole lists of inputs (for instance for sorting them or similar).

To get rid of the empty lists, you can apply a Beanshell like this:

removeEmpty(Collection collection) {
 ArrayList filteredList = new ArrayList();
 for (Object elem : collection) {
  if (elem instanceof Collection) {
    Collection elemCollection = elem;
    if (! elemCollection.isEmpty()) {
      filteredList.add(removeEmpty(elemCollection));
    }
  } else {
    filteredList.add(elem);
  }
 }
 return filteredList;
}

ArrayList output = removeEmpty(list);

Remember to specify the correct depth of the input list to the Beanshell service/processor for this to work, in this case the input “list” can be changed from “a Plain Text” to “2-deep list of Plain Text” (matching the depth of the input) and should be able to transform:

{
   {
      {}
      {
        Hello
      }
   }
   {}
}

into

{
   {
      {
        Hello
      }
   }
}

Note that this Beanshell probably will not be able to handle removal of lists that become empty because they only contained empty lists.

We have noted this as a bug, TAV-119, and will hopefully include this as a local Java service/widget in a later Taverna release.

Hide

This is related to the previous empty lists question. Service that take a single value in and return a list of values will normally produce deeply nested lists when combined. Again, this is because in many cases each list in the output corresponds to each value of the input list. This is further complicated by services that takes many inputs.

If a service takes inputs a, b, c, all of them single values (not lists), then if you call this service with three lists A=[1,2,3], B=[4,5], C=[6,7], Taverna’s implicit iteration will call the service equivalent to:

results = []
for a in A:
   aResults = []
   results.add(aResults)
   for b in B:
      bResults = []
      aResults.add(bResults)
      for c in C:
         cResults = []
         bResults.add(cResults)
         cResults.add(service(a,b,c))

(The actual ordering of a,b,c is not guaranteed without an iteration strategy defined, so it might just as well be c iterated first.)

Now, the result list will be mirroring this structure, so there will be a list for all the A results, which will be lists of all the B results, which will again contain one result for each different C. Now, the service might return a list as well, so in this case you would get a 4-level deep list as a result.

If you are not really interested in keeping this structure, you can flatten the list by using local Java service/widget  Local Services > list -> Flatten list (in Taverna 2.1) or Local Services > Local Java Widgets > list -> Flatten list (in Taverna 1.7.x).

Hide

Security means different things to different people – service providers tend to employ different security protections for their services and there are many security models around. Java also has its ways for dealing with security and how that affects Taverna will be explained in questions this section.

Taverna 2.1 currently supports access to secure Web services that use HTTPS and/or WS-Security with username and password authentication. Taverna currently does not support HTTP Basic authentication with username and passwords – this is one of the planned improvements post 2.1.

In addition, several Taverna plugins have been developed that enable Taverna to invoke secure services on grids (see also the FAQ section on Taverna and grids):

• caGrid
• European Model for Bioinformatics Research And Community Education (EMBRACE)
• Know-how Sharing Technology Based on ARC Services and Open Standards (KnowARC)
• MOTEUR
• Netherlands Bioinformatics Centre
• Grids for Industrial Product Development SIMDAT
• JSDL plugin for Taverna 1.7.x that allows you to submit services within a workflow to a grid using GridSAM

Taverna 2.1 Workbench also has the Credential Manager built in, a utility for safelykeeping your credentials (passwords and certificates) and certificates of trusted services you use in your workflows.

We are aware that there are many other models for securing services, which we will support if our user community needs it. If you are a Taverna user trying to use a secure Web service implemented using a security model other than those described here please contact us via the taverna-users mailing list.

Hide

HTTPS is the most commonly used security protection among services. The use of HTTPS would be indicated by a service’s URL starting with https:// instead of http://. HTTPS is a secured version of the HTTP communication protocol and provides a connection between a client and a server that is confidential (i.e. private, no one can eavesdrop it). It also verifies the identity of the server by means of a digital certificate – the server must possess a valid certificate issued by a trusted Certificate Authority (CA), such as the Verisign, for the HTTPS connection to be opened successfully.

All modern Web browsers include a pre-defined list of trusted CAs (e.g. for Mozilla Firefox, see http://www.mozilla.org/projects/security/certs/included/). That means that if you were browsing a Web site which URL started with https://, your browser would first verify if the site’s certificate was among trusted certificates or if it was signed by one of the built-in CAs. If yes – it would proceed to that site. If not, it would ask you if you wanted to trust it. By answering yes, the browser would remember this site’s certificate as trusted and would not ask you next time.

Similarly, Java has its own list of trusted certificates (that belong to trusted CAs) saved in a special truststore file somewhere on your hard drive. This enables you to open an HTTPS connection from Java to a service whose certificate is signed (i.e. vouched for) by one of the built-in trusted CAs. Taverna’s Credential Manager is also making use if this truststore – see the question about Credential Manager for details.

There is one other important aspect of Java security. By default, Java comes with a security policy that lets you use only limited-strength cryptography. This means that, for example, you can only use short (an therefore not-so-secure) keys for encryption. The reason why Java by default only comes with limited-strength cryptography support is due to import control restrictions in some countries, where unlimited-strength cryptography is classified as a “weapon technology”.

Obviously, we want Taverna to use the strongest possible security protections available. This is possible by downloading and installing the ‘Unlimited Strength Java Cryptography Extension’ policy from Sun (see below for links) in place of the default restrictive policy shipped with Java. Replacing the policy effectively switches on the “strong” cryptography in Java.

Java’s security policy consists of two files located in:

<java-home>/lib/security/local_policy.jar

<java-home>/lib/security/US_export_policy.jar

where <java-home> is the jre directory of the Java Development Kit (JDK) or the top-level directory of the JRE (Java Runtime Environment) on your system. You need to replace both of these files with their “unrestricted” versions.

For Java 6, you can download the unlimited cryptography policy from here.

For Java 5, you can download the unlimited cryptography policy from here.

If you have not heard about this before, your country most probably allows the use of unlimited-strength security and you will be OK to download and install the new policy.

Not installing these files will cause Credential Manager to fail. It will also cause invocation of secure services from Taverna to fail. Note that if you switch to another Java version you would have to install the policy files again in the appropriate directory of your new Java installation.

Hide

Web services typically operate by exchanging SOAP (Simple Object Access Protocol) messages with clients over HTTP. SOAP is an XML-based protocol/language.

WS-Security is a standard that specifies how certain security information (e.g. username and password) can be embedded inside a SOAP message and passed to a Web service over the Internet.

Taverna 2.1 Workbench supports the portion of the WS-Security standard that refers to username and password authentication. Depending on a service’s settings, Taverna will add your plaintext or digest password as part of SOAP messages sent to that service. Plaintext means that your password is simply sent “as is” – it is not “scrambled” or encrypted before sending. If someone got hold of the SOAP message containing a plaintext password they would be able to see it. Digest means that your password is scrambled in some way before placing it in a SOAP message and this would make it harder for someone to “guess” your password if they got hold of the SOAP message carrying it.

Sending passwords like this inside SOAP messages over HTTP is not very secure (even if passwords are digests and not plaintext). For this reason, services typically also use HTTPS to protect the confidentiality of SOAP messages while in transit. This makes it (almost) impossible for eavesdroppers to see what is inside the SOAP messages.

In addition, some Web services may also require a WS-Security timestamp (a date and the time) to be added to SOAP messages for security purposes. Taverna 2.1 is also capable of doing this for you. This helps services fight replay attacks, since they can ensure that messages are “fresh” and not “replayed” by checking the timestamp.

Hide

Credential Manager is a Taverna 2.1 utility that manages your credentials, i.e. stores your usernames and passwords and private key certificates securely on the hard drive. It also remembers what credentials you want to use for which services. This is convenient, as you do not have to enter your security details every time you invoke a service from a workflow that requires you to authenticate. In this respect, Credential Manager is similar to Password Manager in Firefox or Internet Explorer, or Keychain (Apple’s password management system in Mac OS).

Credential Manager also keeps certificates from trusted services and trusted CAs (that issue certificates to services). This is so that Taverna can open HTTPS connections to a desired secure service when executing a workflow, similar to browsers and Java (see also the question about HTTPS). The first time you start the Taverna 2.1 Workbench – it will attempt to copy certificates of all trusted CAs that come bundled with Java. If you have played with these settings in Java and changed the default password for Java’s truststore – Taverna will ask you to enter that password so it can perform the copying. If you have not – Taverna will not bug you and will perform the task silently.

Hide

Taverna 1.7.x error messages can sometimes be difficult to understand. Some common errors are explained here:

• Unable to open Xscufl file – occurs when Taverna is unable to parse the workflow file that you tried to open. This may be because it is not a valid workflow definition, or because Taverna is unable to access some of the services within the workflow. You should check that you are connected to the Internet.
• Could not establish connection … The server uses more recent protocol than… when using the Rshell service. You need to use the correct version of the R server.
• Unable to create scavenger! Unable to load the WSDL definition, underlying reason was … when loading a new WSDL scavenger. This can occur if the WSDL is generated by Axis2 and is a known bug in some Axis2 versions.
• Error occured during invocation Content is not allowed in prolog – indicates that you are attempting to pass non-XML input into a service (normally a WSDL service) that expects an XML file. You should add XML splitters so that the data can be wrapped appropriately.
• … SVG … font-weight:regular – some versions of GraphViz can generate invalid SVG (for the diagram). This is a known GraphViz bug. You may need to change to a different version of GraphViz.
• …java.lang.LinkageError: duplicate class definition – this is a known Taverna bug.
• java.io.FileNotFoundException for a nested workflow – this commonly occurs when you have downloaded or copied a workflow that contains a nested workflow. The path to the nested workflow has been stored in the parent workflow definition, but can no longer be reached e.g. it was on a local machine. Workarounds for this problem have been suggested.
• java.lang.UnsupportedClassVersionError: net/sf/taverna/tools/BootstrapClassLoader – this occurs if you try to run Taverna 1.7.x in a version of Java earlier than 1.5. Check that you are using a correct version of Java, e.g. with java -version.
• Unable to determine file for mygrid.properties – This suggests that the $taverna.home property is not set correctly.

Hide

Currently there are no tools available for users to annotate their own services within the Workbench, but you can annotate your services in the BioCatalogue.

Hide

You can register and annotate services in the BioCatalogue. Please contact the BioCatalogue team for more help and support.

Hide

Normally, Web services do not need to be wrapped or prepared in any way to be used by Taverna. If your Web service is exposed as SOAP and described with WSDL, all you need to do it provide the URL to the WSDL to Taverna.

For example, if your services are provided using Axis, you can find the WSDL listing under the URL to the portlet, say at /axis/services, with a typical service exposing its WSDL as /axis/services/methodName?wsdl.

Soaplab can be used to create Web services from existing code. Typically this code comes in a form of a Perl script.

Daggoo can be used to create Moby services from CGIs, or basic WSDL services, that can then be used within Taverna workflows.

Hide

Taverna can use many kinds of service, so there are many ways of producing services.

If you are a biologist/bioinformatician with many legacy command-line applications and you want to wrap them as web services, we recommend Soaplab.

Soaplab is based on Perl. If you have more experience with Java, you might want to create services using Apache Axis. Please see the Axis user guide for more details.

Hide

There are several ways to achieve this. The main questions are what you already have and what you want to do.

Beanshell

One popular solution for small shims (modify output X slightly so it is in format Y) is to use the Beanshell service. Normally it involves you specifying input and output ports, and then writing some lines of Java-ish code (no class- or method-declarations needed).

The Beanshell can also be used to access external libraries provided as .jar files. However, this means that everybody who wants to run your workflow will have to download and install those .jar files as well. Install the files into the subdirectory lib of your Taverna home directory, and tick them off as dependencies in the beanshell configuration panel. You should then be able to import and use your classes and methods.

API Consumer

If you have a large API, for example similar to BioJava, that you want many Taverna users to access, one quick solution is to use the API Consumer Tool to annotate selected classes and methods from the API, and then distribute the JAR file with an accompaning API definition file (XML).

Users are then able to right click in the Scavengers panel, select “Add new API consumer”, select your XML file, and then being able to browse your API as if it was a service provider. To compose a workflow, constructors and methods are added to the workflow. Remember that Taverna runs workflows by the data flow, and as such API calls that must happen in a certain order must either be coordinated (right click on service/processor, Run after/Coordinate from makes it run after the other service/processor is finished), or by using the output “object” from the first processor as the input “object” for the second processor, if both are concerning method calls on the same object.

Write a plugin as a local Java service/widget

A Java widget is implemented by subclassing a simple interface. This is useful for not-so-complex widgets, such as the default shims provided with Taverna, e.g. “Flatten list”, “Concatenate two strings”, etc.

Developing such a Java widget involves implementing org.embl.ebi.escience.scuflworkers.java.LocalWorker and listing it as an SPI. The interface requires you to specify the input- and output ports, in addition to a method public Map execute(Map inputMap) which is called for executing the service/processor.

In order for users to install the local Java widget it will have to be deployed as a plugin. Describing how to make a plugin is outside the scope of this FAQ, but we are making a Developer Guide that will cover this in detail.

Write a plugin as a local service

If you have decided to write your own plugin, check Developers’ documentation for Taverna 2.1 or Developers’ guide for Taverna 1.7.x.

Write your own Web service

You might want to consider developing your own Web service. If properly deployed and maintained, users worldwide can benefit from your contribution. Depending on what you already have it might be easiest to develop it as a WSDL-based service (using Axis for Java), Soaplab-based (if you have existing code in Perl or similar command line tools) or any of the other available service types.

Write a plugin for your service type

Ultimately you can even make your own plugin for Taverna and your own service, with the plugin connecting to the service. This can hide details of how the remote method calls and focus on what the workflow designer wants to do. This is what we have done with, for example, Soaplab and BioMoby.

Hide

As of Taverna 1.5.2, the Taverna home directory is primarily used for runtime information specific to that user or configuration settings specific to that user. This is useful for installations within a multi-user environment. If this is not the case then most configurations can be modified by changing the files within the conf/ directory of the downloaded Taverna directory, what is called the Taverna startup directory.

On Windows, this is a hidden directory C:\Documents and Settings\username\Application Data\Taverna-x.y.z (XP) or C:\Users\username\AppData\Roaming\Taverna-x.y.z (Vista and Windows 7).

On Mac OS X, this is a directory Library/Application Support/Taverna-x.y.z under your home directory. To find your home directory, click on your username under Places in Finder.

On Linux, this is a hidden directory in your home directory called .taverna-x.y.z.

Customisation

In Taverna 2.1, the Taverna startup directory can be overridden globally by setting

set ARGS=%ARGS% -Draven.launcher.app.home=/somewhere/else

in taverna.sh (Linux)/taverna-debug.bat (Windows) or by setting

raven.launcher.app.home=/somewhere/else

in conf/raven-launcher.properties in the Taverna startup directory.

In Taverna 1.7.x, the Taverna startup directory can be overridden globally by setting

set ARGS=%ARGS% -Dtaverna.home=/somewhere/else

in runme.sh (Linux)/runme.bat (Windows) in the Taverna startup directory. If you just want to avoid saving downloaded JAR files in the home directory of the user, you can override raven.repository property in the mygrid.properties file instead.

Hide

Taverna startup directory is the directory where you installed Taverna and from where you run it.

On Windows, if you have used the installer to install Taverna this is C:\Program Files\Taverna Workbench x.y.z or C:\Program Files(x86)\Taverna Workbench x.y.z directory. If not, then this is the directory where you unzipped Taverna.

On Mac OS X, this is /Applications/Taverna x.y.z.app directory. To find your Applications directory, click on Applications under Places in Finder. You can browse the contents if the app directory by right-clicking Taverna x.y.z.app and selecting the Show Package Contents option.

On Linux, this is a directory where you unzipped Taverna.

Hide

mygrid.properties is a configuration file for Taverna 1.x that includes the HTTP proxy configuration and a list of services that is to be populated in the Available Processors panel. It is located in the conf/ directory of the Taverna startup directory.

On Windows, the Taverna startup directory is C:\Program Files\Taverna Workbench x.y.z or C:\Program Files(x86)\Taverna Workbench x.y.z. Look for mygrid.properties inside the conf\ directory.

To locate mygrid.propertieson a Mac, right click on the Taverna application, select Show Package Contents, switch to Column view, and navigate down through Contents/Resources/Java/conf. Right click on mygrid.properties to Open with… -> Other and select your favourite text editor, say TextEdit.

On Linux, the conf folder is located under the unzipped Taverna installation folder.

Hide

Freefluo is the workflow engine used by the Taverna 1.x. It was developed as part of the original myGrid project, but is outside of the scope of the current myGrid project. It is now managed by IT Innovation at Southampton. In the current Taverna codebase, Freefluo is so heavily customized that it is no longer recognizable as the original project. Approximately 95% of the code the enactment uses is Taverna’s code rather than Freefluo, we really only maintain the name for compatibility with the old powerpoint slides.

Freefluo is not used by Taverna 2.x.

When users ask the Taverna team about Freefluo, they often want to know how to run a workflow without using the Taverna workbench GUI. See also “Can I run Taverna on another machine or from the command line?” question.

Hide

Taverna 2.1 has a GUI interface for Preferences (File > Preferences > HTTP Proxy), where various properties can be customised. HTTP proxy is one of them.

In Taverna 1.7.2, you can specify using a HTTP proxy by modifying your mygrid.properties and uncommenting and completing the lines referring to http.proxyhost and http.proxyPort. The mygrid.properties can be found in the conf/ directory of the Taverna startup directory. In an environment where Taverna is shared between users then this may be customised by an individual by copying and modifying the mygrid.properties in conf/ directory in the Taverna home directory.

If you require authentication you will also need to uncomment and modify the lines referring to http.proxyUser and http.proxyPassword.

If there are hosts that you wish to use that do not require using a proxy then you can add a similar line that declares http.nonProxyHosts.

This is documented in full in the Taverna manual – Proxy configuration.

Hide

To add services to the Service Panel:

• In Taverna 2.1, click on the Import new services button above the Available Services tree and select the appropriate service type. In Taverna 1.7.x, right click on Available Processors and add a new service by selecting the particular type and supplying the address, or you can scavenge for new services at a specified Web address.

To remove services from the Service Panel:

• Right click on the service node and select the service you want to remove from under Remove individual service provider (Taverna 2.1) or Remove from tree (Taverna 1.7.x).

In Taverna 2.1, any service you add (through a service provider) to the Service Panel will be remembered next time you start Taverna. If you want to remove such a service, simply right click on it in the Service Panel and remove the corresponding service provider. Note that removing a service provider will remove all services added though it (if there were several), and not just that one service. You can also remove all services you added at once, so only the default ones will remain.

In Taverna 2.1, you can also remove the default set of service providers and restore them later on. This is done in a similar fashion by right-clicking and selecting an appropriate option from the pop-up menu. You can further configure the behaviour of default service providers through Preferences (File > Preferences > Service Providers).

In Taverna 1.7.x, even if you remove default services, they will be reloaded next time you start Taverna. To prevent services from being loaded at startup, you can alter the configuration in the mygrid.properties file. This file is found in the conf/ directory within the Taverna startup directory or within your Taverna home directory if you wish to specify specific user settings within a multi-user environment.

Hide

In Taverna 2.1, you can configure the behaviour of default services through Preferences (File > Preferences > Service Providers). You can select if you want the default services to appear when you start Taverna up. You can also configure if you want to allow permanent removal of default services (which you can then remove form the Service Panel by right-clicking on a service and selecting Remove).

In Taverna 1.7.x, even if you remove default services, they will be reloaded next time you start Taverna. To prevent services from being loaded at startup, you can alter the configuration in the mygrid.properties file. This file is found in the conf/ directory within the Taverna startup directory or within your Taverna home directory if you wish to specify specific user settings within a multi-user environment.

The settings to change in mygrid.propertiesare:

• taverna.defaultsoaplab – for Soaplab services
• taverna.defaultwsdl – for WSDL services
• taverna.defaultbiomoby – for BioMoby services
• taverna.defaultmartregistry – for BioMart registry locations

Hide

If you use a proxy for Internet access you will need to set up the proxy for Maven.

The central Maven repository can be very slow so it is a good idea to set up a local mirror to use.

Hide

Taverna does not necessarily run “on a grid”. It is a desktop application that can be used to access resources, either on a grid, or anywhere else.

There are two aspects of the Taverna use with grids: running Taverna workflows on a grid or running workflows that access services on a grid.

Running workflows on a grid

If you do want to run Taverna itself on a grid, then it can be installed as an application on a grid node to execute workflows using the Taverna command line tool. This tool is currently only available for Taverna 1.7.x (see here). The Taverna 2.1 command line tool is scheduled for the first quarter of 2010 (see the Taverna Roadmap for details).

Alternatively, the MOTEUR enactor allows Taverna 1.x workflows to run on an EGEE or Grid 5000 grid.

Including services on a grid in workflows

In order to include a grid service within a Taverna workflow, you need to extend Taverna so that it can talk to the service correctly. Because the way such services are accessed depends upon the type of computational grid where they are run, you need to install a plugin appropriate to that grid.

For example, the ARC plugin for Taverna allows users to access KnowARC grids for remote computations and usage of grid-based storage elements. The plugin site is http://grid.inb.uni-luebeck.de.

The caGrid plugin allows users to add caGrid services to a workflow. The plugin site for Taverna 1.7.1 is http://www-unix.mcs.anl.gov/~madduri/taverna/ and for Taverna 2.1 is http://www.mygrid.org.uk/taverna/cagrid/.

There is also a JSDL plugin for Taverna 1.7.x that allows you to include jobs submitted via GridSAM as services within a workflow.

Various projects have successfully run Taverna workflows on a grid or run workflows that access services on a grid:

• caGrid
• European Model for Bioinformatics Research And Community Education (EMBRACE)
• Know-how Sharing Technology Based on ARC Services and Open Standards (KnowARC)
• MOTEUR
• Netherlands Bioinformatics Centre
• Grids for Industrial Product Development SIMDAT

Hide

No. You do not have to install any other OMII-UK software to use Taverna. It is a stand-alone piece of software.

Hide