INTENTION-ACTION PROTOCOL | Mobile Commerce Applications

INTENTION -ACTION PROTOCOL

We now describe the intention-action protocol, in which there are several clients C and servers S. The C and S have a contract that each will request or respond to queries concerning flight reservations . The protocol is the following: Each C can request for a reservation to any S for seats, providing a deadline to respond; then C enters into a doubtful state. Each S then examines its flight vacancy and responds positively or negatively to C, providing a deadline to confirm, and enters into a doubtful state. The doubtful state for C is resolved when S positively or negatively responds within C deadline, or C deadline expires . If there is a positive response, C needs to confirm or cancel within the S deadline.

The S, on the other hand, is in a doubtful state until C confirms or cancels within S deadline, or S deadline expires.

The IA protocol (Figure 1) for extran takes place between CC(i) (Coordinator of C(i)) and SC(p) ( coordinator of S(p)). As before, we use the indices i and j for C and indices p and q for S. We assume that S(p) and S(q) are independent and do not interfere with each other. We also assume that request message and intent message contain deadlines (and provide for time-tolerant transactions). Also we assume that the clocks in S and C are initially synchronized, use the same time, or are provided with a computable time relationship. This protocol is forward recoverable; that is, the logs are written so as to recover global state and local state when failures arise. Also, if failures are short-lived and are repairable within a reasonably short time (in comparison to the deadlines), the communication and system failures can be tolerated.

Figure 1: Intention-action protocol

   Behaviour of CC(i):   SEND Request to all SC(p) with C(i) time stamp and C(i) deadline; WRITE start IA protocol record in log; WAIT for response from S(p) (*Enter doubtful state*); after time-out or reconnect after disconnection initiate restart; IF messages are received from any S(p) within C(i) deadline   BEGIN    IF S(p,i) deadline not expired then       SEND the SC messages to C-task;       WRITE decision record of C in log;       EXECUTE the C-transaction;       SEND decision message to S(p)    ELSE WRITE "S(p,i) deadline expired" in log;    END; ELSE (no response within C(i) deadline) WRITE "no S(p) response" in log; RETURN   Behaviour of SC(p):   WAIT for Request message from CC(i); on receiving Request message, assign S(p) time stamp T(i), activate the S(p) task by SEND Request message to it in S(p) time stamp order; WRITE intent record, C(i) deadline, and S(p,i) deadline in log; IF intent is positive then        BEGIN      IF C(i) deadline has not expired;         EXECUTE the intention transaction;         IF the intention transaction is committed then                BEGIN                SEND intent message (Positive) containing S(p,i) time stamp and                S(p,i) deadline to CC(i)                WAIT for decision message from CC(i) (*Enter doubtful state*);                on time-out initiate S-termination protocol;                  IF S(p,i) deadline not expired                     WRITE decision record in log;                     SEND the decision message of C(i) to S(p)-task;                     EXECUTE an Action transaction as per the decision (reserve or cancel) of C(i) and                          WRITE "Reserved or cancelled for C(i)" as the case may be in log;                  ELSE CANCEL reservation of C(i) and WRITE "S(p,i) deadline expired" in log;                  END;         ELSE activate S(p) task and pass ABORT message to it; send negative response to C(i) and                   WRITE "intent aborted" in log;    ELSE WRITE "C(i) deadline expired" in log;    END; ELSE    IF C(i) deadline has not expired, send negative intent    to CC(i)    ELSE WRITE "C(i) deadline expired" in log; RETURN

Doubtful States and Termination

The C(i) is in a doubtful state from the time it has sent its request message to S(p) until it receives the intent message from any or all S(p).Thus it terminates from this state when any response is received and decision is made. However, if no response is received from any S(p) within time-out or disconnection but C(i) deadline has not expired, C(i) needs to send a reminder to S(p) to avoid the possibility of nondelivery of request message due to networkfailure.

The S(p) is in a doubtful state from the time it has passed on a positive intent message to C(i) until it receives a decision from C(i) (see Figure 1(b)). In case there is no response from C(i) but it had a time-out or got disconnected, S(p) needs to recheck the C-deadline in S(p) log. If C(i) deadline has not expired then S(p) must continue consulting CC(i) to find the decision by sending a reminder to C(i) to avoid the possibility of nondelivery of positive intent message due to network failure or disconnection.

  CC(i) restart after time-out or reconnect (Figure 1c):  RESTART      SEND intent reminder to S(p) if C(i) deadline not expired;      WAIT for intent message from C(p);      on time-out or disconnect go to RESTART;      on receiving intent message from C(p)      RETURN  SC(p) termination from doubtful state after time-out (Figure 1b):  Start SEND decision reminder to CC(i) if C(i) deadline has not expired;      WAIT for decision message from CC(i);      on time-out go to start;      on receiving message from C(i)      RETURN

