Skip to end of metadata
Go to start of metadata

Pluggable invocation ability

Main problem is how to have pluggable invocation abilities, e.g. plug in the ability to enact an external tool in a cloud, with associated UI.  This can cause problems as it will be difficult for the basic external tool activity to deserialize the configuration of the activity.

Suggestion is to identify an invocation ability probably by a URI, and to give it a name e.g. http://taverna.nordugrid.org/ssh and "ssh".  The configuration of the invocation ability will be passed (via serialization) as an XML element.  Invocation abilities will state which ability they can handle.  SPI can be used to discover the correct one.

Shared configuration

The need to share invocation configuration between services in a workflow was discussed.  Idea is to identify specific invocation configurations by a URI and name e.g. http://www.somewhere.com/fred and "execute on fred".  Note that this is distinct from the invocation ability's URI and name. The invocation configurations are edited/created via preferences and stored in a weak hashmap.  When serializing the activity's configuration, the correct invocation configuration from the hashmap is inserted.

Labels
  • None