Release notes

Welcome to GRIA Workflow Service, version 1.1.0. The GRIA Workflow Service enables a GRIA service provider to deploy workflows that compose GRIA jobs and data transfer operations. Such workflows are made available as aggregate applications and can be executed by clients (e.g. Taverna and other GRIA Workflow Services) in a similar manner to GRIA jobs.

The GRIA Workflow Service is made available according to the terms and conditions of the accompanying licence agreement. Please refer to the IPR Registry for licences and information relating to other libraries bundled in this distribution.

Please refer to the main documentation for installation instructions, tutorials, reference information and support details.

Change Log

Version 1.1.0

Bug fixes and upgrade to support GRIA 4.3.0.

• WKF-26 - Improved documentation. Some improvements have been made, including a tutorial on building, deploying and testing a workflow.
• WKF-30/WKF-37 - GRIA job polling properties specified in job-polling.properties. Maximum polling interval can be sepecified in addition to minimum and exponent.
• WKF-35 - contrib.jar now included in freefluo WAR
• WKF-32 - beanshell (bsh) JAR now included in freefluo WAR

Version 1.0.0

Bug fixes and upgraded to use latest GRIA Workflow Plugins v1.0.0 and GRIA Client v4.3.0 RC1 libraries.

Version 0.1

Initial release of workflow service.

Known issues

WKF-23 - Workflow instance context directory

A file system directory should be provided for each workflow instance so that workflow logic can write files to the filesystem safely. Presently, workflow authors are responsible for ensuring they don't inappropriately overwrite others files and for cleaning up file system resources.

A local processor to safely create a unique temporary file can be created easily in Taverna. This can be used by workflow authors when they need to download data from a GRIA server to a unique file safely.

WKF-26 - Edit deployed workflows

It's not possible to edit a deployed workflow. The workflow must be deleted and redeployed. Doing so breaks clients of the workflow.

Advanced users may workaround this by editing the database files under $TOMCAT_HOME/freefluo/WEB-INF/workflows. It's advisable to create a backup of the $TOMCAT_HOME/freefluo directory before doing this in case problems are encountered and you need the server restored to its previous state.

WKF-36 - java.lang.OutOfMemoryError

The Tomcat process runs out of memory easily and this maybe related to the size of the client.state file that the Freefluo service has been configured to use.

There are two things that may help workaround this issue.

Firstly, usually the majority of GRIA Job and GRIA Upload processors can be configured to clean up their resource allocations when the workflow finishes. It's not suitable to configure all processors to do this. In particular, processors that produce the output data in a workflow shouldn't be configured to do this, as the output data is needed by clients of the workflow. Any remaining resources in the client.state file can be cleaned up intermittently and when required in the normal way using the GRIA command line client.

Secondly, the max heap size for Java can be increased to make more memory available to Tomcat. This can be done by inserting the following near the start of the file $TOMCAT_HOME/bin/catalina.sh

WKF-39 - Authorisation delegation

If a subject owns a data stager, they can give permission for a second subject to read or write the data stager. However, it isn't possible to give permission for the second subject to itself give permission for a third party to read or write the data stager. This can cause problems when there are chains of interactions between subjects that exchange references to data stagers.

A simple GRIA copy application is provided. This should be deployed to a GRIA server. A copy step in a workflow can be used to create a copy of the data in a new data stager so that data can be made available to third parties.