Discussion

In order to prioritize events in C and S we use time stamps. This means we need to use a time synchronization every time a C gets reconnected after a disconnection. This is done by an exchange and synchronization of the C with S by asking the time.
The commitment of an intention transaction implies that integrity constraints are satisfied at this point of time and the doubtful state is made visible to other transactions. The commitment of an intention transaction is necessary for the action transaction to commit, if the decision message is positive; otherwise , the transaction is cancelled by the action transaction. Hence the action transaction cannot be aborted, as it would lead to inconsistency. Also note that the undoing of an intention transaction will not violate integrity constraints. Hence there is a provision for aborting an intention transaction, even if the intention is positive, to ensure that a final check is made before sending messages to C(i).
The time-out and disconnection periods are taken into account to preserve battery power and user comfort . Appropriate reminders are built in on either side to successfully complete a transaction.
There could be tolerance limits built in on deadlines if the host can still accommodate such requests without violating the consistency and integrity of the database.
It is also necessary to provide a waiting list to solve the issues of last-minute cancellations and allocate seats to waiting requests (to avoid ending up with vacancies).

Intention-Action Protocol and Intention-Action Locking

It is interesting to note that the intention-action protocol is a messagepassing version of the intention-action lock used for multigranularity locking in a shared-memory database (Krishnamurthy & Murthy, 1992). The advantage of the IA protocol for mobile business arises from the fact that it not only provides a platform for developing and testing loosely connected transactions but also permits a cooperating execution environment where multiple transactions in a workflow can be scheduled to achieve an overall business objective. (Again recall the analogy of this protocol with the intention-action right-left turn signals used while driving cars on roads ). The sharp contrast between the conventional multidatabase transactions and the mobile transactions is now obvious. In the former case, we are dealing with several permanent databases, while in the latter case of mobile transactions, constraints arise due to the messages coming to and from the participating businesses with a dynamically changing database controlled by messages. Further, data dependencies arise nondeterministically due to the interdependence of tasks within the workflow.

Hotel Reservation

Consider the above protocol for the hotel reservation problem. The hotel database has a set of rooms and each room has a status available or unavailable on specified dates. The object Alloc stores the confirmed allocation of rooms to named guests, and Int- Alloc holds the intentional reservations intention-committed. We assume that each guest has a unique ID and is not permitted to hold multiple reservations in the same hotel.

The hotel database has two integrity constraints:

The number of confirmed + intentional reservations does not exceed the number of rooms on any date.
The set of rooms that are unavailable on any date are those already allocated to the guests in Alloc plus those in Int-Alloc on those dates.

The following transactions act on the hotel database:

Reservation request from guest within a deadline (extran).
Reservation availability from hotel and intention commit (intran).
Send negative intent or (positive intent + deadline) to guest to confirm (extran).
Reservation acceptance or cancellation by the guest (extran).
After cancellation by the guest or S-deadline, the intent reservations are cancelled, rooms are made available, and the Int-Alloc is suitably modified and committed (intran).
After the confirmation by the guest within S-deadline, the Int-Alloc rooms are transferred to Alloc and committed (intran).

Note that transactions 2, 5, and 6 are intrans with ACID properties while 1, 3, and 4 are extrans using IA protocol.

E-Checking

We will briefly describe the application of the above protocol for the e-checking problem. The electronic check, or e-check, was introduced by Financial Services Technology Consortium (FSTC, http://www.fstc.org). This system has functions such as: deposit and clear, cash and transfer. It has entities: payee, payer, payer bank, payee bank, and clearinghouse. E-check can be an effective system over integrated networks. E-check can be used for high value transactions, B2B payments, etc. At every stage of this system the intention-action protocol and time-tolerant and time-critical transactions arise (Chen & Dayal, 2000; Sendall & Strohmeier, 2002; Wang & Das, 2001). Using intention-action protocol, log, and time stamps, we can incorporate fairness, non- repudiation , and timeliness of financial transactions.

When a check is presented the bank verifies the details and signature, validates the check and security codes, and accepts or rejects a check within a time limit. Hence, the time stamp also plays an important role in clearing and depositing checks in time order of issue whenever there is not an adequate balance in the account, in order to resolve the conflicts and appropriately inform the payee and payer. Also using logs, non-repudiation can be achieved so that the participants cannot deny a particular intention, event, or action.