Document Sample
					IEEE ICDE ‘98 Tutorial:
Mobile Computing and Databases

          Margaret H. Dunham
     Southern Methodist University
    Dept of Computer Science and
          Dallas, Texas 75275

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing
Projects & Products

2/24/98           ICDE/SMU - Dunham      2
Mobile Computing Architecture

2/24/98      ICDE/SMU - Dunham   3

Fixed Network (FN)
Base Station (BS) (Mobile Support Station -
Fixed Hosts (FH)
Cell - Area covered by BS (1-2 miles)
Handoff - Changing BS by intercell move
Mobile Host (MH) (Mobile Unit (MU))

2/24/98            ICDE/SMU - Dunham           4
Wireless Networks

      High Cost
      Scalability Issue
      Limited Bandwidth: 10 Kbps
Wireless LAN
      Traditional LANs with wireless interface
      Low Cost
      Limited range: 10-100 meters
      Bandwidth: 10Mbps
      NCR Wavelan,ICDE/SMU - Dunham
2/24/98                Motorola ALTAIR            5
Wireless Networks (cont’d)

Satellite Services
 Wide Coverage
 Very Expensive
 Low Bandwidth: 1-2Mbps
Paging Networks
 Wide Coverage
 Sky Tel, Motorola
Slow: (Ethernet: 10Mbps; FDDI or switched
    Ethernet: 100Mbps; ATM: 155Mbps)
2/24/98            ICDE/SMU - Dunham         6

Changing BS due to
 movement between cells
State information
Current handoffs in
 cellular phones may
 take up to a few seconds with
 breaks in conversation of 100-300 ms.
Soft - Temporarily connected to two BSs
Hard - Only connected to one BS
2/24/98            ICDE/SMU - Dunham       7
Location Management

Tracking mobile user
User associated with home
 location server (Home Agent)
                        A      h

May augment by searching in local
                        A      f

 area first             S

May augment with user profiles

Mobile IP [11,14]                         Ah           Af

   Triangle Routing
   Route Optimization                              M

   Location Control (Routing Agent)
 2/24/98               ICDE/SMU - Dunham                     8
Location Management (cont’d)

Active Badge (Cambridge,[2])
    Track employees and route telephone calls
    Unique code emitted every 15 seconds
    Sensors placed in offices and corridors
Location Information Replications
    No HLR
    Hierarchy of Location Servers
    Each server maintains information about its subtree

2/24/98                ICDE/SMU - Dunham                   9
Mobile Applications

  Information Services (Yellow Pages)
  Law Enforcement and Medical Emergencies
  Sales and Mobile Offices
  Weather, Traffic, Sports, Entertainment
  Cellular Subscribers in the United States:
    90,000 in 1984;4.4 million in 1990;
      13 million in 1994
    Handheld computer market will grow to $1.77
      billion by 2002
2/24/98            ICDE/SMU - Dunham          10
Technology Push

Internet: ftp, telnet, email, http,html
Advancing Wireless Communication
Laptop, Notebook, and Palmtop Computers

2/24/98          ICDE/SMU - Dunham         11
Classification of Mobile Database

2/24/98       ICDE/SMU - Dunham     12
Data Management Issues

 Speed of wireless link
 Location dependent data; Location specific
 Limited by battery power
 Disconnection (Voluntary, Involuntary)
2/24/98            ICDE/SMU - Dunham           13
Insurance Example

2/24/98     ICDE/SMU - Dunham   14
Medical Example

911 Call
Ambulance arrives/departs
Closest hospital
Access patient records
Send vital signs
Update patient records
Page hospital personnel
Order medical supplies

2/24/98           ICDE/SMU - Dunham   15
MC/DB Research

Transaction Processing
Caching - Replication
Broadcast Disks
Location Dependent Data
ACID (?)

2/24/98          ICDE/SMU - Dunham   16
Introduction & Data Management Issues
Query Processing
  Location Dependent Queries and Data
  New Query Types
  Query Optimization
Data Broadcasting
Transaction Processing
Projects & Products
2/24/98           ICDE/SMU - Dunham      17
Location Dependent Data

Value of data depends on location
Temporal Replication - One consistent value at
 one time
Spatial Replication - Multiple different correct
 data values at one time
Temporal Consistency - All data objects satisfy
 a given set of integrity constraints.
Spatial Consistency - Consistency constraints
 satisfied within Data Region.
SMU/University of Missouri at Kansas City, [17]
2/24/98             ICDE/SMU - Dunham               18
Location Dependent Queries

Result depends on location
Different from traditional distributed goal of
 location independence
Ex: Yellow Pages, Directions, Map
Predicates based on location: “Find the
 cheapest hotel in Dallas.”
Location constraints: “Find the nearest hotel (to

2/24/98             ICDE/SMU - Dunham            19
Similarity to Spatial Queries

Spatial Data: Data associated with space
 occupied by object.
Types of spatial queries: contains, contained in,
 intersects, neighboring, east of, etc.
Spatial data structures
Spatial operators
Spatial selects and joins
PSQL - extend SQL, [18,20]

2/24/98            ICDE/SMU - Dunham             20
Differences from Spatial Queries

Client is actually moving
Location of client may be    Spatial data is dynamic
 part of the query itself
May depend on direction of movement
Data may not directly contain location
Includes temporal features as well

2/24/98            ICDE/SMU - Dunham            21
Querying Moving Objects

Moving Objects Spatio-Temporal (MOST) data
     Dynamic Attributes - Change over time
     Queries over temporal history:
          Instantaneous - Ex: “Find all restaurants I’ll reach in the
           next half hour. ”
          Continuous - Ex: “Find all restaurants within 5 miles.” The
           answer continuously changes as the MU moves.
          Persistent - Ex: “Find the cars that travel greater than 10
           miles in the next half hour.”
Future Temporal Logic (FTL) language
University of Illinois, [20]
2/24/98                      ICDE/SMU - Dunham                           22
Query Optimization

How best to satisfy the information request
 made by the client?
Different Cost Factors: I/O, network
Different Access Options: cache, FN, broadcast
Dynamic and Adaptable - environment changes
Alternative plans include deciding (based on
 state of MH and environment) whether to
 access in the cache at the MH, to request a
 mobile transaction, or to obtain from a broadcast
2/24/98            ICDE/SMU - Dunham            23

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing
Projects & Products
2/24/98           ICDE/SMU - Dunham      24

  Placing data at MU. Usually on disk.
  Faster to access from MU than from DBMS in
   fixed network.
  Facilitates disconnected operation.
  Adaptive to connection mode.
  Not just another replica
  Pull based
  Most work on files not databases

2/24/98            ICDE/SMU - Dunham            25
Caching Functions

Data fetching
     Granularity (Page, file, table, semantic)
     Callback - Servers send invalidation messages to
     Detection - Clients send queries to servers to.
Updating during disconnect
Data integration when reconnected
2/24/98                  ICDE/SMU - Dunham               26
Connectivity and File Systems

               Table 3.2 from [15]

2/24/98       ICDE/SMU - Dunham      27
MU Replica Control Protocols

Traditional Replication Protocol problems:
     May hinder mobility
     Quorum Consensus: Can’t get quorum if
      disconnected; Avoid using MU replicas to make up
Location information not always readily available
Primary Copy: Should not be stored at MU
First class/Second class replicas

2/24/98                ICDE/SMU - Dunham                 28

                 Table 3.4 from [15]

2/24/98         ICDE/SMU - Dunham      29
Prefetching vs.. Hoarding

 Both prefetch data in anticipation of future use.
      Objective is to improve performance (throughput or
       response time).
      Cache miss not catastrophic.
      Objective is to fetch all needed data into MU cache
       prior to disconnect. Thus the goal is to facilitate
       disconnected operation.
      Cache miss is catastrophic.
      OK to overfetch
2/24/98                  ICDE/SMU - Dunham                   30

Listening to and recording file accesses
Performed during a snapshot interval
May be combined with user profiles.
Results limited to the snapshot.

2/24/98            ICDE/SMU - Dunham        31
Disconnected Issues

                                 Table 3.1 from [15]

2/24/98      ICDE/SMU - Dunham              32

First project to demonstrate disconnected
Optimistic Locking
Granularity - sets of files.
Coherency - callbacks
Hoard Walking: Periodically (every 10 min)
 evaluate contents of cache. Recalculate priorities.
On a callback break, object is purged, refetching
 on demand or during next hoard walk.
Venus - cache manager at MU
2/24/98             ICDE/SMU - Dunham            33
Coda (cont’d)

Venus states:
 hoarding,emulating,write               Hoarding

 disconnected (earlier
Cache misses during
 disconnection are treated as                                       Disconnected

During disconnection, a log
 (Change Modify Log) of                Emulating

 operations is created.
                                       Adapted from Fig 2 in [34]
2/24/98            ICDE/SMU - Dunham                                   34
Coda (cont’d)
During integration, log applied. Conflicting updates
    are determined and user assists in resolution
Timestamps at volume and object level used to
    determine conflicts.
Trickle Reintegration used to asynchronously
    propagate updates.
Hoard Profile - list of files and priorities.
Lowest priority objects chosen for replacement.
Weak Connectivity - low bandwidth, high latency,
    high cost, or intermittent
CMU, [29,34]
2/24/98                ICDE/SMU - Dunham          35
Little Work

Disconnected AFS
Cache operations depends on type of
     Connected - Continuous; High bandwidth; Normal
     Partially Connected - Continuous; Dialup; Delayed
     Fetch Only - On demand; Cellular; Optimistic
Disconnected - Fail if cache miss
2/24/98                 ICDE/SMU - Dunham                 36
Little Work (cont’d)

Caches 64KB chunks of files
Fetch only mode
Modifications sent back to primary file server
Conflicts stored separately and user notified
Michigan, [25,26]

2/24/98             ICDE/SMU - Dunham             37
Uses semantic information to determine
 contents of cache.
Semantic distance between files measured in
 number of file accesses on average between
 two files.
Access is defined as open-close.
Distance measure used to cluster files.
 Fetching of a cluster based on user hints and
 LRU information.
UCLA, [24,30]
2/24/98            ICDE/SMU - Dunham             38

          Table 3.1 from [15]

2/24/98   ICDE/SMU - Dunham     39
Sleepers and Workaholics
Cache invalidation report
Periodically (synchronous) the server
   broadcasts report of changed data.
MU waits for next report prior to answering
Sleepers - frequently disconnected; cache
   invalidation based on signatures.
Workaholics - rarely disconnected; periodic
   broadcast of changes.
False Invalidation
MITL and Rutgers,ICDE/SMU - Dunham
2/24/98               [21]                     40
Transparent Analytic Spying

 File Working Sets
 Continually observe and                            A

  record (in a log) file access.
  At hoard time, reference the             B                 C

  log to determine hoard.
 Trees for a process are              D        E             F
  created reflecting file access
  pattern. One tree per program                Access Tree

  execution is generated.

2/24/98            ICDE/SMU - Dunham                         41
Transparent Analytic Spying (cont’d)
Hoard all files or only those in in the most recent
Tracing adds about 2% CPU overhead.
 Average space for file log record is 100 bytes.
Implemented on Unix, NFS, Mach
Cache miss rate over wireless slightly higher
 than on wired.
Prefetching overall reduced cache misses and
 elapsed time
Columbia, [36]
2/24/98              ICDE/SMU - Dunham             42
  Predictive File Caching

Analyze file access patterns in different environments:
 Personal productivity, Programming, Commercial
Working Set Statistics: Mean working-set sizes small
 (18MB per day)
Attention Shift Statistics: 0.6 per user per week
Conflict Statistics: Depends on environment
  Hoarding is possible due to small working set size
  LRU caching insufficient
UCLA, [31]
  2/24/98               ICDE/SMU - Dunham               43
Virtual Primary Copy

Mobile Primary Copy (MPC) at MU
Virtual Primary Copy (VPC) at BS
Global transactions access VPC
Consistency of VPC maintained by BS
BS monitors MU disconnect
Multilayered approach is transparent to other
Monash, [23]

2/24/98            ICDE/SMU - Dunham             44

MC Replication System
MU Peer to Peer
 communication allowed
Ward Model:
     Ward: Grouping of replicas for
        locations that frequently
     Ward Set: Set of replicated data
        stored in a ward.
     Ward Master: Doorway into
        ward. Maintains consistency
2/24/98 between wards.      ICDE/SMU - Dunham   45
Roam (cont’d)

Ward members are “close”
No “pre-motion” operations
Intra-ward synchronization easier than inter-
Reconciliation- Synchronization process
Selective replication at file level
Scales well
UCLA, [33]

2/24/98             ICDE/SMU - Dunham            46
Semantic Cache

 Caching granularity at a predicate level
 SPJ query - Materialized view
 Advantages: reduces network overhead,
   reduces cache space
 Disadvantages: Indexing, query trimming
 Semantic Cache - C = {Si}
 Semantic Segment - Si=<Sr,Sa,Sp,Sc>
2/24/98          ICDE/SMU - Dunham           47

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing
Projects & Products
2/24/98           ICDE/SMU - Dunham      48
  Data Broadcasting
Server continually broadcasts data to MUs.
Scalability: Cost does not depend on number of
 users listening.
Mobile Unit may/may not have cache.
Facilitates data access during disconnected periods.
Allows location dependent data access.
No need to predict with 100% accuracy the future
 data needs.
Broadcast based on probability of access.
Periodic broadcasting of all data.
  2/24/98             ICDE/SMU - Dunham           49
Data Broadcasting (cont’d)
    Coverage - Everything, Subset
    Content - Static, Dynamic
    Indices - Index, Self Descriptive
    Data Stream - Flat, Skewed, Multiple Disks
    Client - Passive, Active
For uniform page access, flat disk has best
 expected performance.
With skewed page access, nonflat disks are
Push based.
2/24/98                ICDE/SMU - Dunham          50
Broadcast Disks

Simulate multiple
 disks of varying
  sizes and speeds.
 Data of higher
 interest on smaller
 faster disks
                                   Figure 4.1 from [15]
 (broadcast more frequently).
Each “disk” contains data with similar access
Combination of caching and broadcast disks.
2/24/98                ICDE/SMU - Dunham                  51
Broadcast Disks (cont’d)

Don’t want to store hottest pages. They may be
 broadcast frequently.
Store in cache if probability of access (P) is
 greater than the frequency of broadcast (X).
Cost based page replacement.
Replace cache page with smallest P/X - PIX.
 Too expensive to implement.
LIX - PIX approximation. Works well particularly
 with noise.
Brown, MITL, Maryland, [37,38,39]
2/24/98            ICDE/SMU - Dunham            52

Dynamic - Adapts to system workload.
Define temperature of data:
 Vapor (Steamy) Hot - Accessed frequently
   and broadcast.
 Liquid Warm - Accessed often, not
   broadcast, but kept in server’s main memory.
 Frigid (Icy) Cold - Accessed infrequently and
   stored on secondary storage.

2/24/98            ICDE/SMU - Dunham          53
Air-Cache (cont’d)

Three level memory hierarchy based on
Sparks (access) to data can increase
 temperature. No sparks, results in a reduction
 of temperature.
Simulation results predict very good
Maryland, [43]

2/24/98            ICDE/SMU - Dunham              54
Adaptive Protocols

Dynamically modify broadcast contents.
Constant Broadcast Size (CBS) Server Protocol:
     Limited size and periodic
     Popularity Factor (PF)
     Ignore Factore (IF)
Variable Broadcst Size (VBS) Server Protocol:
     All data above threshold PF included.
Arizona and UMKC, [40]
2/24/98                 ICDE/SMU - Dunham        55
  Introduction & Data Management Issues
  Query Processing
  Caching
 Data Broadcasting
     Transaction Processing
     Transaction Model
  Agents
  Projects & Products
  Conclusion
2/24/98                       ICDE/SMU - Dunham   56
Mobile Transaction (MT)

 Database transaction requested from a MU.
  May execute in FN or MU
          Location Dependent Data
          Error Prone
          MU Resources/ Power
2/24/98                ICDE/SMU - Dunham      57
MT Requirements
Keep autonomy of local DBMS
Advanced transaction models
Request from MU
Execute anywhere
Capture movement
ACID (?)
2/24/98              ICDE/SMU - Dunham   58
MT Approaches

No consensus on accepted approach
MU may not have primary copy of data [45]:
     Transaction Proxy: MU does no transaction
     Read Only Transaction: MU only reads data
     Weak Transaction: Read and update cached data;
      Must synchronize updates with primary copy on FN.
MU may have primary copy of data
MU may access data on other MUs
First class and second class transactions
2/24/98                ICDE/SMU - Dunham                  59
MT Recovery
Transaction, site, media, network failure - More
 frequent than in wired network.
Different types of failures (partial)
  Voluntary disconnection
  Battery problems
  Lose computer??
Checkpoint data at MU to BS
Checkpoint at handoff
Database log plus transaction log
May need compensating - transactions
2/24/98            ICDE/SMU Dunham                  60
Atomicity for MT

Weaken or provide different types of atomicity
May decompose transaction into
May require atomicity at lower than transaction
Atomic commitment difficult (expensive)
Global commit/Local Commit

2/24/98            ICDE/SMU - Dunham               61
Consistency for MT

Weakening isolation and atomicity may weaken
 this as well.
May divide data into clusters with consistency
 within clusters.
Reintegration of updates after reconnect may
 cause many conflicts.
May use bounded inconsistency.
Impacted by location dependent data

2/24/98            ICDE/SMU - Dunham          62
Isolation for MT

May be too restrictive
Can’t always do at MU (disconnection)
Isolation at lower levels in transaction
Commitment at different levels of transaction
Cooperating transactions

2/24/98            ICDE/SMU - Dunham             63
Durability for MT

Durability for partial results
May want durability for parts of transactions.
Due to conflicts at reconnect, even durability of
 subtransactions may not be guaranteed.
Local commit vs.. Global commit

2/24/98             ICDE/SMU - Dunham                64
MT Concurrency Control

                    1) T1: Lock(Xa);

Mobility of MUs           Read(Xa)                                        Server B
                                              2) T1 moves to B              Cell B
                         Server A
 may increase             Cell A                                               Xb
 message traffic            Xa
                                               3) T1: Lock(Yb);
 for lock
 management                                6) T1: Unlock(Yb);

