ieee icde 98 tutorial mobile computing and databases
Download
Skip this Video
Download Presentation
IEEE ICDE ‘98 Tutorial: Mobile Computing and Databases

Loading in 2 Seconds...

play fullscreen
1 / 94

IEEE ICDE - PowerPoint PPT Presentation


  • 180 Views
  • Uploaded on

IEEE ICDE ‘98 Tutorial: Mobile Computing and Databases. Margaret H. Dunham Southern Methodist University Dept of Computer Science and Engineering Dallas, Texas 75275 [email protected] http://www.seas.smu.edu/~mhd. Outline. Introduction & Data Management Issues Query Processing Caching

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'IEEE ICDE ' - Angelica


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ieee icde 98 tutorial mobile computing and databases

IEEE ICDE ‘98 Tutorial:Mobile Computing and Databases

Margaret H. Dunham

Southern Methodist University

Dept of Computer Science and Engineering

Dallas, Texas 75275

[email protected]

http://www.seas.smu.edu/~mhd

outline
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data Broadcasting
  • Transaction Processing
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

terminology
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))

ICDE/SMU - Dunham

wireless networks
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, Motorola ALTAIR

ICDE/SMU - Dunham

wireless networks cont d
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)

ICDE/SMU - Dunham

handoff
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

ICDE/SMU - Dunham

location management
Location Management
  • Tracking mobile user
  • User associated with home location server (Home Agent)
  • May augment by searching in local area first
  • May augment with user profiles
  • Mobile IP [11,14]
    • Triangle Routing
    • Route Optimization
    • Location Control (Routing Agent)

S

Ah

Af

M

ICDE/SMU - Dunham

location management cont d
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

ICDE/SMU - Dunham

mobile applications
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

ICDE/SMU - Dunham

technology push
Technology Push
  • Internet: ftp, telnet, email, http,html
  • Advancing Wireless Communication Technologies
  • Laptop, Notebook, and Palmtop Computers

ICDE/SMU - Dunham

data management issues
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

ICDE/SMU - Dunham

insurance example
Insurance Example

ICDE/SMU - Dunham

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

ICDE/SMU - Dunham

mc db research
MC/DB Research
  • Transaction Processing
  • Caching - Replication
  • Broadcast Disks
  • Agents
  • Mobility
  • Location Dependent Data
  • Recovery
  • ACID (?)

ICDE/SMU - Dunham

outline17
Outline
  • Introduction & Data Management Issues
  • Query ProcessingLocation Dependent Queries and DataNew Query TypesQuery Optimization
  • Caching
  • Data Broadcasting
  • Transaction Processing
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

location dependent data
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]

ICDE/SMU - Dunham

location dependent queries
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).”

ICDE/SMU - Dunham

similarity to spatial queries
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]

ICDE/SMU - Dunham

differences from spatial queries
Differences from Spatial Queries
  • Client is actually moving
  • Location of client may be part of the query itself
  • May depend on direction of movement
  • Data may not directly contain location information
  • Includes temporal features as well

Spatial data is dynamic

ICDE/SMU - Dunham

querying moving objects
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]

ICDE/SMU - Dunham

query optimization
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.

ICDE/SMU - Dunham

outline24
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • CachingOverviewTypesResearch
  • Data Broadcasting
  • Transaction Processing
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

caching
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

ICDE/SMU - Dunham

caching functions
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

ICDE/SMU - Dunham

connectivity and file systems
Connectivity and File Systems

Table 3.2 from [15]

ICDE/SMU - Dunham

mu replica control protocols
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

ICDE/SMU - Dunham

checkpointing
Checkpointing

Table 3.4 from [15]

ICDE/SMU - Dunham

prefetching vs hoarding
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

ICDE/SMU - Dunham

hoarding spying
Hoarding/Spying
  • Listening to and recording file accesses
  • Performed during a snapshot interval
  • May be combined with user profiles.
  • Results limited to the snapshot.

ICDE/SMU - Dunham

disconnected issues
Disconnected Issues

Table 3.1 from [15]

ICDE/SMU - Dunham

slide33
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

ICDE/SMU - Dunham

