MOBILE WORKFLOW

Mobility is central to many applications involving telemedicine. This arises due to the fact that the patients , doctors , and data collecting instruments can always be on the move. Hence any transaction that occurs among the clients and servers is a mobile transaction. A mobile transaction is a distributed transaction that can be executed partly within that mobile client (MC) as internal transactions (intran) and partly in other fixed hosts (FHs) as external transactions ( extran ). Each FH has a coordinator FHC that receives external transaction operations from mobile hosts and monitors their execution in the database servers within the fixed network. Similarly each MC has a coordinator MCC.

In a mobile environment, some of the properties of the traditional transaction model (see Chapter 2 of this book; Krishnamurthy & Murthy, 1992) that enforces atomicity,consistency, durability, and isolation have to be replaced by a more realistic model in which the isolation property is removed and intermediate results are made visible. Also precedence order in execution and other dependencies have to be taken care of; this means we must remove the atomicity restrictions. Such a model turns out to be a workflow model between the MC and FH.

A workflow is a collection of tasks organized to accomplish some business activity. Here each task defines some unit of work to be carried out. A workflow ties together a group of tasks by specifying execution dependencies and the dataflow between tasks. Also there could be a constraint that a particular task cannot begin until some other task ends. Such constraints can be specified by event-action systems.

In a workflow model we need to ensure correctness and reliability of workflows. Correctness means that the concurrent execution of transactions and workflows is interleaved in a way that incorrect results such as lost update or inconsistent retrieval cannot occur. Recovery means both the tasks and the transactions are recoverable in the event of a failure arising due to disconnection.

Thus we need to satisfy the following requirements:

1. A programming paradigm to support a combination of transactions that satisfy atomicity, consistency, isolation, and durability (ACID) properties, and workflow tasks that do not have such ACID properties.

2. A method of managing control flow of workflow and transactions.

3. A suitable recovery model under failure of the workflow. This recovery is very complex compared to short transactions since it will require reinstantiation and following the control flow of actions strictly .

4. Contextual information (Henricksen et al., 2002; Mattern & Naghshineh, 2002) that preserves the consistency of databases as well as the local state of the application.

5. Remembering the execution history and path and local states produced in the past.

6. Externalization of preliminary results: workflow computations need to externalize their results before they are completely done. This implies that unilateral rollback is no longer possible; one needs to specify compensating actions as part of the control flow description.

7. Concurrency and consistency control: Consistency can no longer be based on serializability only; we must now allow for application-oriented policies of synchronizing access to shared objects.

8. Conflicts handling: In general, it is not feasible to let some surgical or diagnosis activity wait in case of a resource conflict until a long-duration activity has completed. Nor is it acceptable to roll it back to the beginning. Therefore the control flow description has to specify what should be done if a resource conflict occurs and how it can be resolved using priorities and context. For example, in an emergency, it is necessary to suspend less critical tasks and postpone them for a later time.