Information Technology Reference
In-Depth Information
taken for granted that the transactional database can always be accessed by the ap-
plication. Even if they are structured so as to access locally cached data for “read”
operations, state changes (“updates”) must still applied to the shared, master data-
base
[12,25]
at the completion of each user operation. Obviously, the shared-database
assumption does not hold when business applications are disconnected: they are then
forced to read from, and write to, a database that is
not
shared by other applications
and users. Also, almost inevitably, the disconnected application will execute against
data that is out-of-date with respect to the server's version of the data. How can
work performed on the disconnected device be merged into the shared database in a
manner that preserves the transactional behavior of both disconnected and connected
clients? The lock-based concurrency control mechanisms used in connected environ-
ments to prevent concurrent updates and other transaction serializability violations
are not suitable for disconnectable applications because they unacceptably reduce
database availability. Also, lock-based concurrency control is simply not dynamic
enough; it is typically impossible to know what needs to be locked before the device
disconnects from the server.
Infrastructure must also be developed to deal with the life-cycle of an application
deployed to a disconnected device. Data must first be “checked out” (copied) from
the shared database; the data are then used by the application; and the committed
work must be merged into the server database when the device reconnects. Without
middleware that provides replication (from the server to the device) and synchro-
nization (from the device to the server) functions, each application must provide its
own implementation of these features. A programming model is therefore needed to
facilitate development of business applications for disconnected devices. The pro-
gramming model must provide constructs that address these algorithmic issues, and
must integrate with middleware that provides the services described above.
1 . 3
P r o g r a m m i n g M o d e l s f o r D i s c o n n e c t e d B u s i n e s s
A p p l i c a t i o n s
Comparing programming models is very difficult, because reasonable people can
disagree about (1) the correct set of evaluation criteria and (2) how well a given pro-
gramming model performs with respect to a set of evaluation criteria. Thus, even
in environments with which people have much experience, such as connected busi-
ness applications, discussing the superiority of EJBs versus CORBA versus DCOM
can produce much more heat than light. This difficulty is compounded for emerging
areas such as disconnected business applications. In addition, programming models
may have features that are interesting in their own right, independently of whether
applications execute in a connected or disconnected environment.
