Prev   Next

Appendix K. OGSA-DAI request execution specification

K.1. Request execution
K.2. Request execution status
K.3. Request status

K.1. Request execution

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

  • 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 executing its maximum number of workflows then the request will be queued. If the queue is 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 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 request to the workflow engine.
  • From this point on any errors will be written to the request resource's request status. If the request was asynchronous then the DRER will return to the client the current request status, the request resource ID and, if a new session was created, the session ID.
  • The workflow is validated to ensure that there are no unconnected inputs or outputs.
  • The workflow is validated to ensure that all the specified resources and activities exist and that activities targeted at resources and actually supported by those resources.
  • The workflow execution now commences.
  • 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.
    • A target resource is nable to connect to a database.
    • The client has provided an invalid database query as an input literal.
  • The workflow executes until finished or terminated by the client via the request resource. During execution overall status and activity status information is written to the request status. Data may also be written to the request status. For asynchronous requests, 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.
  • If the request was executed synchronously then the final request status will be returned to the client and the request resource destroyed.
  • If the request was executed asynchronously then the request resource will be set to terminate in 24 hours.

K.2. Request execution status

A request execution status is a constant value indicating the status of execution of a workflow. It is accessible to clients as a RequestExecutionStatus resource property of a request resource.

If a workflow executes successfully the request execution status will begin at UNSTARTED, change to PROCESSING when the workflow is being processed and finally change to COMPLETED when the workflow has completed successfully. There are other status values associated with errors and premature request termination. All the status values are described in Table K.1, “Request execution status values”. Note that all the status values are, in practice, prefixed by the namespace uk.org.ogsadai.resource.request.status. For example, COMPLETED is actually uk.org.ogsadai.resource.request.status.COMPLETED.

Status valueMeaning
UNSTARTEDRequest has not started processing.
PROCESSINGRequest is processing and no activities are in error.
COMPLETEDRequest has completed successfully
COMPLETED_WITH_ERRORRequest is processing but some activities are in error.
TERMINATEDRequest has been explicitly terminated.
ERRORRequest encountered an error prior to processing.

Table K.1. Request execution status values


While the request execution status provides an easy and efficient way of monitoring, at a high level, the execution of a request, lower level activity status details and result data can be obtained from the request status.

K.3. Request status

A request status is a complex, dynamic value indicating the status of execution of a workflow at discrete point in time. It is returned by a DRER in response to a workflow submitted by a client and, for asynchronous requests, is accessible to clients as a RequestStatus resource property of a request resource.

The request status is a dynamic data structure that is part of the state of a request resource. The request status contains three portions of data:

  • Request details.

  • Activity details.

  • Result data.

The request details section contains the same request execution status as can be obtained from the RequestExecutionStatus resource property (see Section K.2, “Request execution status”). It also contains any top-level error information.

The activity details sections contains a status value for each activity in the workflow (UNSTARTED, PROCESSING, COMPLETE, etc.). It may also contain errors and warnings produced by the activities.

The result data section contains any data written to the request status by activities. Most activities do not write data to the request status but OGSA-DAI includes one activity, called DeliverToRequestStatus, that can be used to write the data it receives to the request status. This is sometimes used in conjunction with synchronous requests.

The request status will be continually updated while the request is being executed. Clients can read the current value of the request status using the RequestStatus resource property of the associated request resource at any point during the request's execution. It is recommended best practice that clients only read the RequestStatus resource property once and that this is done after the request is known to have finished. The more efficient RequestExecutionStatus resource property can be used to monitor the execution of a request.

Prev   Next
Appendix J. OGSA-DAI resources specification Home Appendix L. OGSA-DAI services specification