Information Technology Reference
In-Depth Information
Stages
0
and
1
benefit from middleware that allows devices to define the subset of
relevant data that needs to be copied to the device. The subset is typically expressed
as a query or set of queries applied to the server database.
Stage
1
ensures that the device's database is as up-to-date as possible before be-
ginning disconnected execution. It greatly benefits from middleware that:
Subscribes
to relevant changes on the server (i.e., those changes which fall
within the defined subset of relevant data).
Propagates
server changes to the client device database, with the result that the
device's data is now up-to-date with respect to the server.
Standardized protocols such as SyncML
[40]
can be used to pass data between the de-
vice and the server—across wireless and wired networks and over multiple transport
protocols—using the standard representation format defined in the SyncML
Rep-
resentation
protocol. The SyncML Synchronization protocol efficiently replicates
server-side data to the device, by doing either a “one-way sync from server only” or
a “Refresh sync from server only.” In the former, the device gets all data modifica-
tions that have been committed on the server; in the latter, the server exports all of
its data to the device, which then replaces its current set of data.
Assuming that the correct set of data has been replicated to the device, stage
2
simply involves the execution of the disconnected application against the local data-
base.
For example, enabling the
order entry
application to run on a disconnected de-
vice requires, during stage
0
, that a system administrator replicate the stock catalog
consisting of items, in-stock quantities, agents, customers, and prior orders, if any.
Before disconnection, the device's database is brought up-to-date (stage
1
), so that
the recorded stock levels match the server's values. The agent is then able to take
new orders (stage
2
) while disconnected from the server database. We assume that
the agents prefer to work while out in the field, where connectivity may be unavail-
able or sporadic.
In order for work performed on the disconnected device to become visible to other
applications, the device must transactionally propagate its updates (or “change set”)
to the server-side database that maintains the master version of the data seen by other
applications and users (stage
3
). While propagating the change set from the client to
the server, stage
3
must deal with the following issues:
Conflict detection
, in which the application or middleware detects whether the
change set conflicts with the current state of the server-side database.
One important issue is how the notion of a “conflict” is defined. Connected
business applications typically define conflicts as non-serializable transaction
schedules
[15]
. Can this definition be used for disconnectable business applica-
tions as well? Efficiency is also a consideration: for example, does a detected
