There are several ways to achieve this. The main questions are what you already have and what you want to do.
If you have an existing tool or a script that you want to call, then the easiest way is to define a tool service.
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 Beanshell on how to do this.
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 API Consumer on how to do this.
If your service can be written as a Taverna workflow, then you can create and share it as a component.
If you have decided to write your own plugin, check Developers’ documentation for Taverna 2.x.
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.
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.