MU failure may
 leave some data                       6) T1: Unlock(Xa);
                                                                       4) T1 moves to C

 locked /unlocked   Fig 2 from [48]              Xc
                                                 Yc               5) T1: Lock(Zc);
                                                 Zc                     Write(Zc);
                                              Server C                   Commit
                                               Cell C
2/24/98             ICDE/SMU - Dunham                                               65
    Revised Optimistic Locking

                                    LOCK     W_INTEND R_LOCK W_LOCK
 Read locks may be                 HELD

  executed at multiple          LOCK
  servers.                      W_Intend No                   Yes      No

 Read unlock can be            R_Lock       No               Yes      No
  executed at any site
                                W_Lock       No               No       No
 Benefit shown using
  analytic model                                  Figure 3 from [48]

 Purdue, [48]

2/24/98                  ICDE/SMU - Dunham                                  66
Kangaroo Transaction (KT)

Built on top of global transactions
Captures data and movement behavior
DAA as BS - Maintains logging and transaction
Logging at BS
Flexible atomicity
Restart after disconnect
Management moves

2/24/98           ICDE/SMU - Dunham              67
Kangaroo Transaction (cont’d)

Local Transaction - Sequence of read and write
 operations ending in commit or abort
Global Transaction - Sequence of global or local
Joey Transaction - Sequence of global and local
 transactions ending in commit, abort, or split
