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:
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 DRER passes the workflow to the OGSA-DAI activity framework.
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.
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:
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:
If the request is asynchronous: