How can I create my own processor to add to a workflow?

There are several ways to achieve this. The main questions are what you have already 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 processor. See the manual about how to use the Beanshell. 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 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 processor, "Coordinate from" makes it run after the other 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 widget

A Java widget is implemented by subclassing a simple interface. This is useful for not-so-complex processors, such as the default shims provided with Taverna, "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 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, but need more features such as dynamic ports or having your own scavenger tree, you can instead subclass org.embl.ebi.escience.scufl.Processor and get more control over how to serialize the processor as XML in XSCUFL, how to configure it and how it is run.

This is also covered in the developer guide.

Write your own web service

You might want to consider developing your own web service. If properly deployed and maintained, interesting 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.

Ultimately you can even make your own plugin 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 the Soaplab and BioMOBY^? processors.