Chapter 13. How requests (workflows) are executed

13.1. Acceptance by the DRER
13.2. Pre-processing by the activity framework and engine
13.3. Workflow execution

As previously stated, when a workflow is executed by OGSA-DAI, the activities in the workflow execute in parallel. Data streams through the activities in a pipeline-like way, through fixed-size buffers termed pipes, with each activity operating on a different portion of the data stream (if the activities are well defined) at the same time.

When a DRER receives a request to execute a workflow from a client the following occurs:

13.1. Acceptance by the DRER

A workflow is initially received by a DRER which does a number of checks and actions before accepting it and handing it over to the OGSA-DAI activity framework.

  • The request is authorized in the presentation layer using plug-in authorization functionality if supported.
  • The DRER checks to see if its workflow engine is already executing its maximum number of workflows then the request will be queued. If the queue is already full then the request is rejected.
  • A request resource is created for the request. If the client has provided a request ID and this is not already taken then this ID will be used. If it is taken then the request is rejected. If the client did not supply an ID then a unique ID will be generated.
  • If requested by the client, a new session is created or the request is joined to an existing session.
    • If the client requested creation of a session then a session is created. If the client has provided a session ID and this is not already taken then this ID will be used. If it is taken then the request is rejected. If the client did not supply an ID then a unique ID will be generated.
    • If the client requested that the workflow execute in the scope of an existing session then a session with the session ID provided by the client is sought. If none is found then the request is rejected.

The DRER passes the workflow to the OGSA-DAI activity framework.

13.2. Pre-processing by the activity framework and engine

The activity framework parses and validates the workflow. The workflow is validated to ensure that there are no unconnected inputs or outputs. It is also validated to ensure that all the specified resources and activities exist and that activities targeted at resources are actually supported by those resources.

It then creates activity objects for each activity in the workflow and pipe objects for the connections between activity inputs and outputs.

Each activity object given the objects it needs via reflection on the interfaces supported by the activity. We call these activity interfaces and the objects the pass to an activity include resources, security contexts, the OGSA-DAI resource manager, configuration properties, service URLs - it depends upon the activity.

The workflow is handed over to the activity framework's engine for execution.

13.3. Workflow execution

The workflow execution now commences - every activity is started simultaneously. Activities pull blocks from their input pipes, other activity outputs or input literals, and correspondingly push (processed) blocks onto their output pipes.

Any errors occurring within an activity will be written to that activity's section of the request status. Examples of the type of errors can that occur within an activity include:

  • A request input is missing.
  • An output is missing.
  • Invalid input data - an activity is connected to another activity that provides data of the unexpected type or is otherwise illegal.
  • A data resource is unable to connect to a database.
  • The client has provided an invalid value as an input literal.

The workflow executes until all its activities have finished, or one throws an error or it is terminated by the client via the request resource.

During execution, the overall request execution status and individual activity status information is written to the request status. Data may also be written to the request status.

If the request is synchronous:

  • The DRER will not return anything to the client until the request has completed.
  • When the request has completed, the final request status will be returned to the client and the request resource destroyed.

If the request is asynchronous:

  • The DRER will immediately return to the client the current request status, the request resource ID and, if a new session was created, the session ID.
  • Clients may view the current value of the request execution status and the request status using the corresponding resource properties of the associated request resource.
  • The request resource will be set to terminate in 24 hours.