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.
Sections