Kangaroo Transaction - Sequence of one or
 more Joeys with last one ending in commit or
 abort. All earlier end in split
SMU, [47]
2/24/98            ICDE/SMU - Dunham            68
KT and Movement

2/24/98     ICDE/SMU - Dunham   69
Reporting and Co-Transactions

Mobile transaction is a special type of
 multidatabase transactions.
GDMS exists at each base station.
Subtransactions of the mobile transaction will
 commit or abort independently.
Atomic and non-compensatable transactions.
Reporting and co-transactions.
Pittsburgh, [46]

2/24/98            ICDE/SMU - Dunham              70
Clustering Model

Views mobile transaction as beginning on
 mobile and nonmobile hosts.
Transaction migration
Transaction model is designed to maintain
 consistency of the database.
Database is divided into clusters.
Data is divided into core and quasi copies.
Mobile transactions and operations are
 decomposed into a set of weak and strict
2/24/98            ICDE/SMU - Dunham           71
Clustering Model (cont’d)

Weak operations access only data in the same
 cluster. Strict operations allowed database wide
 access. Two copies of data can be maintained
 (strict and weak).
Clusters defined based on location and user
Transaction Proxy: dual transaction of one
 executed at mobile host which includes only the
Purdue, [51,52]
2/24/98            ICDE/SMU - Dunham            72
Mobile Transactions and
Ambulatory Care

