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.
If your Beanshell is depending on an external .jar library – you also have to place that .jar file in a special directory so Taverna can find it. See the FAQ “Using a library with Beanshell/API Consumer services” on how to do this.
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 Service Panel, click “Import new services” and select “API consumer service…”. In the pop up dialog, select your XML description file, and then 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.
You also have to place the .jar file of your API Consumer in a special directory so Taverna can find it – see the FAQ “Using a library with Beanshell/API Consumer services” on how to do this.
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.x 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 or REST-based service (e.g. using Apache CXF 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.
