MODBC - A Middleware for Accessing Databases from Mobile Computers

Michael Beigl, University of Karlsruhe


0) Abstract

Mobility is a new challenge for many existing applications. This paper
addresses the problems when using existing applications on mobile
devices. It presents a mobility service architecture and gives a look at
one of our exemplarily implemented and tested systems building onto this
architecture. One of these systems, the MODBC service, is introduced in
this paper; the MODBC service enables mobile devices to access
relational databases with existing and widely used applications.

1) Introduction

Today mobile devices have grown up: Hardware like long-life batteries
and low-power chips are as long available as pre-versions of basic
mobility software like MobileIP. Although this software components are
in beta phase, they provide a good basis for new applications using the
advanced possibilities of mobile devices. Actually only a few of these
applications are available, and only a few of the innumerably existing
applications fit the requirements needed for mobile devices. Regarding
to existing applications, the main problems for applications running on
mobile devices at laptop size are [1]:

- frequently changing and slow connection lines for transferring data

- expensive connection lines, like wireless GSM (Groupe Speciale
Mobile[2]) or Modacom (MObile DAta COMmunication [3])

- erroneous connection lines

- longer times of disconnection

- devices with weak computing power and small amount of memory

2) Mobility Service Architecture

We address these problems mentioned above when building a service
architecture for mobile computing scenarios. To verify the usefulness of
the components and the underlying assumptions of our architecture we
implement a system exemplary.

Our first decision was to enhance existing applications and not to build
complete new ones. This decision is based on the following pragmatic
assertions:

- most users want to use applications they are used to from their
desktops on their mobile device

- existing applications will be adopted to the needs of mobile computing
very slow

- most of the parts of an application need not be adopted to fulfill the
needs of mobile computing if underlying layers are adopted

The above mentioned problems could be solved by using enhancements at
OSI layer 3 like MobileIP. But for our application scenarios an adoption
of services at network layer was not sufficient enough. E.g. semantic
information is needed for efficient transmission of data, which is not
available at this layer. Because of the high cost of data transmission
an inefficient transmission of data is not tolerable in mobile
computing.

2.1) Mobility Services

The above conditions are best fulfilled when adopting middleware for
mobile needs [4]. We do this by replacing existing services (or better:
service drivers) with enhanced ones. This mobility services are offering
the same APIs to the application side as the original services. Only the
functionality to the lower layers is enhanced and the services could use
upgraded implementations in network protocols like MobileIP. An
additional advantage of this implementation is, that mobile services
shield the applications from changes at these lower layer protocols.
These functionality's are collected in our architecture model under the
term Special Mobility Services (SMS).

Additional to these functions there are mobility enabling functions that
belong to all middleware services. Mobility enabling functions could be
used by the SMS modules or by special mobility enhanced applications. We
group these functions under the term Common Mobility Services (CMS). An
example for such a service is the connection management services. The
connection manager protects the user from unexpected line disruption and
looks for available lines, choosing the optimal (in the sense of the
user) one for transmission.

The third class of functions belongs to services that need an
interaction with the user, e.g. to configure behaviour for different
classes of mobility scenarios. New applications could configure these
parameters directly. We call these services Management Mobility Services
(MMS).

A sketch of the architecture could be drawn as follows: Think of SMS,
CMS and MMS as building blocks, where upon the SMS and CMS Services the
applications are layered, and under SMS, CMS and MMS the
operating-system building block with the network and transport protocol
is settled. The advantage of grouping the services in classes is the
possibility to reuse the developed CMS and MMS components for other
mobility services.

2.2) Basic Tasks of the Middleware

The basic tasks of middleware are derived from the basic requirements of
mobile computing [5]. These requirements are stability, awareness of
changing bandwidth and costs, integration into familiar environment,
security, extendibility and scalability. From these requirements we can
derive several tasks for a mobile system:

- Connection management: checking for the availability of lines,
automatically selecting the best suited one

- line parameter management: comparing the cost of data transmission
with given requirements and providing a set of alternative strategies

- caching and replication: copying data onto the mobile device,
providing strategies for inconsistencies and enabling disconnected work

- authentication and encryption

- accounting: negotiating the costs of the usage of resources in foreign
domains

