Skip to end of metadata
Go to start of metadata

Current architecture

Circles in pink are parts of the larger modules that we think should be separated out. For instance the Service registry should move out from the Workbench so that a future TNG-workbench could make use of the existing service registry.

Note that I have tried to use the term workflow for an overall enactable workflow and keep Dataflow for the Taverna 2 class.


  1. The Service Registry uses some information from the Activities User Interface such as how to load service descriptions from a source and how to turn a service description into an activity that can be included in a workflow
  2. The Activities User Interface is used within the workbench to get actions for configuring the activity, information on how to display the activity and show its contextual information.
  3. An Activity User Interface uses the corresponding Activity both as a source of information to display and also to pass configurations to.
  4. The Service Registry uses the Activity since Activities are created when a service description is added to a workflow.
  5. The workbench uses the user interface portions of security so that users can access their credential manager and specify security information for particular activities.
  6. Some activities use Security to enable access to their underlying realizations.  For example, a WSDL activity may use it to call a secured WSDL service/operation.
  7. The FileManager uses serialization to load and save workflows.
  8. If a Taverna 1 (scufl) workflow is loaded, then the serializer uses the Taverna 1 libraries to load it into a ScuflModel that is then translated into a workflow.  Note that the translators are not shown on the diagram.
  9. The Taverna 1 libraries use Raven and an SPI registry mechanism.
  10. The serialization uses the infrastructure to find possible sources for workflows and ways of opening/saving them.
  11. Deserialization creates Activities.
  12. The Workbench uses the Edits within the Engine to edit workflow models.  The EditsManager though is within the Workbench.
  13. The Workbench accesses workflow models directly, normally to read fields of objects within the workflow.
  14. When running of workflows, the Workbench uses the workflow engine to create facades for workflows, to push data into the facade, to specify provenance collection and to register monitors on the workflow run.
  15. The running of workflows uses the data manager to specify where data is stored for a run, to register the data that is pushed into the workflow run and to dereference results.
  16. The Workbench uses Activities within the definition of a Dataflow.  When the workflow is enacted, tokens are pushed into the invocation of activities and results received from the Activity invocations.
  17. The Activities use the Data Manager to dereference data that is sent to their underlying realizations (e.g. as WSDL operations) and also to store data that is received from the realizations.
  18. The Workbench uses the Data Manager during the enactment of a workflow.  In particular it can expand lists for iterating over activity invocations, or create lists to enable activity invocation.
  19. Running Workflows within the Workbench uses Provenance to recover information about runs previous to the current Taverna and to specify which collector (if any) is to be used for a workflow run.  It also enables the display of intermediate values for a run.
  20. The Engine uses Provenance to receive provenance events during a workflow run.
  21. The Workbench uses Provenance to access the intermediate values during a workflow run.
  22. Provenance uses the Data Manager to understand the context of single workflow tokens that it receives.  This should not be needed.
  23. The Workbench uses the infrastructure extensively, for example to determine the content of menus.


The infrastructure that underpins Taverna 2.1 has several parts:

  • Raven that handles the dynamic downloading of "artifacts" and the creation of classloaders
  • SPI registry support to identify the classes that implement interfaces (used to do plugins)
  • The plugin manager
  • The PreLauncher that sets things up for
  • The Launcher that starts Taverna
  • The Application Configuration that handles information such as the name of the running application and the home directory

In the code base it is within net.sf.taverna.t2.infrastructure and its sub-modules

Most/all of the infrastructure will be removed and replaced with OSGi (Equinox?) alternatives.


The Taverna Engine can be considered to be in the workflow model.  Note that in Taverna 2., the code to enact an object is within the object itself.*  The workflow model (and its associated implementation modules) has several parts:

  • The workflow model itself with interfaces describing concepts such as a Dataflow and single implementations for those interfaces e.g. DataflowImpl
  • Description of how to annotate the workflow model
  • An Edits interface and associated implementations that expose undo/redoable edits that can be made on the workflow model
  • Serialization (and associated implementations) for serializing and deserializing the workflow model as t2flows
  • The facade module that creates WorkflowInstanceFacades (roughly corresponding to a runnable instance of a given workflow)
  • The invocation context module that contains information about how a workflow is to be/was run.  For example, how data and provenance is stored, the workflow run
  • Hooks to support the monitoring of a workflow enactment
  • Description of the provenance data that can be collected about a workflow run
  • HealthCheckers that are no longer used

In the code base, the Engine is in the workflowmodel-api and workflowmodel-impl modules.

The HealthCheckers should be removed.  The Edits should be moved into their own identifiable component.  The serialization should be moved into its own identifiable component.

Data Manager

The term Data Manager encompasses

  • the descriptions of the type of data that Taverna handles - ErrorDocuments, Lists and references to (sets of versions of an) a piece of data)
  • the ReferenceServices that are used to store and access the data
  • the converters used to transform data
  • the ReferenceContext that gives information about the context which owns the data - for example an InvocationContext for the running of a workflow

Note that there may be several ReferenceServices (e.g. in memory, Derby or mySQL) and they could be used within the same set-up.

Within the Taverna code base, the Data Manager is within the reference-api, reference-impl and reference-core-extensions modules.  The term Data Manager has been used here as it is thought to be more descriptive and to avoid confusion with any other types of references


The Provenance describes the ProvenanceConnector that receives provenance related events from the enactment of a workflow.  Implementations/extensions pf the ProvenanceConnector store the provenance related events in a database from which it can be accessed by the Workbench using the lineageservice classes.

