Notes for developers extending Taverna

Quick reminder to all - please check in with UNIX line endings!

Extensibility of Taverna

Processor Types

The Scufl processor types provide extensibility by abstracting over different types of services and making the available as processors.

• WSDL - Web Services accessible through their WSDL descriptions
• Soaplab - Web Services conforming the the Soaplab interface
• Biomoby - Web Services conforming the BioMOBY interface
• SeqHound - service interface the SeqHound
• Local Services - useful utilities given a service interface
  • Java widgets
  • String constant
  • Beanshell scripting
  • Notification
• Nested Workflows - a Scufl workflow as a service
• Talisman -

Displaying results

The renderers for displaying the results in Taverna is another extension point. The potential renderers are selected based on the MIME type that has been given for the output. TavernaMimeTypes has a brief list of the basic types that have been used. In addition there are renderers that convert collection structures, especially lists, into tables.

Workflow Event Model

This is used for example in the provenance plugin

org.embl.ebi.escience.scufl.enactor.WorkflowEventListener

There aren't any examples of this in the Taverna code other than the EnactorEventMonitor in the scuflui package. [TMO taverna-hackers 27 Sep 2004]

The basic idea is that you stick the plugin classes in a jar with a manifest file. This lets taverna/freefluo know that a listener should be registered for workflow events and the name of that listener.

Service Interfaces for extensions (SPIs)

Saving results SPI

The code to save results of a workflow invocation from the GUI is now in its own SPI, specifically that defined in org.embl.ebi.escience.scuflui.results.ResultMapSaveSPI

Implement this interface, add the implementing class to the appropriate services file (i.e. path /META-INF/services/org.embl.ebi.escience.scuflui.results.ResultMapSaveSPI in your .jar file) and it should appear in the enactor invocation panel when the workflow completes. [TMO taverna-hackers 24 Sept 2004]

UI Components SPI

Contrary to my objections the other day I've implemented a SPI style interface for GUI components. This is largely to get around a potential circular dependency. Anyway, implement the ScuflUIComponent interface in your component (and extend JComponent otherwise it won't work!), and put a META-INF/services/org.embl.ebi.escience.scuflui.ScuflUIComponent file in your extension jar with the full class name of any extensions the jar contains, make the jar available to the workbench and it should pick it up. [TMO taverna-hackers 19 May 2004]

LocalWorker SPI

I've rolled LocalWorker over to use an SPI-based API for discovery. It's documented in the LocalServiceScavenger class. [Matthew P taverna-hackers 28 May 2004]

Running workflow without gui (Taverna workbench)

A description of how to run a workflow independantly of the GUI can be found here: ExecutingWorkflowOutsideOfTaverna

Procedures for bugs, enhancements, etc

We have quite a few people contributing into the CVS repository these days, so I'd like to suggest (okay, demand, but suggest sounds a lot nicer) some procedures to avoid us tripping over one another.

0) Sf.net usage

Please log in to sf.net before manipulating the trackers - you can submit as anonymous but it's harder for me to manage.

Also, I can use the tracker system to assign bugs and RFEs to people. These then show up on your sf.net homepage so please check this at least once a week to see if there's anything that we think you should be doing! Of course, you're free to say that you don't want to do it or that there's not enough time etc but we need to know either way.

http://sf.net/projects/taverna and follow tabs for Bugs, RFE, etc.

1) Bugs

All bugs should be reported in the bug tracking system. This applies even (especially so) if you've found and fixed it. The bug list contains hyperlinks to the bug report. PLEASE include this link in the cvs commit message - this means that commits should not in general be at the top level and should be done per file or subpackage - I know this is a pain and I've not been great at it myself but I think we now need to be a bit more disciplined.

2) RFE (Request for Enhancement)

Same applies, but also post to the hackers and possibly users lists before coding. It's quite plausible that someone else has been thinking along the same lines. So, in this case log a RFE in the tracker, post a note to the mailing list summarizing (and put as much detail in the tracker item as you can) and include a link to the RFE detail page.

Again, CVS commits pertaining to the RFE should include a link back to the item in the tracking system.

3) Code 'fragility'

There are three packages in particular which can have a massive knock-on effect if things are not done carefully. The packages concerned are :

org.embl.ebi.escience.scufl org.embl.ebi.escience.baclava uk.ac.soton.itinnovation.taverna.enactor.entities

If you have found a bug or want to change code within these packages please post to the list before you commit and wait for either myself or Justin to okay it, again, this is a pain and could slow us down but until we've done our major refactoring these packages contain some code 'quicksands' which can cause major problems unless handled carefully. This is, I should say, almost entirely my fault and the above request is a function of the tangled structure and lack of documentation rather than a comment on the abilities of any of the developers - you wouldn't have CVS access if I didn't believe you to be competent.

Cheers,

Tom [TMO taverna-hackers 4 Oct 2004]

Writing New Processors

If you're implementing the functionality as a set of local workers (the purple java based processors) you'll need to do the following :

1. ) Create one class per operation and make this class implement the LocalWorker^? interface from org.embl.ebi.escience.scuflworkers.java
2. ) Create a service definition file called org.embl.ebi.escience.scuflworkers.java.LocalWorker, the file should contain the following on each line, one line for each class in (1) :

    
<FULLY QUALIFIED CLASSNAME> = <CATEGORY>:<NAME>
I'd suggest using 'ncbi' as the category, so an example line :
org.foo.EntrezFetcher = ncbi:Fetch entry from Entrez

This would then appear in the local service section under a new 'ncbi' node.

Once you have the classes and this description file you need to put hem into a .jar - the classes in the normal place but the description file needs to go inside a directory 'META-INF/services/' in the jar file. If you do all this correctly you'll find that simply putting the new jar file into Taverna's workbench lib directory should make the processors appear.

Tom [TMO taverna-hackers 9 Nov 2004]

---

Related info

• TavernaTips - useful Taverna information
• WorkflowLinks - general scientific workflow resources

-- MarkGreenwood - 12 Nov 2004