- profiling: adapting the system onto the needs and habits of the user

- scaleable service e.g. for video/audio/graphics

To fulfill these requirements we need some services from the underlying
layers as:

- Localisation management

- Quality of Service parameters

2.3) Scenario

The scenario consists of a minimum of 3 stations where the data are
processed [1]. The first one is the original server, where the data are
coming from. This server is called backend in our term. The second one
is the mobile enabling server, called relay, which converts data before
sending to the client. The relay also offers additional features for
mobile clients. Clients are called frontend in our scenario. Both the
backend and the relay could, but need not be executed at the same
machine. At the way to the frontend there could be other relays
processing the data. As [6] shows, it was profitable to have one at each
access point to the (wireless) network that the client uses. This
strategy decouples the wireless and wired lines and could therefore
speed up the communication, avoiding retransmission of lost or damaged
packets over the whole distance from the backend to the frontend.
Because wireless lines are very erroneous it is an improvement to resend
the packets only over the wireless line in an error case. If
additionally installing the backend and relay part at the same machine,
we could take advantage of the minimised protocol and the on-line
compression we implemented in our CMS: Most service protocols are not
optimised to minimise data to transmit but to minimise the effort of
writing such middleware drivers. To overcome the inefficiency of sending
too much data we do not encapsulate the packets from the middleware
driver, but translate them before sending over wireless lines to reduce
the amount of data to send.

3) Mobile Open Database Connectivity

ODBC [7] defines a standardised method for accessing databases and is
based on a client/server model. ODBC is proposed to be a X/Open standard
[8] to which almost all database vendors and database front-end vendors
do commit. Also many popular applications could access databases through
ODBC, among them spreadsheets like EXCEL or wordprocessors like
Wordperfect. ODBC defines an Application Programming Interface (API).
With the ODBC API an ODBC driver could be accessed from an application.
This driver transmits the data it got from the application with the help
of a proprietary network protocol, which is specific for a database
vendor to the database server and vice versa.

This ODBC service driver should be enhanced to fit the needs of mobile
computing; we call this driver Mobile ODBC (MODBC). In the following,
special realisation issues are explained to clarify the functionality
and implementation issues of MODBC.

3.1) Realising Reliability and Connection Management

As mentioned above, the connection manager protects from unexpected line
disruption by watching the actual connection to be available. After a
line disruption the manager tries to reconnect according to the
connection list. In this list the available connections are sorted at
the users need, e.g. according to the transmission costs or according to
speed. The reconnection is done transparently to the application and the
user. Also disruptions during data transmission are handled without loss
of data or crashing the system. Existing applications make many
assertions to parameters of the underlying services, e.g. according to
response-time. As a result, preventing the application (or the whole
system) from crashing was very difficult to realise. This points to one
of the major problems when building mobile applications using existing
components: Today's applications make assumptions that are not
appropriate in a mobile computing environment.

3.2) Realising Cache

Caching is a central feature for weak connected devices. As shown above,
a general underlying caching mechanism at the transport layer isn't as
effective as a middleware caching mechanism. A middleware level driver
is aware of some of the structure of the data. This information could be
used for efficient implementing a caching mechanism well adopted to the
needs in mobile computing scenarios. We could avoid retransmission of
previously transmitted data even if the data packets are different. E.g.
a network level cache does not know that two transmitted packets contain
the same data and only the sequence number has increased. As shown in
[9][10], caching mechanisms for database applications could be very
complex: In a database system the place intended to store data is the
database server itself. Thus implementing a appropriate caching
mechanism for mobile devices isn't as simple as in other cases like
writing a disk cache. Care should be taken choosing the convenient
mechanism for use in a mobile system.

After testing with different caching mechanisms we choose a relative
simple caching method, that takes benefit from the ODBC capabilities the
system has access to. This realisation is adopted to the computing power
restrictions of mobile computers. Basis of the system is an identifier,
that will be computed for all data that are cache candidates, on the
basis of their binary representation. The unit of a cache are single
data fields. As the method how to compute the identifier we choose the
CRC Method with conflict resolution through the server.  With this
method we minimise the load on the client and lay some of the effort to
the server. The cache is designed as a read-only cache where write
requests are passed through to the database server.

