© 2010-2012 The University of Manchester, UK
This is a Ruby library to interface with the Taverna 2 Server REST API.
Ensure that gem itself is up to date:
[sudo] gem update --system
Then simply install as you would any other gem:
[sudo] gem install t2-server
In case of problems with the above the gem is available for download here: rubygems.org/gems/t2-server
You can also download the source code from here: github.com/myGrid/t2-server-gem
From version 0.9.0 this library is compatible with Taverna Server 2.3 onwards. It is not compatible with any earlier version of Taverna Server due to breaking changes in its REST interface. We strongly encourage all users to upgrade to the current version of Taverna Server, but if that is not possible right now then please continue to use version 0.6.1 of this library for the time being.
This version of the library should be compatible with any Ruby code that you may have already written against earlier versions but you may see some warnings about API deprecations. These are clearly marked [DEPRECATION] and will appear on your console output. Anything marked as deprecated will be removed in version 1.0.0 (and are not guaranteed to continue working even until then) so you are advised to update your code at your earliest convenience.
This library is known to work with the following versions of Ruby:
jruby 1.6.4 (in Ruby 1.8 mode)
Those marked with an asterisk (*) are supported and bugs found against them will be fixed. Other versions may work but are not tested or supported.
There are two entry points for the T2Server API:
T2Server::Run - Use this for running single jobs on a server.
T2Server::Server - Use this if you are providing a web
interface to one or more Taverna 2 Server instances.
In both cases the gem should be initialized by requiring the top level ruby file:
Setting up a connection to a secure server can be quite tricky and a secure Taverna Server is no different. To make things slightly easier this library provides some short cuts to providing various parameters for different types of connection.
Connection configuration settings are passed in to various methods using
ConnectionParameters class. Parameters that can be set
:ca_file - A file to use as a Certificate Authority (CA) for
self-signed server certificates.
:ca_path - Path or list of paths to directories of CA
:verify_peer - Use a CA to verify that the Taverna Server you
are connecting to has a valid server certificate and that it is the correct
:client_certificate - A certificate to use for client
:client_password - The password to unlock the private key of
the client certificate.
And can be set like this for a standard https connection:
conn_params = ConnectionParameters.new conn_params[:verify_peer] = true
This will ensure that the identity of the Taverna Server you are connecting
to will be verified using the default set of certificates for your
:ca_path can also be set to a list of paths if
required. You do not need to include your platform’s default certificate
paths as these are included automatically.
For convenience a number of standard sets of parameters have been defined.
The above example is available as
Others available are:
InsecureSSLConnectionParameters - to ignore SSL checks.
CustomCASSLConnectionParameters - for custom (self-signed)
ClientAuthSSLConnectionParameters - for client certificate
See the rdoc for more details on these classes.
Some calls to a server require that a set of user credentials are provided. These are simple to set up:
credentials = T2Server::HttpBasic.new("username", "password")
The Server constructor can yield the newly created object. Simple supply a URI and a set of connection parameters to connect to a server:
T2Server::Server.new(uri, conn_params) do |server| ... end
Note that credentials are not required by default to simply connect to a Taverna Server. Further operations (such as creating and starting runs) may require authorization depending on how your server has been set up.
To create a Run on a Server simply pass the workflow you wish to run and your credentials:
server.create_run(workflow, credentials) do |run| ... end
An individual run can be deleted with its own
(see below) but all runs on a server can be deleted in one go:
Note that you can only delete runs for which your credentials have delete authorization. See later for details.
You can bypass the Server API if you know you are only going to be dealing with a couple of runs directly:
T2Server::Run.create(uri, workflow, credentials, conn_params) do |run| ... end
Setting an input port to a run is very easy:
run.input_port("port_name").value = 1 run.input_port("port_name").value = "Hello!" run.input_port("port_name").value = ["list", "of", "values"]
Or you can use a local file as input:
run.input_port("port_name").file = filename
Once all the inputs have been set the run can be started:
And monitored to see if it has finished:
Or just wait until the run has finished:
Then the outputs can be collected:
result = run.output_port("port_name").value
If you have a lot of output you can grab the whole lot as a zip file:
zip_data = run.zip_output
Using baclava documents for setting inputs and collecting outputs is also supported:
run.baclava_input = filename
But make sure you request baclava output before starting the run:
run.request_baclava_output run.start run.wait output = run.baclava_output
A run can be deleted when no longer needed, like so:
See the rdoc for more information. Many methods and classes have much more functionality than the defaults described above. Please note that anything which does not appear in the documentation is not intended to be part of the public API. Use of undocumented classes and methods is entirely at your own risk! Such things might not have consistent behaviour and might be removed at any time.
As well as rdoc there are also a couple of example scripts which
demonstrate good use of the T2Server API. These
are available in the
bin directory but are also installed with
the library code when the gem is installed:
Running any of these scripts with a
switch will show how to use them, e.g.:
This library can be used to run workflows that contain secure services. Such services may be secured in a number of ways depending on how the credentials are passed and whether they are REST, SOAP or Rshell services.
Running workflows that contain secure services requires that you pass your credentials to Taverna Server so that it can authenticate itself as you on your behalf.
It is essential that you trust the Taverna Server that you are using!
Ideally, you should only pass sensitive information, such as passwords, via https so that you can be sure that it is not being read in transit.
REST services are commonly secured via HTTP Basic or HTTP Digest authentication and Taverna treats these two schemes in the same way. Simply pass in your username and password with the host name of the server on which the service is running:
run.add_password_credential("https://example.com:8443/", "username", "password")
The above example shows a https server running on port 8443. If the service is on port 80 for http or port 443 for https then you don’t need to specify the port.
If there are services on the same host that require different credentials then you will need to specify the realm for which each set of credentials applies. This is done by adding the name of the realm to the end of the host name with a # separating them:
run.add_password_credential("https://example.com:8443/#realm", "username", "password")
SOAP services are commonly secured via WS-Security. Simply pass in the WSDL address of the service with your username and password:
run.add_password_credential("https://example.com:8443/services/MyService?wsdl", "username", "password")
You can authenticate to R Servers in almost exactly the same way as for
REST services - only the protocol scheme is different. So instead of
https it is
run.add_password_credential("rserve://example.com:6311", "username", "password")
Some https servers authenticate clients using certificates. If you have services that require this type of authentication you can upload a keypair:
run.add_keypair_credential("https://example.com:8443/", "certificate.p12", "password")
If the services in your workflows are on a https server then Taverna requires that it can verify that the server is the one you expect it to be. This is done by peer verification. In most cases this happens automatically and transparently but if the remote server has a non-standard or “self-signed” certificate then you will need to provide Taverna with the corresponding public key for verification to take place:
Taverna Server is a multi-user system and as such insulates users from one another as much as possible. Each run that a user creates can only be accessed by that user by default. If you want to give another user permission to perform certain actions on a run then you can do so:
Available permissions are:
:none - No permissions.
:read - Read the state of the run and get its outputs.
:update - Set the state of the run (e.g. start it).
:destroy - Delete the run.
Permissions are accumulative so giving a user the
permission also allows that user to read and set the run’s state. Note that
there is no way for any user other than the owner of a run to perform any
security related actions on it. This means that only the owner may grant,
query and revoke permissions and only the owner may add, query and delete
trusts and credentials.
You can revoke a user’s permission:
You can get a list of the permissions you have granted for a run:
And also see what permission you have granted a particular user:
Please email firstname.lastname@example.org for any questions relating to this Ruby gem.