Introduction

The GRIA Workflow Service (Freefluo) is a task orchestration tool and interpreter for executing workflows. A workflow describes a graph of executable steps and also describes how data and control should be passed between steps at runtime.

This release includes a J2EE web application (WAR) that can be deployed along side an existing GRIA Services installation. The web application includes web-based administration tools for configuration and deployment of workflows that have been authored using Taverna. Deployment of the web application exposes a SOAP web service that clients can use to execute workflows in a similar manner to which they can execute a GRIA job in a workflow.

The Freefluo web service utilises the secure web service infrastructure of GRIA. WS Security is used for message integrity and Process based access control (PBAC) for managing dynamic authorisations.

Architecture

The diagram below shows the component architecture for GRIA.

GRIA component architecture

Freefluo is an optional GRIA Service that can be deployed to an existing GRIA Services installation. If you decide to deploy Freefluo, you will also need to install the GRIA Client and Taverna (with GRIA Workflow Plugins), as these are required for administration.

An overview of the workflow development and deployment process - undertaken by a GRIA services administrator (admin) - is given in the diagram below.

Workflow development and deployment

A GRIA services administrator wishes to compose a workflow and deploy it to their Freefluo service so that clients can use (and utimately be charged for) its functionality. The GRIA command line client is used to request an account with any GRIA service providers that will be used in the workflow. If only local services are to be used, the admin can approve the account themselves. However, if other service providers are to be used, the admin may have to wait for out-of-band account approval before continuing. Accounts can be reused of course, so it's not necessary to open an account with a service provider for each workflow. After account approval, the admin can use Taverna for workflow authoring and testing. After testing, a web browser and the Freefluo web interface is used to deploy the workflow. After deployment, Taverna can be used by the admin to test the deployed workflow.

An overview of the client process of discovering and executing a workflow is provided below.

Workflow discovery and execution

To be able to execute a workflow, a client must hold an account with the service provider that hosts the workflow. If an account isn't held with the service provider, the first step is to request one using the GRIA Client. The client must wait for notification of account approval. The approval of the account by the service provider's administrator is asynchronous and the notification to the client is out-of-band (e.g. e-mail). Taverna is used to query the service provider's Freefluo service to discover workflows before selecting one for execution. When the workflow is executed Taverna provides the ID of the client account so that the service provider can bill the client appropriately. Note that whilst the sequence shows requesting an account before discovery, it's also possible to discover available workflows before deciding to open an account with a service provider.

Client accounts are quite separate to any used by a service provider for it's internal billing when resources are used by the workflow. When a remote workflow is executed, the workflow process will accumulate charges for the resources used. The service provider's account(s) will be billed for this resource usage. The idea is that when a client uses a remote workflow, the client's account will be billed appropriately for workflow execution. The service providers policy for transferring to the client the charges it has incurred in workflow execution, isn't currently addressed, though a pluggable business policy is invisaged.

In the descriptions above, a single client and service provider have been assumed. In reality, a service provider will often be a client also. The diagram below illustrates some of the interactions that can occur between services providers. In this example, service provider GRIA 2 hosts some useful GRIA applications and workflows. GRIA 1 composes a workflow out of these components and hosts it on its Freefluo server. The Client composes its own workflows from the workflow at GRIA 1 as well as some GRIA applications at GRIA 1. The business and technical relationship between GRIA 1 and GRIA 2 is entirely hidden from the client. The client has no knowledge of how GRIA 1 implements its services.

Service provider interactions

Related components

GRIA documentation and software downloads are available from the GRIA homepage. Taverna information and user documentation can be found at the Taverna project site.

GRIA Workflow Plugins 1.1.0 has been released along with this distribution and is needed for use with Taverna to author workflows that can be deployed to a GRIA Workflow Service instance.