A global workflow (we call it an external transaction, or extran ) T(ij) is defined as a collection of tasks between two objects O(i) and O(j). This consists of a message sent from O(i) to execute a desired action in O(j); this message is received by O(j).O(j) has a behaviour specified by: Pre(T(ij)), G(j), F(j), Post(T(ij)), where Pre() and Post() are, respectively, the pre- and post-states that are active before and after the transaction T(ij). G(j) is a guard of O(j), and F(j) is the command function consisting of operations that map values to values in local domains (note that the operations used in G(j) and F(j) are assumed to be defined) and sending messages. Thus the script specifies what message O(j) can accept and what actions it performs when it receives the message while in state Pre(T(ij)) to satisfy the postcondition Post(T(ij)). The extran T(ij) can trigger in O(j) numeric, symbolic, or database computations .
Each extran T(ij) triggers a set of serializable computations in O(j), either in a total order or in a partial order depending upon whether parallelism, concurrency, and interleaving are possible locally within O(j). If the object O(j) is "made up" of subobjects, we may have to execute a workflow consisting of several local workflows (called an internal transaction, or intran ). After executing the intran, the system reaches a new state s' from old state s such that: s' = s - pre(T(ij)) post(T(ij)), using the command set F(j). This is analogous to the contract approach (Meyer, 1992a, 1992b) that is widely used in the language Eiffel. The precondition is specified by "require" and postcondition by "ensure" (Clark & Warmer, 2002; Jezequel, Train, & Mingins, 2000; Kramer, 1998; Meyer, 1992a, 1992b; Thomas & Weedon, 1998; Warmer & Kleppe, 1999; Wiener, 1996).
The extran and intran have more general properties than the four classical ACID properties (Bacon, 1993), as mentioned earlier. Therefore in extran and intran we modify the ACID requirements by four other new properties, called "chemical reactivity-like properties", resembling chemical reactions : molecularity, contractual obligation, opacity during a molecular action, and retry or rescue through a recovery protocol, bringing the system back into the invariant state. These are defined as below:
Molecularity : If there is a crash during a composite operation, all the effects of the sub-operation are lost. If there is no crash, the composite or molecular operation is complete. That is, a molecule is synthesised fully or not at all.
Contractual obligation : Invocation of a single composite operation takes the program from one consistent state to another. This means precondition and postcondition of a contract hold. Thus conventional consistency is replaced by contractual obligation (Jezequel et al., 2000; Kramer, 1998; Meyer, 1992a, 1992b; Thomas & Weedon, 1998; Warmer & Kleppe, 1999; Wiener, 1996).
Opacity : The results of the sub-operations of the composite operation should not be revealed until the composite operation is complete.
Durability : If a crash occurs and contract fails and a component cannot meet its obligation and fails in its contract, an exception is raised. Then we have three possibilities:
Exception is not justified: it is a false alarm; we may ignore.
If we have anticipated the exception when we wrote the routine and provided an alternative way to fulfil the contract, then the system will try that alternative. This is called resumption (Meyer, 1992, 1995).
If, however, we are still unable to fulfil the contract, we go into graceful degradation or surrender with honour. Then bring all the objects to an acceptable state (precommitted state) and signal failure. This is calledorganized panic. This should restore the invariant. At this point we initiate retry. The effect of retry is to execute the body of the routine again.
Remark: In Eiffel the rescue clause does all the above (this is essentially restart after recovery in transaction processing; Jezequel et al., 2000; Kramer, 1998; Meyer, 1992a, 1992b; Thomas & Weedon, 1998; Warmer & Kleppe, 1999; Wiener, 1996).
Also in MOPS, the chemical reactivity properties are generalized further: Since a number of remote objects are invoked, the coordinators SC and CC should ensure all the remote actions and the local actions are complete. If any one fails, the whole program has to be abandoned , and we need to retry, rescue, and bring the system to its invariant state. Contractual obligation is extended to all objects under concurrent invocation and partial failures.
No results are revealed from any objects until all the actions are complete and the coordinator commits.
Retry/Rescue and Reset : If it is a false alarm, then retry; else rescue and restart so that all the invariants in all objects are reset to their pre-action state.
Recall that we have two types of transactions ‚ extran (external transaction) between a C and an S, and intran (internal transaction) that takes place locally within each C or in S. We split the extrans into intention and action transactions; the intention transactions are local to each C or S and based on the decision in this phase, and the action transaction takes place through a protocol called intention-action (IA) protocol. The IA protocol provides a time-out strategy and recovery to cope up with failures of disconnection.
Workflows can be classified into the following types:
Attribute-sensitive : The tasks are to be committed or aborted locally as well as globally depending upon their exact attribute values.
Attribute-tolerant : The tasks can be permitted to be locally relaxed in terms of constraints but globally consistent eventually.
Time-critical : These are tasks that are to be permanently committed within a very short time deadline.
Time-tolerant or eventually consistent : Some workflows can wait until reconnection takes place and have a longer time duration.
An essential requirement in all the above cases is the introduction of timeliness (time-tolerance) or other related constraints in the contract.
Certain special behavioural patterns (Gamma et al., 1995; Jezequel et al., 2000) of workflows occur in e-commerce applications. As described by Jezequel et al., such design patterns capture the intent behind a design by identifying the objects, their collaborations, their responsibilities, and a protocol for communication among them. Accordingly, a particular pattern is very specific to a particular application domain. In e-commerce we encounter most frequently the following patterns:
Conventional transactions with ACID properties : These occur at the lowest level of a workflow.
Supply chain or chain of responsibility workflow : These consist of a sequence of conventional transactions between a customer and a seller through a set of intermediary agents . The supply chain workflow is successful if and only if each individual transaction in the supply chain is successful. An abort in the chain will be considered unsuccessful , restoring the consistency of the initial state.
Mutually exclusive-collectively exhaustive workflow : Here, as in Example 1, there can be a single buyer and several suppliers to complete a given task through several mutually exclusive transactions and collectively exhaustive transactions. Here the workflow is considered successful only if all the mutually exclusive transactions are all committed. If any one is aborted, this workflow is unsuccessful and the initial states are restored.
Negotiated choice workflow : Here, as in Example 2, a customer can bargain and negotiate with several suppliers simultaneously to obtain a particular product at a bargain price. This workflow is successful if and only if one of the transactions is committed and soon after that time the rest of the transactions are aborted, respecting the contract. In the latter case, the states are properly restored.
There can be other workflow behavioural patterns which are combinations of the above patterns in e-commerce, depending upon the granularity, functionality, and structural features needed. These require further research based on the work of Gamma et al. (1995) and Jezequel et al. (2000).
A local commit of an intran is an intentional commit that contains all relevant details for an action commit of the extran that is bound by a contract between the buyer and seller that contains the required time-tolerance (timeliness) and other attribute tolerances.
The various types of workflow patterns arise in planning (subjunctive, or "what-if", programming), in which we execute hypothetical or pseudo-transactions to test the intention of actions for trial-error design. Such transactions arise in real-time transactions in patient-health monitoring, flight plans, and cooperating information systems consisting of interacting tasks involving stock inventory, shipping goods, purchasing, and market forecasting.