Medical Personal Digital Assistant (MPDA)
Battlefield - Cache copy of soldiers’ medical
 records in MPDA
Distributed Medical Database - EMT obtains
 patient’s medical record and updates.
BSA (Base Station Agent) is responsible for
 logging and recovery.
Recovery based on sagas with save-points.
Mailboxes used to save information.
Purdue, [49,50]
2/24/98            ICDE/SMU - Dunham             73
 Semantics-Based Mobile
 Transaction Processing

Views mobile transaction processing as a
 concurrency and cache coherency problem.
A stationary database server dishes out the
 fragments of an object on a request from a
 Mobile Unit.
On completion of the transaction, the Mobile
 Units return the fragments to the server.
These fragments are put together again by the
 merge operation at the server.
Pittsburgh, [54]
2/24/98            ICDE/SMU - Dunham             74
Multidatabase Transaction
Processing Manager

Mobile transactions built on top of multidatabase
 global transactions.
Timestamps used to enforce ordering
Allows voluntary disconnections.
MU part of MDS
Message Queuing Facility (MQF)
MU sends request to designated coordinating
 node on FN.
Monash, [56]
2/24/98            ICDE/SMU - Dunham            75

MC/Database Transaction Processing approach
Multiple transaction types
 Controlled divergence
 Update cache and later DB at FH
