Docstoc

MOBILE COMPUTING AND DATABASES

Document Sample
MOBILE COMPUTING AND DATABASES Powered By Docstoc
					IEEE ICDE ‘98 Tutorial:
Mobile Computing and Databases

          Margaret H. Dunham
     Southern Methodist University
    Dept of Computer Science and
               Engineering
          Dallas, Texas 75275
           mhd@seas.smu.edu
    http://www.seas.smu.edu/~mhd
Outline


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

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




2/24/98      ICDE/SMU - Dunham   3
Terminology


Fixed Network (FN)
Base Station (BS) (Mobile Support Station -
 (MSS))
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

Cellular
      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
Handoff

Changing BS due to
 movement between cells
State information
  transferred
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
                                                S

 area first             S


May augment with user profiles
                        M



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
  Trucking
  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
 Technologies
Laptop, Notebook, and Palmtop Computers




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




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

 Speed of wireless link
 Scalability
 Mobility
 Location dependent data; Location specific
  queries
 Limited by battery power
 Disconnection (Voluntary, Involuntary)
 Replication/Caching
 Handoff
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
Agents
Mobility
Location Dependent Data
Recovery
ACID (?)

2/24/98          ICDE/SMU - Dunham   16
Outline
Introduction & Data Management Issues
Query Processing
  Location Dependent Queries and Data
  New Query Types
  Query Optimization
Caching
Data Broadcasting
Transaction Processing
Agents
Projects & Products
Conclusion
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
 me).”


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
 information
Includes temporal features as well


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

Moving Objects Spatio-Temporal (MOST) data
 model
     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
 disk.
2/24/98            ICDE/SMU - Dunham            23
Outline

Introduction & Data Management Issues
Query Processing
Caching
  Overview
  Types
  Research
Data Broadcasting
Transaction Processing
Agents
Projects & Products
Conclusion
2/24/98           ICDE/SMU - Dunham      24
Caching

  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)
Replacement
Coherency
     Callback - Servers send invalidation messages to
      clients.
     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
      quorum
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
Checkpointing




                 Table 3.4 from [15]



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

 Both prefetch data in anticipation of future use.
 Prefetching
      Objective is to improve performance (throughput or
       response time).
      Cache miss not catastrophic.
 Hoarding
      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
Hoarding/Spying


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
Coda

First project to demonstrate disconnected
 operation.
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
 reintegrating).
Cache misses during
                                                                       Write
 disconnection are treated as                                       Disconnected

 failures.
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
 connection
     Connected - Continuous; High bandwidth; Normal
      operation
     Partially Connected - Continuous; Dialup; Delayed
      writes
     Fetch Only - On demand; Cellular; Optimistic
      replication
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
Seer
Ficus
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
Summary




          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
   query.
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
 execution.
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
Conclusion:
  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
 sites
Monash, [23]

2/24/98            ICDE/SMU - Dunham             44
Roam

MC Replication System
MU Peer to Peer
 communication allowed
Ward Model:
     Ward: Grouping of replicas for
        locations that frequently
        communicate
     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-
 ward
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>
 SMU
2/24/98          ICDE/SMU - Dunham           47
Outline

Introduction & Data Management Issues
Query Processing
Caching
Data Broadcasting
  Overview
  Indexing
  Research
Transaction Processing
Agents
Projects & Products
Conclusion
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)
Classification:
    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
 better.
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
 behavior.
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
Air-Cache

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
 temperature.
Sparks (access) to data can increase
 temperature. No sparks, results in a reduction
 of temperature.
Simulation results predict very good
 performance.
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
     Priority
     Popularity Factor (PF)
     Ignore Factore (IF)
Variable Broadcst Size (VBS) Server Protocol:
     Aperiodic
     All data above threshold PF included.
