WID 6012.9 References How to
WID V6.0.1.2, Interim Fix 009
Table of Contents
Short-Running and Long-Running Processes
Short-Running and Long-Running Processes
Source:
WebSphere Business Integration Primer: Process Server, BPEL, SCA, and SOA
by Ashok Iyengar, Vinod Jessani and Michele Chilanti
IBM Press © 2008
WebSphere Process Server supports two types of processes: short-running and long-running. Occasionally you will see the terms microflows and macroflows to describe short-running processes and long-running processes, respectively. The type of process determines the activities the process can perform.
A short-running business process has the following characteristics:
-
Completes in a short period of time
-
Runs in a single transaction
-
Its state is transient and is not persisted to a database in between activities
-
Should invoke only synchronous services and other short-running subprocesses
A long-running process has the following characteristics:
-
Can run for hours, days, or even years
-
May run as several transactions
-
Invokes synchronous and/or asynchronous services
-
Stores each intermediate process state, which makes the process forward-recoverable
-
Involves human interaction or wait activities
Transaction Characteristics of Processes
As stated earlier, one of the differences between a short-running process and a long-running process is its transactional characteristics. As shown in Figure 3.3, all the activities in a short-running process are executed in a single transaction. Services that are invoked by a short-running process may or may not participate in that process’s transaction. Services that participate in a short-running process’s transaction are automatically rolled back if the process’s transaction is rolled back. However, if they do not participate in the transaction, they stay committed.
Figure 3.4 illustrates transactions in a long-running process. Each activity is executed in its own transaction, with the process engine storing the state of the process in a database between activities. The failure and rollback of any one of those transactions does not affect any previously committed transactions. As a result, services that are invoked in a previously committed transaction remain untouched."Global Transaction"
A global transaction is a unit of work in which the activities of multiple services (such as Resource Managers) are coordinated by an external transaction coordinator that is responsible for ensuring that all the services either complete successfully or roll back. For a Resource Manager to be able to participate in such a transaction, it needs to support the two-phase commit protocol. Not all Resource Managers support this protocol. Additionally, long-running processes execute each of their activities in separate transactions. In these cases, services cannot be automatically rolled back by the transaction coordinator.
To undo the changes in these cases, you can use BPEL’s Compensation Handler feature.
Versioning BPEL Processes
As you have seen, long-running processes can run for a very long time. However, businesses might have a need to update their business process periodically to meet changing requirements. For example, a company might need to update how claims processing is done at the beginning of each year.
All existing process instances are serviced by the version of the BPEL process that was used to create them. New process instances are created using the latest version of the process. Runtime servers use different approaches to “switch over” to the new process instance. WPS uses a timestamp-based approach to support versioning of BPEL processes such that different versions of a process with the same name and interface can be active concurrently by using different validFrom timestamps. Chapter 10, “Business Integration Services Management,” discusses versioning of BPEL processes in greater detail.
No comments:
Post a Comment