Compact - Compact Agent at MU, Mobility
 Manager at BS, Compact Manager at Server
Pittsburgh, [55]

2/24/98          ICDE/SMU - Dunham         76
MT Research Limitations

Architectural Assumptions
No support for location dependent data
Few Implementations

2/24/98            ICDE/SMU - Dunham      77
MT Management Options


2/24/98          ICDE/SMU - Dunham   78

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing
  Client-Agent-Server Model
  Mobile Agent
Projects & Products
2/24/98            ICDE/SMU - Dunham     79

Application dispatched by and
                                                       Client   Server
 working for the client.
  Solves disconnect problem                  Client    Agent    Server

  Solves slow bandwidth problem
Agent Classification:
Type - Client,Server,Application,User
       Movement - Static, Relocatable, Migrating (Mobile)
       Number - Single, Multiple, Clonable
  2/24/98                 ICDE/SMU - Dunham                      80
Itinerant Agent (Mobile Agent)

Program dispatched from mobile unit that roams
 through the fixed network to satisfy client’s data
At a server the agent is sent to an Agent
 Meeting Point (AMP) where desired server
 functions are determined and requested.
Client, Migrating, Single
IBM, [58]

2/24/98             ICDE/SMU - Dunham             81
Migrating User Agent

User process that mimics MU.
Process migrates as user moves.
Client, Migrating, Single
Massachusetts, AT&T, [63]

