Skip to end of metadata
Go to start of metadata

Tutorial: Creating a service invocation plugin

This tutorial will walk you through how to create a Taverna service invocation plugin. Also see other documentation on creating Taverna plugins.

First we'll assume you have Eclipse 3.5.1 for Java (or later) installed, and that you have configured Maven integration plugin version 0.9.8 or later. See prerequisites for details. If you are new to Maven we also recommend you have a look at the online Maven book Maven: The Definitive Guide.

This tutorial is confirmed to work with Taverna 2.3.0, but some screenshots might be from older versions.

Terminology

  • Activity is a way for Taverna to connect to and invoke a third-party service. Different activities can use different libraries and/or protocols to connect to the code that does the "real work". While some activities invoke services over the network, like the WSDL activity which can invoke web services, others can perform local invocations, like the Beanshell activity which executes local Java-like scripts. Some services don't do any invocation at all, and simply deal with data retrieval or storage, like the String constant activity, which simply return the configured string. In the Taverna workbench, possible activities are browsed as 'Available services', configured and connected with a Processor, together forming a Service in the workflow.
  • Maven artifact is a Java library (JAR) packaged (and possibly built) using Maven, and made available in a Maven repository. Taverna plugins are described in a plugin description file, and installed from the described Maven repository. Maven artifacts are described in a POM file with identifiers and version numbers, and where they can also state dependencies on other Maven artifacts, which will be retrieved automatically. Taverna consists of several such artifacts, and a plugin would typically depend on mainly the API bits of the Taverna workbench and execution engine.
  • A Maven artifact is identified by a groupId, artifactId and version. The groupId should be based on the reverse domain name notation as used for Java package name, and also include the product name, for instance uk.co.mycompany.myproduct (or including your username edu.mit.people.johndoe.myproduct).
  • The artifactId is the identifier of this particular JAR within the given groupId - a product could consist of anything from one to hundreds of such artifacts, conventionally hierarchical artifacts have named combined using dashes, like maven-dependency-plugin. (Note that Taverna artifacts don't always follow this convention)
  • The version defines which version of this artifact we're talking about, like 1.2.0 or 2.1. While a Maven project is under development, version numbers end with -SNAPSHOT to indicate that the artifact is a moving target, for instance 1.5-SNAPSHOT - meaning "what will soon be released as 1.5 or 1.5.0, but 1.5-SNAPSHOT today is not necessarily the same as yesterday". As we're starting from scratch we'll use 0.1-SNAPSHOT as the version number. Maven can also download nightly snapshots of external dependencies in SNAPSHOT versions, but for consistency we recommend depending on stable versions where possible. In this example we'll depend on the stable versions used by Taverna 2.1.
  • A Maven module is a build tree for Maven to produce an artifact, and has a standard structure with folder such as src/main/java for Java source code. Compiled modules are installed into a local repository (typically .m2/repository in the user's home directory). To be reachable by others, an artifact needs to be deployed to a Maven repository, typically exposed on the web. Taverna's artifacts are deployed to the myGrid Maven repository. Maven will also search central repositories for common dependencies such as log4j.
Labels
  • None