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:

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:

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

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:

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:

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?