2/24/98           ICDE/SMU - Dunham   82
Remote Programming

Language for communication required.
User and server communication without using
Places - Meeting points for agents and servers
Agents - Application is set of agents. Agent is
 either at a place or travelling between places.
Travel - Go instruction
Meetings - Agents communicating at a place.
General Magic Telescript, [59]
2/24/98             ICDE/SMU - Dunham              83

Mitsubishi Electra ITA
Java Objects; JDBC

                                 User                                         Oracle
                                 Agent                                        Server
Collaborating Agents

Agent Server - FN                                        Agent

User Agent - MU to BS                   Collaboration

Query Agents- BS to
 Server                                                   Agent

Collaborator - BS                                                            Notes
                             Adapted from Fig 6 in [61]

Mitsubishi Electric ITA,
2/24/98             ICDE/SMU - Dunham                                                  84

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing
Projects & Products
2/24/98           ICDE/SMU - Dunham      85
Some DB/MC Projects URLs
 MobiDick - Monash Univ. (Australia);
 Mobisaic - Univ. of Washington;
 Purdue;
 SMU;
 MCC - Collaboration Managment Infrastructure;
 University of Ioanina;
 Michigan - CITI;
 UCLA - Ficus;
 Columbia;
2/24/98                  ICDE/SMU - Dunham               86

           Figure 6.1 from [15]

