This document is a checkpoint of Task 1 in PT.WP.4. It describes a set of requirements and anticipated extensions to the Taverna Workbench needed to support SCAPE preservation workflows gathered from various discussion with SCAPE users.
Support for invoking REST Web services is available in Taverna 2.2 in a form of a plugin that can be installed from the Workbench. In the current Taverna 2.3 release (released on 2011-07-14), the support for REST services has been hardened and has been built into the distribution so there is not need for users to install anything separately. For a list of issues fixed between the Taverna 2.2 and 2.3 versions see Taverna's bug tracking system.
Please refer to the Taverna User Manual for the documentation on how to use REST services from Taverna workflows.
Requirements from SCAPE users included: support for GET and POST requests, handling XML and URL encoded input data and support for HTTP Basic authentication and they have all been incorporated into the current 2.3 release of Taverna.
Some of SCAPE command line tools are described using the tool specification/invocation language (developed by British Library (BL) and available from the SCAPE's github repository). A toolspec describes a set of command line invocations of the same tool with several varying parameters, such as loss rate or image quality. It is planned to have all the SCAPE command line and Web services described using this language.
Another similar language (toolwrapper) is developed by ONB (Austrian National Library). This language takes a command line tool and the toolwrapper specification and generates a SOAP Web service from it. There have been discussion to merge the two languages.
A requirement for SCAPE is to be able to import a set of toolspecs/toolwrappers into Taverna's Service Panel and make them available for inclusion in workflows. This was and is to be discussed in more detail between BL, ONB, AIT and UNIMAN. At the moment, it seems like BL is in favour of deprecating their toolspec and using toolwrapper language.
Tools services in Taverna allow users to invoke command line tools as part of the workflow. The command line tool can be local to the machine running Taverna or it can be invoked on any machine to which Taverna can obtain an SSH connection.
Currently, the only supported SSH authentication mechanism is via username and password pairs. Some partners have expressed a request for supporting utilizing the SSH client keys/certificates already stored on the user's hark disk (typically in <HOME_DIRECTORY>/.ssh) for remote execution of commands. This request been filed in Taverna's issues tracking system as issue T2-1860.
There was a requirement to extract descriptions of Web services from their WSDL documents and include those descriptions into Taverna Service Panel to make it easier for users to find and select services they need.
This issue has been entered into Taverna's bug tracking system - http://www.mygrid.org.uk/dev/issues/browse/T2-1990.
A related requirement to the one above is to pull the annotations on Web services' ports into corresponding XML input splitters' ports.
This issue has been entered into Taverna's bug tracking system - http://www.mygrid.org.uk/dev/issues/browse/T2-2007
There was a requirement to "copy" the name of a WSDL service's input port into the workflow's input port when the two are directly connected.
This is a non-trivial requirement.
One a user is happy with the workflow results, publish these results together with provenance data of the run to a SCAPE store for further processing/sharing/viewing by other users.
For example, save all results from Taverna into WebDav (for binary data) or Ref (RDF triple store).
Service Catalogue currently supports storing descriptions of WSDL and REST services. As of Taverna 2.3, there is a built-in facility to search such a catalogue and add services to either Taverna's Service Panel or directly into workflows.
There was a requirement to store toolspecs/command line tool descriptions in the Catalogue. This may be outside the scope of the project as the project proposal only mentions a catalogue of Web services - needs to be investigated.
It has also been discussed to wrap/make all command line tools available as REST Web services; thus there may not be the need for extending the Catalogue's functionality.