Moving the plugin to Taverna 3

Introduction

This tutorial is about moving Taverna Plugin from Taverna version 2 to Taverna version 3. In this tutorial, steps towards moving Common Workflow Language (CWL) UI plugin to Taverna 3 is explained. This case has  two main modules:

• Taverna-cwl-activity
• Taverna-cwl-activity-ui

Example service invocation tutorial can be found here which explains how the Taverna 2 activity is implemented.   

Taverna-cwl-activity Module

Activity

Taverna-cwl-activity contains CWLDummyAcivity  class, in Taverna 2 which is responsible for specifying the input and the output ports and doing the actual service that is required. Configuring the Activity is done using CwlActivityConfigurationBean, which holds the required configuration information of the activity.

But in Taverna 3  a JSON NODE object is used instead of CwlActivityConfigurationBean.

Activity class is released from  specifying the input and output ports duty and move that to new class called ActivityFactory, in this case CwlActivityFactory class. When the AcivityFactory class is extended, the following methods should be overridden in such a way that it will return Set containing all the details of inputs or outputs.  

All the details required for configuring the inputs and output are in the configuration JsonNode, Which can be browsed using built in methods such as configuration.get(KEY). Each detail of a parameter(input/output) returned as an  ActivityInputPort or ActivityOutputPort object which can be created like the following:

The edits is an object of org.apache.taverna.workflowmodel.Edits class which is configured in the cwl-activity-context-osgi.xml and cwl-activity-context.xml. //should explained more

cwl-activity-context.xml:

cwl-activity-context-osgi.xml:

The link between  CWLDummyAcivity and CwlActivityFactory is achieved through a URI (Activity Type) which is unique for both classes.

As for dependencies, you can see follow, how the pom.xml is different for two versions

Taverna 2: pom.xml

Taverna 3: pom.xml

As you can see now the packages are named org.apache.taverna.* and previously it was net.sf.taverna.t2.*

Taverna 2:

Taverna 3:

The location and the properties of the repositories are also changed,

Taverna-cwl-activity-UI Module

Example service discovery plugin tutorial can be found here which explains how Taverna 2  discovery plugin is implemented.    

ServiceDescription

In Taverna version 3, it is not needed to provide generics, the type of the Configuration bean for ServiceDescriptions since configuration is a org.apache.taverna.scufl2.api.configurations.Configuration object.

Taverna 2:

Taverna 3:

In Taverna version 3, getActivityClass() method is replaced with the getActivityType()  which returns an URI of the corresponding Activity type.

In this case org.apache.taverna.scufl2.api.configurations.Configuration  object contains JSON NODE, which is the configuration of the CwlDummyActivity and the activity type. Thus in Taverna 3 getActivityConfiguration() method is returning a Configuration object instead of CwlActivityConfiurationBean.

In the ActivityFactory, when the getInputPorts(JsonNode configuration) and the  getOutputPorts(JsonNode configuration) methods are called, the argument  JsonNode configuration is the object, which was  initiated in Configuration object(“c.setJson(cwlConfiguration)”).  

Service Provider

As discussed in the above topics, In service provider also configured using org.apache.taverna.scufl2.api.configurations.Configuration object. In Taverna 2 this is done using Configurable bean which contains necessary details to build a service provider.

Taverna 2:

Taverna 3:

As you can see In Taverna 3 generics are removed since all service provider type are configured using org.apache.taverna.scufl2.api.configurations.Configuration object. In this case service provider is a configurable one. That means user can configure the Service provider inside the workbench.

When the constructor of the service provider is called, Configuration should be passed. In this case this is done by the following method,

In this configuration, user will be asked for a PATH to configure  the service provider.

ServiceIcon

In terms of implementation nothing has changed except In taverna 3 packages are moved to org.apache.taverna.*  from net.sf.taverna.t2.*.

ContextualView

In this plugin HTMLBasedActivityContextualView is used as the extended class for ContextualView class. In that case, details can be represented using HTML tags inside the Service Detail panel. Here you can have a peek what it looks like. In Taverna 3, like previous classes, generics have been removed. Because although  there are different types of Activities, they all have common Configuration type org.apache.taverna.scufl2.api.configurations.Configuration. This object contains JsonNode, which holds required information to build an activity.

Taverna 3:

   Constructor:

      

Taverna 2:        

   Constructor:

As for constructors, in Taverna 3 Activity type object is passed instead of CwlDumyActivity type object. This is because  the type of the activity doesn’t matter as long as the Configuration it holds is valid. Another change is now ColourManager object is passed along with the Activity. This ColourManager object is configured  in “context-osgi.xml” and “context.xml” through the ViewFactory.

Contextual VIew Factory

Taverna 3:

Taverna 2:

As shown above In Taverna 3 generics has been changed. Now it’s org.apache.taverna.scufl2.api.activity.Activity  instead of CwlDumyActivity. This is because now the Contextual View is expecting a Activity type object instead of the Specific Activity type object.

Taverna 3 POM: pom.xml