3.3) Realising Replication

As above for the caching mechanism, we choose a very simple method for
replication. To begin the replication, pre-defined tables or parts of
tables are copied to the client. The selection of the tables could be
done by the user (manual mode) or by MODBC through automatically copying
the tables previously accessed by the user at disconnection time. These
data could optionally be blocked on the server. At this time the
original state of the checked out data is stored. When disconnected, the
user works with the replicated data as with remote data previously. The
order of the data is the same as on the server: we use the same keys the
database server uses. When checking in, we compare the actual client
state, the actual server state and the original state. When determining
a conflict, we rely on the user for resolving the conflict.

3.4) Realising Compression

Actually we concentrate our work on lossy compression of pictures
according to the users predefined needs. The user profile contains the
wanted minimum quality level for pictures or the maximum transfer time.
The transfer time was estimated from the previous transferred data or we
get the Quality of Service parameter from the underlying layers.
Actually we compress only pictures in Jpeg format. A lossless
compression of other elements e.g. text seems not to be useful in our
scenarios: Most dial-up networks use PPP with integrated Lempel-Ziv
compression and many wireless cards contain hardware compression chips
based on similar operations. This compression ratio could not be
improved when using devices with low computing power and is therefore
sufficient for our purpose.

3.5) Measurements and experience

Mobile ODBC shows a way how to enhance an existing class of applications
for mobile computing needs through a simple exchange of a middleware
driver. We have implemented a MODBC driver that covers some important,
but not all ODBC API's. As a result some applications, like MS-Access or
Execl, which use only a subset of the ODBC API's run with our system;
other ODBC enabled applications may or may not run with MODBC depending
on the ODBC API calls they need. We have ascertained through
measurements with Mobile ODBC saving expensive and rare resources like
amount of transmitted data up to a factor of 1:10 and transmission time
in switched networks like GSM up to a factor of 1:2 compared to the
original service driver is possible. We could also show that recovery
from line disruption could be handled without notifying the user or
application on the basis of predefined user preferences. It is typical
for mobile work, that data will rather be read than written or changed
by the user. Thus a conflict resolution for replicated data is seldom
needed in our experience.

4) Conclusion

With the proposed architecture we have shown a way to adopt existing
applications to the needs in mobile computing. We do this adoption by
enhancing middleware the application uses. The usability of our
architecture could be shown by a first implementation, the Mobile ODBC.

Additionally to MODBC we have developed a Mobile WWW driver, that covers
a similaar functionality as MODBC; the architectural design allows us to
reuse the MMS and CMS components. Because of ODBCs complexity we will
discontinue development on MODBC and focus our work to the less complex
Mobile WWW. Our actual work focuses adaptive lossy compression methods
and integration of PDAs in existing and new application environments.

[1] R. Rudisch, M. Beigl, System support for mobile computing, 
    Comput.& Graphics, Vol. 20, No. 5, 1996
[2] A. Mann, Der GSM-Standard. Grundlage fuer europaeische Mobilfunknetze,
    Informatik Spektrum 14, 1991
[3] T. Kautz, B. Mielke, Alles ueber MODACOM. Franzis Verlag, 1993
[4] J. Jonson, Middleware makes wirless WAN Magic. Data Communications 3, 1995
[5] A.Schill, B.Bellmann, et al., System support for mobile distributed 
    computing applications. In IEEE SDNA Workshop, Vancouver, 1995
[6] A.Bakre, B.Badrinath, I_TCP: indirect TCP for mobile hosts. Technical
    Report DCS-TR-314, Rutgers University, 1994
[7] Open Database Connectivity Software Development Kit Programmers Reference,
    Microsoft, 1994
[8] SQL Call Level Interface, X/Open,  Document No C451
[9] Klaus Elhard, Das Datenbank-Cache: Entwurfsprinzipien, Algorithmen, 
    Eigenschaften, Technische Universitaet Muenchen, Dissertation, 1982
[10]A.Kemper, M.Wallrath, M.Duerr, K.Kuespert, V.Linnemann, An Object Cache
    Interface for complex Object engineering Databases, Technical Report,
    IBM Germany Heidelberg, 1989