coda cont d
Coda (cont’d)
  • Venus states: hoarding,emulating,write disconnected (earlier reintegrating).
  • Cache misses during disconnection are treated as failures.
  • During disconnection, a log (Change Modify Log) of operations is created.

Hoarding

Strong Connection

Weak Connection

Disconnection

Write

Disconnected

Connection

Disconnection

Emulating

ICDE/SMU - Dunham

Adapted from Fig 2 in [34]

coda cont d35
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]

ICDE/SMU - Dunham

little work
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

ICDE/SMU - Dunham

little work cont d
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]

ICDE/SMU - Dunham

slide38
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]

ICDE/SMU - Dunham

summary
Summary

Table 3.1 from [15]

ICDE/SMU - Dunham

sleepers and workaholics
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, [21]

ICDE/SMU - Dunham

transparent analytic spying
Transparent Analytic Spying

A

B

C

D

E

F

Access Tree

  • File Working Sets
  • Continually observe and record (in a log) file access. At hoard time, reference the log to determine hoard.
  • Trees for a process are created reflecting file access pattern. One tree per program execution is generated.

ICDE/SMU - Dunham

transparent analytic spying cont d
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]

ICDE/SMU - Dunham

predictive file caching
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]

ICDE/SMU - Dunham

virtual primary copy
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]

ICDE/SMU - Dunham

slide45
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 between wards.

ICDE/SMU - Dunham

roam cont d
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]

ICDE/SMU - Dunham

semantic cache
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

ICDE/SMU - Dunham

outline48
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data BroadcastingOverviewIndexingResearch
  • Transaction Processing
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

data broadcasting
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.

ICDE/SMU - Dunham

data broadcasting cont d
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.

ICDE/SMU - Dunham

broadcast disks
Broadcast Disks
  • Simulate multiple disks of varying sizes and speeds. Data of higher interest on smaller faster disks (broadcast more frequently).
  • Each “disk” contains data with similar access behavior.
  • Combination of caching and broadcast disks.

Figure 4.1 from [15]

ICDE/SMU - Dunham

broadcast disks cont d
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]

ICDE/SMU - Dunham

air cache
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.

ICDE/SMU - Dunham

air cache cont d
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]

ICDE/SMU - Dunham

adaptive protocols
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]

ICDE/SMU - Dunham

outline56
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data BroadcastingTransaction ProcessingOverviewTransaction ModelConcurrencyRecoveryResearch
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

mobile transaction mt
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

ICDE/SMU - Dunham

mt requirements
MT Requirements
  • Keep autonomy of local DBMS
  • LLT
  • Interactive
  • Advanced transaction models
    • Nested
    • Multidatabase
  • Request from MU
  • Execute anywhere
  • Capture movement
  • ACID (?)

ICDE/SMU - Dunham

mt approaches
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

ICDE/SMU - Dunham

mt recovery
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

ICDE/SMU - Dunham

atomicity for mt
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

ICDE/SMU - Dunham

consistency for mt
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

ICDE/SMU - Dunham

isolation for mt
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

ICDE/SMU - Dunham

durability for mt
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

ICDE/SMU - Dunham

mt concurrency control
MT Concurrency Control

1) T1: Lock(Xa);

Read(Xa)

2) T1 moves to B

Server A

Cell A

Xa

Ya

3) T1: Lock(Yb);

Read(Yb)

Server B

Cell B

6) T1: Unlock(Yb);

Commit;

Xb

Yb

4) T1 moves to C

Xc

Yc

Zc

5) T1: Lock(Zc);

Write(Zc);

Unlock(Zc);

Commit

Server C

Cell C

  • Mobility of MUs may increase message traffic for lock management
  • MU failure may leave some data locked /unlocked

6) T1: Unlock(Xa);

Commit;

Fig 2 from [48]

ICDE/SMU - Dunham

revised optimistic locking
Revised Optimistic Locking
  • O2PL-MT
  • Read locks may be executed at multiple servers.
  • Read unlock can be executed at any site
  • Benefit shown using analytic model
  • Purdue, [48]

Figure 3 from [48]

ICDE/SMU - Dunham

kangaroo transaction kt
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

