20.4 The WAP-Enabled Transaction Model

The WAP-enabled transaction model is based on the multilayered approach capable of supporting preexisting global users on the wired network, in addition to mobile users. The proposed model is implemented as a software module on top of the preexisting multidatabase management system. In reality, a mobile transaction is no different from a global transaction as far as the MDBS layer is concerned. ^[12] However, a number of factors make it sufficiently different enough to consider it as a separate type in the MDAS:

Mobile accessing requires the support of fixed hosts for computations and communications.
Mobile accessing might have to split the processing, with one part executing on a mobile unit and the other part executing on a fixed host.
Mobile transactions might have to share state and data. This is a violation of the revered ACID (atomicity, consistency, isolation and durability) transactions-processing assumptions.
Mobile accessing tends to be long lived. This is a consequence of the frequent disconnection experienced by the mobile client and the mobility of the mobile client.

The MDAS, as we envision it, consists of a software module, called a mobile accessing manger (MAM), implemented above the MDBS layer. The two layers combine to form the MDAS. The MAM is responsible for managing the submission of mobile transaction to the MDBS layer and its execution. Thus, the MAM acts as a proxy for the mobile unit, thereby establishing a static presence for the mobile unit on the fixed network.

Our approach is based on the principle that the computation and communication demands of an algorithm should be satisfied within the static segment of the system to the extent possible. ^[13] In this chapter, we attempt to:

Localize the communication between the fixed host and a mobile host within the same cell
Reduce the number of wireless messages by downloading most of the communication and computation requirements to the fixed segment of the network so that the database access is faster

In the proposed WAP model, communication occurs through the exchange of messages between static and mobile hosts. In order to send a message from a mobile host to another host, either fixed or mobile, the message is first sent to the local MSS over the wireless network. The MSS forwards the message to the local MSS of the other mobile host, which forwards it over the wireless network to the other mobile host if it is meant for a mobile host; otherwise the message is directly forwarded to the fixed host. The location of a mobile host within the network is neither fixed nor universally known in the network. Thus, when sending a message to a mobile host the MSS that serves the mobile host must first be determined. Each MSS maintains a list of mobile hosts' IDs that are local to its cell. When a mobile host enters a new cell, it sends a join message to the new MSS. The join message includes the ID (usually the IP address) of the mobile host. To change location, the mobile host also must send a left message to the local MSS. The mobile host neither sends nor receives any further messages within the present cell once the left message has been sent. When the MSS receives the left message from the mobile host, it removes the mobile host ID from its list of local mobile hosts.

Disconnection is often predictable by a mobile host before it occurs. Therefore, in order to disconnect, the mobile host sends a disconnect message to the local MSS. The disconnect message is similar to the leave message; the only difference is that when a mobile host issues a leave message, it is bound to reconnect at some other MSS at a later time. A mobile host that has issued a disconnect message may or may not reconnect at any MSS later.

To initiate a mobile access to the database, the mobile host sends a start message to the MAM. The MAM acknowledges the request by returning a transaction number. Each MSS has a MAM associated with it, and the transaction numbers are assigned in a distributed manner among the MAMs in the system using any distributed ordering algorithm. ^[14] The mobile unit tags each accessing request with an ID, which is composed of the mobile host ID and the transaction number. The access request message is composed of the mobile host ID, the transaction number, and the transaction operations. To signify the completion of an accessing request, a stop message is triggered to the MAM, in order to guarantee that the entire transaction as a whole is submitted to the MDBS.

The WAP-enabled transaction model workflow is as follows:

The mobile unit initiates a transaction request. The message is received by the MSS, and is forwarded to the associated MAM.
The MAM receives the request from the MSS. This request is logged and the transaction ID (transaction number along with the mobile host ID) is placed in the ready list. A transaction proxy is created to execute the transaction.
Now the proxy removes a transaction ID from the ready list and inserts it into the active list. The proxy translates the transaction request and then submits the transaction to the MDBS for execution.
The request is executed at the MDBS layer, and the results and data are returned to the proxy.
The proxy places the transaction ID in the output list along with the results and data to be returned to the mobile host.
The MAM initiates a search for the location of the mobile host and the results are transferred to the mobile unit if it is still connected, and then the transaction ID is removed from the ready list.

In applying the proposed WAP model to the MDAS, we may derive the following benefits:

The proposed model decouples the effects of mobility from the MDAS. Hence, any developed concurrency control-and-recovery mechanism can be readily adopted into our model.
The MDAS layer does not need to be aware of the mobile nature of some nodes. The accessing speed increases because the mobile transactions are submitted to the MDBS interface by the transaction proxies. The MDBS interacts with the transaction proxy as though it were the mobile unit. In the case of a mobile transaction, most of the communication is within the fixed network and, as far as the MDBS is concerned, a static host has initiated the transaction.
The operations of nonmobile users are unaffected by the transactions of mobile users. The effects of long-lived transactions can be effectively and efficiently handled. Delegating the authority to commit or abort a transaction on behalf of the mobile host to the transaction proxy can minimize the effects of long-lived transactions. Thus, transactions initiated by non-mobile users will experience less conflict and, as a consequence, system throughput and response times are not severely affected.

In Section 20.5, we present this approach through a sample application to show how it can be put to work in the real world.

^[12]Segun, K. et al., A Transaction Processing Model for the Mobile Data Access System, LNCS 2127, pp. 112–127, 2001.

^[13]Badrinath, B.R. et al., Structured distibuted algorithms for mobile hosts, Conf. Distributed Computing Syst., pp. 21–38, 1994.

^[14]Badrinath, B.R. et al., Structured distibuted algorithms for mobile hosts, Conf. Distributed Computing Syst., pp. 21–38, 1994.