MOBILE OBJECT PROGRAMMING SYSTEM

A mobile object programming system (MOPS) is interpreted as a collection of objects consisting of intergalactic clients and servers interacting through messages. Each object maintains its own share of data and has its own program piece to manipulate it. That is, each object combines data structure and functionality. The objects are active and behave like actors in a movie, each following its own script and interacting with other objects. By modelling a problem as a set of cooperating concurrent objects, we can obtain higher descriptive power and clearer understanding because we have only one set of syntax and semantics for any object (Milner, 1999;Vitek &Tschudin, 1997). It is therefore not surprising that the technical skills arising from the two major areas in computer science, namely, object-oriented database techniques and concurrent programming techniques, are needed in order to blend the appropriate techniques and achieve a consistent framework for mobile object programming.

Use of the Contract-Based Workflow Model

A workflow is a collection of tasks (that include conventional transactions) 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 may 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 timeliness, correctness, and reliability of workflows. Timeliness in m-commerce is defined by the customers (sellers/ buyers ). This feature enables customers to decide just before committing whether the transaction satisfies timeliness; otherwise , the customer can reject or abort the workflow since a contract is violated. Correctness means that the concurrent execution of transactions and workflows between different customers are interleaved in a way that incorrect deliveries or inconsistent billing do not occur. Further, the commit and abort actions need to satisfy the following rules:

Commit: A workflow cannot commit unless all its subtasks commit.

Abort: If a parent workflow aborts, then all its children or subtasks should be aborted.

Recovery: Both the tasks and the transactions are recoverable in the event of a failure of a contract and subsequent abort.

Wachter and Reuter (1995) suggest the following requirements in their ConTract model:

1. A programming paradigm that can support a combination of transactions that satisfy ACID properties and workflow tasks that do not have the 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 that preserves the consistency of database, as well as the local state of the application (hoarding).

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

6. Externalisation of preliminary results: Workflow computations need to externalise 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 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 activity wait in case of a resource conflict until a long duration activity has completed, nor ist it acceptable to roll it back to the beginning. Therefore part of the control flow description has to specify what should be done if a resource conflict occurs, how it can be resolved, etc.

A contract is a consistent and fault tolerant execution of an arbitrary sequence of predefined actions (called steps) according to an explicitly specified control flow description (called a script). A script is a condition-event structure that describes a stereotyped sequence of events in a particular context. Scripts are useful because, in the real world, there are patterns in the occurrence of events. Events described in a script form a causal chain.

The ConTract model of Wachter and Reuter (1995) provides a formal basis for defining and controlling long-lived, complex computations in a manner analogous to a parallel programming environment with persistent local variables , accesses to shared objects, and synchronization facilities. The ConTract model uses short transactions as well as scripts to handle workflows.

In this chapter we will be guided by the spirit of the ConTract model, although we will add extra features for scheduling, conflict resolution, time-stamping, and recovery needed for the mobile environment. Also we will be using post- and preconditions and invariant predicates for ensuring consistency. A suitable log will be used for storing the history at both the C and the S to permit recovery. In our approach, however, we will introduce two forms of transactions ‚ extran (external transaction), which takes place between a C and an S, and intran (internal transaction), which takes place locally within each C or in S. The internal transactions have the ACID properties. The external transactions are split into intention and action transactions, where the intention transactions have the ACID properties while the action transactions are long duration transactions supported by a recovery protocol. The intention transactions are again local to each C or S and based on the decision in this phase; the action transaction takes place through a protocol (called intention-action (IA) protocol) provided with a time-out strategy and recovery to cope up with failures of disconnection. Accordingly this protocol coordinates the control flow and also ensures reliability.