ICDE/SMU - Dunham

kangaroo transaction cont d
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]

ICDE/SMU - Dunham

kt and movement
KT and Movement

ICDE/SMU - Dunham

reporting and co transactions
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]

ICDE/SMU - Dunham

clustering model
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.

ICDE/SMU - Dunham

clustering model cont d
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]

ICDE/SMU - Dunham

mobile transactions and ambulatory care
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]

ICDE/SMU - Dunham

semantics based mobile transaction processing
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]

ICDE/SMU - Dunham

multidatabase transaction processing manager
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]

ICDE/SMU - Dunham

pro motion
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]

ICDE/SMU - Dunham

mt research limitations
MT Research Limitations
  • Architectural Assumptions
  • No support for location dependent data
  • Few Implementations

ICDE/SMU - Dunham

mt management options
MT Management Options
  • MU
  • BS
  • Combination
  • Fixed/Relocatable/Moving
  • Agent

ICDE/SMU - Dunham

outline79
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data Broadcasting
  • Transaction Processing
  • AgentsOverviewClient-Agent-Server ModelMobile Agent
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

agent
Agent

Client

Server

Client

Server

Agent

  • Application dispatched by and working for the client.
  • Agent:
    • Solves disconnect problem
    • Solves slow bandwidth problem
  • Client-Agent-Server
  • Agent Classification:
  • Type - Client,Server,Application,User
      • Movement - Static, Relocatable, Migrating (Mobile)
      • Number - Single, Multiple, Clonable

ICDE/SMU - Dunham

itinerant agent mobile agent
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]

ICDE/SMU - Dunham

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

ICDE/SMU - Dunham

remote programming
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]

ICDE/SMU - Dunham

concordia
Concordia

User

Agent

Oracle

Server

Concordia

Query

Agent

Collaboration

Query

Agent

Notes

Server

Concordia

Adapted from Fig 6 in [61]

  • Mitsubishi Electra ITA
  • Java Objects; JDBC
  • Collaborating Agents
  • Agent Server - FN
  • User Agent - MU to BS
  • Query Agents- BS to Server
  • Collaborator - BS
  • Mitsubishi Electric ITA, [60,61]

ICDE/SMU - Dunham

outline85
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data Broadcasting
  • Transaction Processing
  • Agents
  • Projects & Products
  • Conclusion

ICDE/SMU - Dunham

some db mc projects urls
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

ICDE/SMU - Dunham

rover
Rover
  • Figure 6.1 from [15]

ICDE/SMU - Dunham

oracle mobile agent
Oracle Mobile Agent

Message Manager

  • Commercial Product
  • Application, Static, Multiple
  • Message Manager - MU
  • Message Gateway - BS
  • Agent - FN (Server)
  • [67,69]

Gateway

Corporate

Network

Agent

Database Server

ICDE/SMU - Dunham

sybase sql anywhere
Sybase - SQL Anywhere

Remote Database

SQL Anywhere standalone engine

Message agent

Consolidated Database

SQL Anywhere network server

Message agent

  • Designed for Windows, (95, 3.x, NT), OS/2, DOS
  • Limited memory requirements
  • Full TP capabilities
  • Includes SQL Remote
  • Compatible with Sybase SQL Server
  • [68]

ICDE/SMU - Dunham

sybase cont d sql remote
Sybase (cont’d) - SQL Remote

Consolidated

DB

Remote Databases

  • Two way replication based on message passing.
  • Remote database are synchronized with consolidated DB
  • Message Agent required at DB server
  • Replication of subscribed fragments
  • Periodic changes sent from consolidated DB to remote DBs
  • Updates from committed transactions at remote submitted to consolidated database.
  • Conflicts: Consolidated is master; Triggers used.

ICDE/SMU - Dunham

informix
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]

ICDE/SMU - Dunham

outline92
Outline
  • Introduction & Data Management Issues
  • Query Processing
  • Caching
  • Data Broadcasting
  • Transaction Processing
  • Agents
  • Products
  • Conclusion

ICDE/SMU - Dunham

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

ICDE/SMU - Dunham

acknowledgements and url bibliographies
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

ICDE/SMU - Dunham

ad