The code for Provenance is within the net.sf.taverna.t2.provenance module.  The code for the specific implementations of the ProvenanceConnector is in the net.sf.taverna.t2.core.provenance-derby and net.sf.taverna.t2.core.provenance-mysql modules.


The Activities are a set of modules, one for each service type known to Taverna.  In general, each service type has an associated Activity class that specifies how to run the service and an ActivityConfigurationBean that specifies how the configuration information necessary to run the service.

The Activity module also contains a HealthChecker specific to that activity type.

At leat one type of activity (WSDL) contain activity-type specific edits.

At least one type of activity (WSDL) contains activity-type specific security, including UI dialogs.

The HealthCheckers should be removed.  The activity-specific edits should probably be moved into a separate module. The security should probably be moved elsewhere.

The code for each activity-type is in a sub-module of net.sf.taverna.t2.activities

Activities User Interface

 There is an Activity User Interface for each activity type.  The Activity User Interface encompasses:

  •  actions related to the activity-type
  • contextal and configuration panels
  • menu items for the activity-type
  • activity-type specific graphical information e.g. the Icon
  • how the set of service descriptions is determined i.e. what causes service descriptions of this type to appear in the service registry
  • in some cases, activity-type specific edits

The code for the activity user interface is in a specific sub-module under net.sf.taverna.t2.ui-activities

The Service Registry related information should probably be pulled out.  The activity-type specific edits should be moved elsewhere.


Security contains the CredentalManager that activities can use to access their underlying realizations e.g. to call a secure WSDL operation.

The security module currently contains user-interface dialogs.

The code for Security is within the module and its sole credential-manager sub-module.

The Security support needs to be generalized e.g. its capability to handle head-less running is not clear.  The UI-related dialogs need to be moved.


The Workbench encompasses the UI classes that are used for interaction with the user.  There are a large number of classes in various packages and modules, only some of which are described here:

  • The ServiceRegistry within the net.sf.taverna.t2.servicedescriptions package that keeps track of the services known to Taverna
  • Preferences support via the net.sf.taverna.t2.workbench.configuration package
  • The EditsManager within the net.sf.taverna.t2.workbench.edits package that allows edits to be undone/redone
  • The FileManager within the net.sf.taverna.t2.workbench.file package that handles the creation, opening and closing of workflows
  • The net.sf.taverna.t2.workbench.file.translator package that handles the calling of the Taverna 1 SCUFL translator
  • Startup and Shutdown SPI to allow the plugging in of code to be called when Taverna is started/shut down.
  • The WorkflowLaunchPanel within the net.sf.taverna.t2.reference.ui package that gathers the input values for a workflow run
  • DataflowRunsComponent within the package that runs a workflow and DataflowRun within the same package that represents a run of a workflow
  • The net.sf.taverna.t2.workbench.views.monitor package that contains classes for monitoring a workflow run and for retrieving and displaying intermediate values
  • The ResultsViewComponent within the net.sf.taverna.t2.workbench.views.results package where (references to) results are kept as they are generated by a workflow run
  • The RendererRegistry within the net.sf.taverna.t2.renderers package that keeps track of how types of data can be displayed
  • A large number of CompoundEdits (groups of standard Edits).  Some of these are UI interaction-specific but many represent generally useful funcationality.

It is planned to make the ServiceRegistry independent (so it can be replaced/augmented later).  The launching of workflow runs, the keeping of the list of workflow runs, the handling of workflow runs should be separated out.  Much of the FileManager capability should be pulled out.  The non-UI CompoundEdits should be put alongside the other Edits.

Proposed new architecture

Although more boxes - this would allow the workbench to be replaced, and provide capabilities to it such as how to execute workflows and keep track of runs, editing of a workbench, etc.  It is also intended that a subset of the boxes can be used to support a command line enactor, Taverna server etc.

While the current architecture forces the workbench to modify and work with the full workflow model (inside the engine), the new architecture has a mapping between a more light-weight scufl2 model (or even an UI-centric workbench model) and the internal, executable t2core model.


  1. Should the Engine still contain the workflow model and the facades and invocation contexts?  Alan would like to split it into a true enactment engine and a model server (for want of a better word).  Perhaps the facades and invocation contexts can be moved into the workflow execution.
  2.  It is not clear if there should be one DataManager per ReferenceService or if you can have one DataManager for the various ReferenceServices in the set-up.  Alan thinks it should be the latter.
  3. How should the Preferences be handled? 
  4. It is assumed that the mapping is from the workbench model to a scufl2 model and that the workflow engine has a scufl2 to workflow model mapping.  Should this be shown?


  • None
  1. 2010-07-22

    Was a decision made on whether to use Eclipse Extensions and/or OSGi Declarative Services and/or Spring Dynamic Modules, for the Taverna "backend"?

    This affects (or at least has an impact on) Taverna TNG work.

    This article - A Comparison of Eclipse Extensions and OSGi Services (from 2007 I think) provides a good overview and comparison. It is possible to combine approaches.

    I am compiling a list of useful articles/docs whilst doing the mockup 3 work for Taverna TNG (link TBD).

    "How should the Preferences be handled?"

    Maybe consider using the Eclipse Preferences framework (a tutorial) if it is possible to use it apart from the full blown Eclipse RCP framework. Again, this has an impact on TNG work.