Quartz 4

26.2 Transactional Workflows

6 min read

Definition and Examples

  • Workflow: An activity involving multiple coordinated tasks executed by different processing entities. It’s about how work gets done, step-by-step.

  • Task: A unit of work to be done. It can be specified in many ways (text description, form, message, program).

  • Processing Entity: The “actor” that performs a task. Can be a person or a software system (e.g., mailer, application, DBMS). Other terms: Task Flow, Multisystem application, Steps.

  • Examples (Figure 26.3):

  • Electronic-mail routing:

    • Typical task: Sending/forwarding an email message.
    • Typical processing entity: Mailers (software).

  • Loan processing:

    • Typical task: Form processing (checking, verifying, approving).
    • Typical processing entity: Humans, application software.

  • Purchase-order processing:

    • Typical task: Form processing.
    • Typical processing entity: Humans, application software, DBMSs.

  • Loan Processing Workflow Example (Figure 26.4):

  • Describes a loan application process, with steps like form filling, verification, approval, and disbursement, involving interactions between a customer, loan officer, and superior officer.

  • Why Workflows are Important:

    • Organizations have multiple software systems that need to interact.
    • Increasing automation of services.
    • Need to coordinate tasks when orders are placed (e.g., reserve production time, delivery).

  • Two main activities to automate workflow: 1. Workflow Specification 2. Workflow Execution.

26.2.1 Workflow Specification

  • Goal: Define the tasks and their execution requirements.
  • Internal of task: It does not need to be modeled.
  • Abstract View of a task:
    • use parameter that stored in it’s input variable.
    • Update data in local system.
    • Store data in output variables.
    • Query about execution state.

  • Workflow State: At any time during execution, this is the collection of states of all constituent tasks and the values of all variables in the workflow specification.

  • Coordination of Tasks: Can be specified statically or dynamically.

    • Static Specification: Tasks and dependencies are defined before workflow execution begins. Example: Expense voucher approval (secretary → manager → accountant → check).

      • Generalized Static Specification: Use preconditions for each task. All possible tasks and dependencies are known, but only tasks with satisfied preconditions are executed.

    • Dynamic Specification: Tasks and dependencies are determined during execution. Example: Email routing (next hop depends on destination address and router availability).

  • Preconditions (for Static/Generalized Static Specification):

    • Execution States of Other Tasks:

      • Example: “Task cannot start until task has ended.”
      • Example: “Task must abort if task has committed.”

    • Output Values of Other Tasks:

      • Example: “Task can start if task returns a value greater than 25.”
      • Example: “Manager-approval task can start if secretary-approval task returns ‘OK’.”

    • External Variables (modified by external events):

      • Example: “Task cannot be started before 9 A.M.”
      • Example: “Task must be started within 24 hours of the completion of task .”
    • Logical Connectors: use logical connectors (and, or, not).

26.2.2 Failure-Atomicity Requirements of a Workflow

  • Failure Atomicity: Traditional definition (all-or-nothing) is often too strict for workflows. Workflows may need to survive the failure of individual tasks.
  • Failure-Atomicity Requirements: It defined by the workflow designer.

  • Acceptable Termination States: States that satisfy the workflow’s failure-atomicity requirements, as defined by the designer. These can be:

    • Committed Acceptable Termination State: Workflow objectives have been achieved.
    • Aborted Acceptable Termination State: Workflow objectives have not been achieved, but the state is still valid according to the failure-atomicity rules. Any partial effects must be undone.

  • Nonacceptable Termination States: States that violate the failure-atomicity requirements.

  • System Responsibility: The system must ensure that every workflow execution ends in an acceptable termination state, even in the presence of failures. If a failure leaves the workflow in a nonacceptable state, it must be brought to an acceptable state during recovery.

  • Example (Loan Processing):

    • Committed Acceptable: Loan approved and disbursed, or loan rejected.
    • Aborted Acceptable: Loan application returned to the applicant due to a system failure (e.g., long verification system outage).

  • Compensating Transactions: Used to undo the effects of committed subtransactions if the overall workflow needs to abort.

    • A compensating transaction must eventually complete successfully (possibly after multiple retries).
    • Example: Reduce the department budget balance on voucher approval, and use compensating transactions if later rejected.

26.2.3 Execution of Workflows

  • Control Mechanisms:

    • Human coordinator.
    • Workflow-Management System: Software system.

  • Workflow-Management System Components:

    • Scheduler: Submits tasks for execution, monitors events, and evaluates conditions related to intertask dependencies. Enforces scheduling dependencies.
    • Task Agents: Control the execution of tasks by processing entities.
    • Query Mechanism: Allows querying the state of the workflow system.
    • Multidatabase transactions: tasks are subtransactions and processing entites are local DBMS.

  • Architectural Approaches to Workflow-Management Systems:

    • Centralized Architecture: A single scheduler manages all concurrently executing workflows.
    • Partially Distributed Architecture: One scheduler per workflow. Good when concurrency control can be separated from scheduling.
    • Fully Distributed Architecture: No central scheduler. Task agents communicate directly to coordinate execution and satisfy dependencies.

  • Simple Workflow Execution (Fully Distributed, Messaging-Based):

    • Uses persistent messaging (guaranteed delivery).
    • Email can be used (but doesn’t guarantee atomicity of message delivery and transaction commit).
    • Task agents at each site execute tasks.
    • Messages between agents contain all relevant task information.
    • Useful on disconnected networks.

  • Centralized Approach:

    • Data store in central database.
    • The scheduler notfies various agents.
    • keep tracks of task completion.
  • Scheduler guarantee: Scheduler must gurantee a workflow will terminate in one of the specified acceptable termination states.
  • Workflow Safety: Ideally, the scheduler should check if a workflow can terminate in a nonacceptable state before execution. If so, the workflow specification should be rejected. If this check is impossible/impractical, the responsibility falls on the workflow designer.

26.2.4 Recovery of a Workflow

  • Objective: Enforce the failure-atomicity requirements of workflows.

  • Recovery Procedures: Must ensure that, after a failure, the workflow eventually reaches an acceptable termination state (either committed or aborted).

  • Scheduler Options after Failure:

    • Continue processing as if nothing happened (forward recoverability).
    • Abort the entire workflow.

  • Subtransaction Handling: Some subtransactions may need to be committed or submitted (e.g., compensating transactions) during recovery.

  • Assumptions: Processing entities have their own recovery mechanisms.

  • State Information to Restore:

    • Scheduler state at the time of failure (including task execution states).
    • Must be logged on stable storage.

  • Message Queues: Contents must be considered.

  • Handoffs Between Agents: Must be exactly once.

    • If handoff happens twice, a task might be executed twice.
    • If handoff fails, the task might be lost.
    • Persistent messaging (Section 19.4.3) provides exactly-once semantics.

26.2.5 Workflow-Management Systems

  • Goal: Simplify workflow construction and improve reliability by allowing high-level specification and automated execution.
  • ERP System: workflow often hand coded as part of application system.
  • Many Commercial systems are avaliable.
  • Interorganizational Workflow: Workflows that cross company boundaries.
  • Business Process Management: Workflow Management that related to business processes.
  • Service-Oriented Architecture(SOA): System architecture is based on invoking services.
  • Orchestration: Process logic that controls the workflow.
  • Standard:
    • Web services Business Process Execution Language (WS-BPEL): XML based standard.
    • Business Process Modeling Notation (BPMN): Standard for Graphical Modeling.
    • XML Process Definition Language (XPDL): XML based representation.

Graph View

Backlinks