Table of Contents
The Workflow component leverages the same infrastructure stack as the caGrid toolkit (GT4, Tomcat, Java, Ant, and Introduce) with the addition of the ActiveBPEL workflow engine. The WorkflowFactoryService is a standard Introduce-built grid service that allows a workflow to be created from a BPEL workflow document. An EPR is returned to a WorkflowManagementService resource that can be used to start, stop, pause, resume, cancel, and destroy the created workflow. The WorkflowManagementService is layered on top of the ActiveBPEL workflow engine, which provides the primary functionality for running the BPEL-defined workflow. See Figure 1 for an overview of this architecture.
The following actions are performed when a user invokes start on the workflow management service:
- The input BPEL document is parsed and an exception is thrown if it is not well-formed (with respect to schema compliance).
- The input arguments to the workflow are declared as an array of xsd:any. They are parsed and cast to the types that they are meant to be.
- The service implementation invokes PDDGenerator to generate the deployment descriptor for the workflow.
- The service implementation invokes BPRGenerator to generate the BPelArchive (called bpr hereafter) that is ready to be deployed.
- The workflow management service is bootstrapped with the location of ActiveBPEL admin service location.
- The service implementation invokes deployBpr operation on the admin service, which is a vanilla Axis-based Web Service, to deploy the workflow created.
- The admin service responds with deployment summary reporting success if the workflow is deployed successfully.
- Once the workflow is deployed successfully, it is deployed as a web service inside ActiveBPEL.
- To start the workflow, a message is sent to the receiving partnerLink in the workflow.
- After the workflow successfully executes the results are returned to the client app/user by a call to getWorkflowOutput
Workflows are created using the WorkflowFactoryService, which is a grid service that follows the resource pattern. The returned object holds an EPR to a WorkflowManagementService, which can be used to manipulate the create workflow.
Public WorkflowFactoryOutputType createWorkflow(WorkflowDescriptionType wmsInputType) throws WorkflowException()
This method creates a workflow resource from the BPEL document found in wmsInputType and returns an EPR of the created resource to the client. The BPEL resource, along with the most recent state, is persisted in a MySQL database and is recovered in the event of a container crash.
This is the input to createWorkflow, and it consists of workflowName , a String bpelDoc, an Array of wsdlReferences, and an initial termination time for the workflow. If the termination time is not specified the service defaults to 24hrs. Termination of the workflow invalidates the WorkflowManagementService EPR and any running workflow is stopped.
This is the output of the createWorkflow method. An EPR is constructed by the factory and returned to the client. At this point the workflow document is deployed in the workflow engine and is also stored in a database, but it has not started. The EPR points to an instance of the WorkflowManagementService, which should be used to start the workflow.
This fault is thrown if the workflow is unable to be deployed (e.g. the BPEL document submitted fails pre-deployment validation).
This fault is throw if the BPEL document submitted fails pre-deployment validation (e.g. not valid XML).
We intend to provide aggregate resource properties on the factory service in our next iteration. Following are some of the examples of those:
- Total number of workflows
This service is used to manage the workflow resources created by the WorkflowFactoryService. The service provides asynchronous execution of deployed workflows. The following are the operations the service provides in addition to the standard WS-RF operations such as destroy(), setTerminationTime(), etc.
Public WorkflowStatusType start(StartInputType input) throws WorkflowException, StartCalledOnStartedWorkflowFault
This operation is used to start the workflow deployed using the factory with a set of input parameters. The input parameters are modeled as an array of xsd:any elements. The output is a void type.
StartCalledOnStartedWorkflowFault: This is thrown if start() is called on a workflow that is not in any one of the terminal states (i.e. Done, Failed, Cancelled).
WorkflowException: Every other fault results in the service throwing this with a message describing more details as to what went wrong.
Public WorkflowStatusType getStatus( ) throws WorkflowException
This operation is used to query for the status of the deployed workflow. WorkflowStatusType includes a fault.
Public WorkflowStatusType pause() throws CannotPauseFault
This operation pauses the workflow until resume() or cancel() is invoked. This operation translates to invoking an equivalent operation provided in the ActiveBPEL Admin interface. When the pause operation is invoked, ActiveBPEL stops the execution of the workflow document which means that there would no further service invocations or other activities. However, this will not affect the invocations in progress when the pause() is invoked. This operation returns the new state of the workflow resource (which always should be Active).
Public WorkflowStatusType resume() throws CannotResumeFault
This operation resumes a paused workflow. It translates to invoking an equivalent operation provided in the ActiveBPEL Admin interface.
Public WorkflowOutputType getWorkflowOutput() throws WorkflowException
This operation is used to get the final output of a completed workflow. It will return a fault if the workflow is not yet completed. If ActiveBPEL allows for intermediate access of results, then this operation can potentially return the last result that the workflow engine has for this workflow. The output is modeled as a array of xsd:any elements.
Public void cancel() throws WorkflowException
This operation terminates a workflow. It translates to invoking equivalent operation provided in the ActiveBPEL Admin interface.
The status of a workflow is exposed as a Resource Property so clients can subscribe to it and get notified when a state change happens. WorkflowStatusType is modeled as an Enum of Strings with the following valid values:
- Pending (Created but Start has not been called)
The status also includes the latest fault a workflow execution throws.
This property denotes the time when start() operation is called on the resource.
This property denotes the time when workflow status is set to Done/Failed/Cancelled.
Public void destroy()
This is a standard WS-RF operation but mentioned here to clarify the semantics and what it means to a Workflow Resource. If called, this method will delete a Workflow resource from the database along with the intermediate results and subscriptions for notifications. This operation is called by the GT4 framework when the lifetime of a resource is expired. The lifetime is set in the initial create() call in the factory. Internally, destroy() removes all the database entries for a particular workflow resource, all the subscriptions for notifications, and other temporary resources both in memory and on the disk.
Two types of deployment patterns for Workflow are needed in regards to security. One deployment scenario would have the factory and the context service running with grid security (using Transport level security and caGrid authorization) and would require a client present grid credentials to submit and run workflows. Once a workflow resource is created by a user, programmatic GridMap authorization is used to limit access to the resource to the creator of the resource. Delegation of credentials is performed using the delegation service of the Globus Toolkit. This deployment is used to orchestrate workflows that require secure access to any services involved in the workflow. The other deployment does not have any security and is used to orchestrate workflow between unsecured grid services.
A Custom invoke handler is written for ActiveBPEL that queries a pre-configured GT4 index service to get the list of services. The query would be based on input and output types of the service invocation. Once a list of service handles is obtained from the index service, the dynamic endpoint for the service invocation is replaced by the first endpoint in the list.
This is out of scope for this component during this release. No provenance tracking is exposed via the workflow component.
A BPEL service can involve affecting state of a WS-RF resource. Additional support needs to be added to ActiveBPEL to pass WS-A headers that contain EPRs and other relevant info to caGrid services.