2/24/98      ICDE/SMU - Dunham     87
Oracle Mobile Agent

                                      Message Manager

Commercial Product
Application, Static,                                              Gateway

Message Manager - MU

Message Gateway - BS
Agent - FN (Server)

                                                        Database Server

2/24/98         ICDE/SMU - Dunham                                88
Sybase - SQL Anywhere

Designed for
                                              Remote Database
 Windows, (95, 3.x,                     SQL Anywhere standalone engine
                                               Message agent

 NT), OS/2, DOS
Limited memory
Full TP capabilities
Includes SQL Remote
Compatible with
 Sybase SQL Server
                                        Consolidated Database
[68]                                SQL Anywhere network server
                                           Message agent

2/24/98          ICDE/SMU - Dunham                                 89
 Sybase (cont’d) - SQL Remote
Two way replication based on
   message passing.                                    Consolidat
Remote database are synchronized
   with consolidated DB
Message Agent required at DB server
Replication of subscribed fragments           Remote Databases

Periodic changes sent from consolidated
   DB to remote DBs
Updates from committed transactions at remote
   submitted to consolidated database.
Conflicts: Consolidated is- Dunham
 2/24/98              ICDE/SMU
                               master; Triggers used. 90

I-Mobile 1.0 discontinued:
  No replication
  Three tier approach appropriate for long term, but in
   the short term users wanted to be able to use
   existing client-server applications (not rewrite).
  Small DBMS server to run on mobile client
  Only dial up needed for now
Informix Dynamic Server/Personal Edition
    (IDS/PE) for Windows 95/NT. Mobiles and
    desktop clients
2/24/98              ICDE/SMU - Dunham                     91

Introduction & Data Management Issues
Query Processing
Data Broadcasting
Transaction Processing

2/24/98           ICDE/SMU - Dunham      92

Combine different approaches
Semantic caching
Query Optimization
Adaptive Data Broadcasting
Performance Benchmarks
Location Dependent Queries

2/24/98           ICDE/SMU - Dunham   93
Acknowledgements and URL

 Earlier version of this tutorial presented at the 1996
  Brazilian Database Symposium.
 We particularly want to thank Evaggelia Pitoura for
  providing several tables and figures from her recent
  book [15].
 Some slide information obtained from slides presented
  at a database class at the University of Massachusetts,
Online bibliographies
2/24/98                ICDE/SMU - Dunham                    94