Arizona and UMKC, [40]
2/24/98                 ICDE/SMU - Dunham        55
Outline
  Introduction & Data Management Issues
  Query Processing
  Caching
 Data Broadcasting
     Transaction Processing
     Overview
     Transaction Model
     Concurrency
     Recovery
     Research
  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
 Issues
          Disconnect/Handoff
          Mobility
          Location Dependent Data
          Error Prone
          MU Resources/ Power
          Recovery/Restart
          Management
2/24/98                ICDE/SMU - Dunham      57
MT Requirements
Keep autonomy of local DBMS
LLT
Interactive
Advanced transaction models
    Nested
    Multidatabase
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
      processing
     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)
  Handoff
  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
 subtransactions
May require atomicity at lower than transaction
 level
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
                                                                               Yb
 message traffic            Xa
                            Ya
                                               3) T1: Lock(Yb);
                                                      Read(Yb)
 for lock
 management                                6) T1: Unlock(Yb);
                                                   Commit;

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

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

 O2PL-MT
                                    LOCK     W_INTEND R_LOCK W_LOCK
 Read locks may be                 HELD

  executed at multiple          LOCK
                                REQUEST
  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
 status
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
 transactions
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
 transactions.
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
 profile.
Transaction Proxy: dual transaction of one
 executed at mobile host which includes only the
 updates.
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
PRO-MOTION

MC/Database Transaction Processing approach
Multiple transaction types
 Controlled divergence
 ACID
 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


MU
BS
Combination
Fixed/Relocatable/Moving
Agent




2/24/98          ICDE/SMU - Dunham   78
Outline

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

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

  Solves slow bandwidth problem
Client-Agent-Server
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
 request.
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
 network.
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
Concordia

Mitsubishi Electra ITA
Java Objects; JDBC




                                                                  Concordia
                                 User                                         Oracle
                                 Agent                                        Server
Collaborating Agents
                                                          Query

Agent Server - FN                                        Agent



User Agent - MU to BS                   Collaboration


Query Agents- BS to
                                                          Query
 Server                                                   Agent




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

Mitsubishi Electric ITA,
 [60,61]
2/24/98             ICDE/SMU - Dunham                                                  84
Outline


Introduction & Data Management Issues
Query Processing
Caching
Data Broadcasting
Transaction Processing
Agents
Projects & Products
Conclusion
2/24/98           ICDE/SMU - Dunham      85
Some DB/MC Projects URLs
 MobiDick - Monash Univ. (Australia);
   http://www.ct.monash.edu.au/~mobidick
 Mobisaic - Univ. of Washington;
   http://www.cs.washington.edu/homes/voelker/mobisaic
 Purdue; http://www.cs.purdue.edu/research/cse/mobile
 SMU; http://www.seas.smu.edu/~mhd/mobile.html
 MCC - Collaboration Managment Infrastructure;
   http://www.mcc.com/projects/transaction
 University of Ioanina; http://zeus.cs.uoi.gr/
 Michigan - CITI;
   http://www.citi.umich.edu/projects/mobile.html
 UCLA - Ficus; http://ficus-www.cs.ucla.edu/ficus
 Columbia; http://www.mcl.cs.columbia.edu
2/24/98                  ICDE/SMU - Dunham               86
Rover




           Figure 6.1 from [15]




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

                                      Message Manager

Commercial Product
Application, Static,                                              Gateway


 Multiple
Message Manager - MU
                                    Corporate
                                     Network


Message Gateway - BS
Agent - FN (Server)
[67,69]
                                     Agent



                                                        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
 requirements
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
                                                           ed
                                                          DB
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
Informix

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
[64,66]
2/24/98              ICDE/SMU - Dunham                     91
Outline


Introduction & Data Management Issues
Query Processing
Caching
Data Broadcasting
Transaction Processing
Agents
Products
Conclusion

2/24/98           ICDE/SMU - Dunham      92
Future


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


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


 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,
  http://www-ccs.cs.umass.edu/mobile.
Online bibliographies
     http://www.seas.smu.edu/~mhd/mobile.html
     http://www.ct.monash.edu.au/~mobidick
2/24/98                ICDE/SMU - Dunham                    94

				
DOCUMENT INFO