IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerworks > My developerWorks >  Dashboard > Bobby Woolf: WebSphere SOA and J2EE in Practice > Miscellaneous Technologies > Business Process
developerWorks
Log In   View a printable version of the current page.
Overview Connect Spaces Forums Wikis
Business Process
Added by bwoolf, last edited by bwoolf on Jun 27, 2006
Labels: 
(None)

Business Process

Business process, aka workflow (I use the terms interchangeably), as in the BP part of BPEL.

A BP can be interruptible or non-interruptible. This is independent of compensating transactions.

Interruptible vs. Non-Interruptible

Workflows are sometimes characterized as macro or micro; I prefer the terms interruptible and non-interruptible, which I find more descriptive. The basic difference is that a non-interruptible process runs in a single transaction (a commit point at the start and at the end), whereas an interruptible process can contain commit points.

Commit points enable an interruptible process to group activities into units of work. Activities are usually (these days, with SOA and all) implemented as services. A single service is often (usually?) its own transaction. For a workflow to group multiple services into a transaction, the service must be able to participate in an external transaction (one defined and controlled by the workflow), which is usually a distributed transaction. If a service implements its own transaction and cannot/will not participate in an external transaction, then it cannot be used to implement an activity in a non-interruptible workflow.

A workflow must be interruptible for an activity to be implemented as a human task or for an activity to invoke a service asynchronously. These implementations require commit points to isolate the workflow from the provider (the human's GUI or the asynchronous messaging system).

Non-interruptible workflows require less overhead for the workflow engine to execute, and so are usually better for performance and scalability.

Compensating Transactions

A compensating transaction is an activity that reverses the changes made in a previously committed transaction. When multiple activities need to be performed as a unit a work, but each implements its own transaction and they cannot participate in an external transaction, then there is no single transaction that can be used to rollback the unit of work. Rather, each activity must have a corresponding compensating activity that undoes what the activity does; for rollback, the workflow executes the compensating activities for the activities that successfully completed, and executes them in reverse order.

Compensating transactions are really only an issue for interruptible workflows, since a non-interruptible workflow requires its services to run in its transaction, and therefore can roll them back when it rolls back.


 
    About IBM Privacy Contact