2. 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

3. 2/24/98ICDE/SMU - Dunham2 Outline 4Introduction & Data Management Issues zQuery Processing zCaching zData Broadcasting zTransaction Processing zAgents zProjects & Products zConclusion

4. 2/24/98ICDE/SMU - Dunham3 Mobile Computing Architecture

5. 2/24/98ICDE/SMU - Dunham4 Terminology zFixed Network (FN) zBase Station (BS) (Mobile Support Station - (MSS)) zFixed Hosts (FH) zCell - Area covered by BS (1-2 miles) zHandoff - Changing BS by intercell move zMobile Host (MH) (Mobile Unit (MU))

6. 2/24/98ICDE/SMU - Dunham5 Wireless Networks zCellular yHigh Cost yScalability Issue yLimited Bandwidth: 10 Kbps zWireless LAN yTraditional LANs with wireless interface yLow Cost yLimited range: 10-100 meters yBandwidth: 10Mbps yNCR Wavelan, Motorola ALTAIR

7. 2/24/98ICDE/SMU - Dunham6 Wireless Networks (contd) zSatellite Services yWide Coverage yVery Expensive yLow Bandwidth: 1-2Mbps zPaging Networks yWide Coverage ySky Tel, Motorola zSlow: ( Ethernet: 10Mbps; FDDI or switched Ethernet: 100Mbps; ATM: 155Mbps)

8. 2/24/98ICDE/SMU - Dunham7 Handoff zChanging BS due to movement between cells zState information transferred zCurrent handoffs in cellular phones may take up to a few seconds with breaks in conversation of 100-300 ms. zSoft - Temporarily connected to two BSs zHard - Only connected to one BS

9. 2/24/98ICDE/SMU - Dunham8 Location Management zTracking mobile user zUser associated with home location server (Home Agent) zMay augment by searching in local area first zMay augment with user profiles zMobile IP [11,14] yTriangle Routing yRoute Optimization yLocation Control (Routing Agent) AfAh S M

10. 2/24/98ICDE/SMU - Dunham9 Location Management (contd) zActive Badge (Cambridge,[2]) yTrack employees and route telephone calls yUnique code emitted every 15 seconds ySensors placed in offices and corridors zLocation Information Replications yNo HLR yHierarchy of Location Servers yEach server maintains information about its subtree

11. 2/24/98ICDE/SMU - Dunham10 Mobile Applications zInformation Services (Yellow Pages) zLaw Enforcement and Medical Emergencies zSales and Mobile Offices zWeather, Traffic, Sports, Entertainment zTrucking zCellular Subscribers in the United States: y90,000 in 1984;4.4 million in 1990; 13 million in 1994 yHandheld computer market will grow to $1.77 billion by 2002

12. 2/24/98ICDE/SMU - Dunham11 Technology Push zInternet: ftp, telnet, email, http,html zAdvancing Wireless Communication Technologies zLaptop, Notebook, and Palmtop Computers

13. 2/24/98ICDE/SMU - Dunham12 Classification of Mobile Database Systems

14. 2/24/98ICDE/SMU - Dunham13 Data Management Issues zSpeed of wireless link zScalability zMobility zLocation dependent data; Location specific queries zLimited by battery power zDisconnection (Voluntary, Involuntary) zReplication/Caching zHandoff

15. 2/24/98ICDE/SMU - Dunham14 Insurance Example

16. 2/24/98ICDE/SMU - Dunham15 Medical Example z911 Call zAmbulance arrives/departs zClosest hospital zAccess patient records zSend vital signs zUpdate patient records zPage hospital personnel zOrder medical supplies

17. 2/24/98ICDE/SMU - Dunham16 MC/DB Research zTransaction Processing zCaching - Replication zBroadcast Disks zAgents zMobility zLocation Dependent Data zRecovery zACID (?)

18. 2/24/98ICDE/SMU - Dunham17 Outline zIntroduction & Data Management Issues 4Query Processing Location Dependent Queries and Data New Query Types Query Optimization zCaching zData Broadcasting zTransaction Processing zAgents zProjects & Products zConclusion

19. 2/24/98ICDE/SMU - Dunham18 Location Dependent Data zValue of data depends on location zTemporal Replication - One consistent value at one time zSpatial Replication - Multiple different correct data values at one time zTemporal Consistency - All data objects satisfy a given set of integrity constraints. zSpatial Consistency - Consistency constraints satisfied within Data Region. zSMU/University of Missouri at Kansas City, [17]

20. 2/24/98ICDE/SMU - Dunham19 Location Dependent Queries zResult depends on location zDifferent from traditional distributed goal of location independence zEx: Yellow Pages, Directions, Map zPredicates based on location: Find the cheapest hotel in Dallas. zLocation constraints: Find the nearest hotel (to me).

21. 2/24/98ICDE/SMU - Dunham20 Similarity to Spatial Queries zSpatial Data: Data associated with space occupied by object. zTypes of spatial queries: contains, contained in, intersects, neighboring, east of, etc. zSpatial data structures zSpatial operators zSpatial selects and joins zPSQL - extend SQL, [18,20]

22. 2/24/98ICDE/SMU - Dunham21 Differences from Spatial Queries zClient is actually moving zLocation of client may be part of the query itself zMay depend on direction of movement zData may not directly contain location information zIncludes temporal features as well Spatial data is dynamic

23. 2/24/98ICDE/SMU - Dunham22 Querying Moving Objects zMoving Objects Spatio-Temporal (MOST) data model yDynamic Attributes - Change over time yQueries over temporal history: xInstantaneous - Ex: Find all restaurants Ill reach in the next half hour. xContinuous - Ex: Find all restaurants within 5 miles. The answer continuously changes as the MU moves. xPersistent - Ex: Find the cars that travel greater than 10 miles in the next half hour. zFuture Temporal Logic (FTL) language zUniversity of Illinois, [20]

24. 2/24/98ICDE/SMU - Dunham23 Query Optimization zHow best to satisfy the information request made by the client? zDifferent Cost Factors: I/O, network zDifferent Access Options: cache, FN, broadcast zDynamic and Adaptable - environment changes zAlternative 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.

25. 2/24/98ICDE/SMU - Dunham24 Outline zIntroduction & Data Management Issues zQuery Processing 4Caching Overview Types Research zData Broadcasting zTransaction Processing zAgents zProjects & Products zConclusion

26. 2/24/98ICDE/SMU - Dunham25 Caching zPlacing data at MU. Usually on disk. zFaster to access from MU than from DBMS in fixed network. zFacilitates disconnected operation. zAdaptive to connection mode. zNot just another replica zPull based zMost work on files not databases

27. 2/24/98ICDE/SMU - Dunham26 Caching Functions zData fetching yGranularity (Page, file, table, semantic) zReplacement zCoherency yCallback - Servers send invalidation messages to clients. yDetection - Clients send queries to servers to. zUpdating during disconnect zData integration when reconnected

28. 2/24/98ICDE/SMU - Dunham27 Connectivity and File Systems Table 3.2 from [15]

29. 2/24/98ICDE/SMU - Dunham28 MU Replica Control Protocols zTraditional Replication Protocol problems: yMay hinder mobility yQuorum Consensus: Cant get quorum if disconnected; Avoid using MU replicas to make up quorum zLocation information not always readily available zPrimary Copy: Should not be stored at MU zFirst class/Second class replicas

30. 2/24/98ICDE/SMU - Dunham29 Checkpointing Table 3.4 from [15]

31. 2/24/98ICDE/SMU - Dunham30 Prefetching vs.. Hoarding zBoth prefetch data in anticipation of future use. zPrefetching yObjective is to improve performance (throughput or response time). yCache miss not catastrophic. zHoarding yObjective is to fetch all needed data into MU cache prior to disconnect. Thus the goal is to facilitate disconnected operation. yCache miss is catastrophic. yOK to overfetch

32. 2/24/98ICDE/SMU - Dunham31 Hoarding/Spying zListening to and recording file accesses zPerformed during a snapshot interval zMay be combined with user profiles. zResults limited to the snapshot.

33. 2/24/98ICDE/SMU - Dunham32 Disconnected Issues Table 3.1 from [15]

34. 2/24/98ICDE/SMU - Dunham33 Coda zFirst project to demonstrate disconnected operation. zOptimistic Locking zGranularity - sets of files. zCoherency - callbacks zHoard Walking: Periodically (every 10 min) evaluate contents of cache. Recalculate priorities. zOn a callback break, object is purged, refetching on demand or during next hoard walk. zVenus - cache manager at MU

35. 2/24/98ICDE/SMU - Dunham34 Coda (contd) zVenus states: hoarding,emulating,write disconnected (earlier reintegrating). zCache misses during disconnection are treated as failures. zDuring disconnection, a log (Change Modify Log) of operations is created. Hoarding Write Disconnected Emulating Adapted from Fig 2 in [34] Disconnection Strong Connection Weak Connection Connection Disconnection

36. 2/24/98ICDE/SMU - Dunham35 Coda (contd) zDuring integration, log applied. Conflicting updates are determined and user assists in resolution zTimestamps at volume and object level used to determine conflicts. zTrickle Reintegration used to asynchronously propagate updates. zHoard Profile - list of files and priorities. zLowest priority objects chosen for replacement. zWeak Connectivity - low bandwidth, high latency, high cost, or intermittent zCMU, [29,34]

37. 2/24/98ICDE/SMU - Dunham36 Little Work zDisconnected AFS zCache operations depends on type of connection yConnected - Continuous; High bandwidth; Normal operation yPartially Connected - Continuous; Dialup; Delayed writes yFetch Only - On demand; Cellular; Optimistic replication zDisconnected - Fail if cache miss

38. 2/24/98ICDE/SMU - Dunham37 Little Work (contd) zCaches 64KB chunks of files zFetch only mode zModifications sent back to primary file server zConflicts stored separately and user notified zMichigan, [25,26]

39. 2/24/98ICDE/SMU - Dunham38 Seer zFicus zUses semantic information to determine contents of cache. zSemantic distance between files measured in number of file accesses on average between two files. zAccess is defined as open-close. zDistance measure used to cluster files. Fetching of a cluster based on user hints and LRU information. zUCLA, [24,30]

40. 2/24/98ICDE/SMU - Dunham39 Summary Table 3.1 from [15]

41. 2/24/98ICDE/SMU - Dunham40 Sleepers and Workaholics zCache invalidation report zPeriodically (synchronous) the server broadcasts report of changed data. zMU waits for next report prior to answering query. zSleepers - frequently disconnected; cache invalidation based on signatures. zWorkaholics - rarely disconnected; periodic broadcast of changes. zFalse Invalidation zMITL and Rutgers, [21]

42. 2/24/98ICDE/SMU - Dunham41 Transparent Analytic Spying zFile Working Sets zContinually observe and record (in a log) file access. At hoard time, reference the log to determine hoard. zTrees for a process are created reflecting file access pattern. One tree per program execution is generated. A BC DE F Access Tree

43. 2/24/98ICDE/SMU - Dunham42 Transparent Analytic Spying (contd) zHoard all files or only those in in the most recent execution. zTracing adds about 2% CPU overhead. Average space for file log record is 100 bytes. zImplemented on Unix, NFS, Mach zCache miss rate over wireless slightly higher than on wired. zPrefetching overall reduced cache misses and elapsed time zColumbia, [36]

44. 2/24/98ICDE/SMU - Dunham43 Predictive File Caching zAnalyze file access patterns in different environments: Personal productivity, Programming, Commercial zWorking Set Statistics: Mean working-set sizes small (18MB per day) zAttention Shift Statistics: 0.6 per user per week zConflict Statistics: Depends on environment zConclusion: yHoarding is possible due to small working set size yLRU caching insufficient zUCLA, [31]

45. 2/24/98ICDE/SMU - Dunham44 Virtual Primary Copy zMobile Primary Copy (MPC) at MU zVirtual Primary Copy (VPC) at BS zGlobal transactions access VPC zConsistency of VPC maintained by BS zBS monitors MU disconnect zMultilayered approach is transparent to other sites zMonash, [23]

46. 2/24/98ICDE/SMU - Dunham45 Roam zMC Replication System zMU Peer to Peer communication allowed zWard Model: yWard: Grouping of replicas for locations that frequently communicate yWard Set: Set of replicated data stored in a ward. yWard Master: Doorway into ward. Maintains consistency between wards.

47. 2/24/98ICDE/SMU - Dunham46 Roam (contd) zWard members are close zNo pre-motion operations zIntra-ward synchronization easier than inter- ward zReconciliation- Synchronization process zSelective replication at file level zScales well zUCLA, [33]

48. 2/24/98ICDE/SMU - Dunham47 Semantic Cache zCaching granularity at a predicate level zSPJ query - Materialized view zAdvantages: reduces network overhead, reduces cache space zDisadvantages: Indexing, query trimming zSemantic Cache - C = {Si} zSemantic Segment - Si= zSMU

49. 2/24/98ICDE/SMU - Dunham48 Outline zIntroduction & Data Management Issues zQuery Processing zCaching 4Data Broadcasting Overview Indexing Research zTransaction Processing zAgents zProjects & Products zConclusion

50. 2/24/98ICDE/SMU - Dunham49 Data Broadcasting zServer continually broadcasts data to MUs. zScalability: Cost does not depend on number of users listening. zMobile Unit may/may not have cache. zFacilitates data access during disconnected periods. zAllows location dependent data access. zNo need to predict with 100% accuracy the future data needs. zBroadcast based on probability of access. zPeriodic broadcasting of all data.

51. 2/24/98ICDE/SMU - Dunham50 Data Broadcasting (contd) zClassification: yCoverage - Everything, Subset yContent - Static, Dynamic yIndices - Index, Self Descriptive yData Stream - Flat, Skewed, Multiple Disks yClient - Passive, Active zFor uniform page access, flat disk has best expected performance. zWith skewed page access, nonflat disks are better. zPush based.

52. 2/24/98ICDE/SMU - Dunham51 Broadcast Disks zSimulate multiple disks of varying sizes and speeds. Data of higher interest on smaller faster disks (broadcast more frequently). zEach disk contains data with similar access behavior. zCombination of caching and broadcast disks. Figure 4.1 from [15]

53. 2/24/98ICDE/SMU - Dunham52 Broadcast Disks (contd) zDont want to store hottest pages. They may be broadcast frequently. zStore in cache if probability of access (P) is greater than the frequency of broadcast (X). zCost based page replacement. zReplace cache page with smallest P/X - PIX. Too expensive to implement. zLIX - PIX approximation. Works well particularly with noise. zBrown, MITL, Maryland, [37,38,39]

54. 2/24/98ICDE/SMU - Dunham53 Air-Cache zDynamic - Adapts to system workload. zDefine temperature of data: yVapor (Steamy) Hot - Accessed frequently and broadcast. yLiquid Warm - Accessed often, not broadcast, but kept in servers main memory. yFrigid (Icy) Cold - Accessed infrequently and stored on secondary storage.

55. 2/24/98ICDE/SMU - Dunham54 Air-Cache (contd) zThree level memory hierarchy based on temperature. zSparks (access) to data can increase temperature. No sparks, results in a reduction of temperature. zSimulation results predict very good performance. zMaryland, [43]

56. 2/24/98ICDE/SMU - Dunham55 Adaptive Protocols zDynamically modify broadcast contents. zConstant Broadcast Size (CBS) Server Protocol: yLimited size and periodic yPriority yPopularity Factor (PF) yIgnore Factore (IF) zVariable Broadcst Size (VBS) Server Protocol: yAperiodic yAll data above threshold PF included. zArizona and UMKC, [40]

57. 2/24/98ICDE/SMU - Dunham56 Outline zIntroduction & Data Management Issues zQuery Processing zCaching 4Data Broadcasting Transaction Processing Overview Transaction Model Concurrency Recovery Research zAgents zProjects & Products zConclusion

58. 2/24/98ICDE/SMU - Dunham57 Mobile Transaction (MT) zDatabase transaction requested from a MU. May execute in FN or MU zIssues xDisconnect/Handoff xMobility xLocation Dependent Data xError Prone xMU Resources/ Power xRecovery/Restart xManagement

59. 2/24/98ICDE/SMU - Dunham58 MT Requirements zKeep autonomy of local DBMS zLLT zInteractive zAdvanced transaction models yNested yMultidatabase zRequest from MU zExecute anywhere zCapture movement zACID (?)

60. 2/24/98ICDE/SMU - Dunham59 MT Approaches zNo consensus on accepted approach zMU may not have primary copy of data [45]: yTransaction Proxy: MU does no transaction processing yRead Only Transaction: MU only reads data yWeak Transaction: Read and update cached data; Must synchronize updates with primary copy on FN. zMU may have primary copy of data zMU may access data on other MUs zFirst class and second class transactions

61. 2/24/98ICDE/SMU - Dunham60 MT Recovery zTransaction, site, media, network failure - More frequent than in wired network. zDifferent types of failures (partial) yHandoff yVoluntary disconnection yBattery problems yLose computer?? zCheckpoint data at MU to BS zCheckpoint at handoff zDatabase log plus transaction log zMay need compensating transactions

62. 2/24/98ICDE/SMU - Dunham61 Atomicity for MT zWeaken or provide different types of atomicity zMay decompose transaction into subtransactions zMay require atomicity at lower than transaction level zAtomic commitment difficult (expensive) zGlobal commit/Local Commit

63. 2/24/98ICDE/SMU - Dunham62 Consistency for MT zWeakening isolation and atomicity may weaken this as well. zMay divide data into clusters with consistency within clusters. zReintegration of updates after reconnect may cause many conflicts. zMay use bounded inconsistency. zImpacted by location dependent data

64. 2/24/98ICDE/SMU - Dunham63 Isolation for MT zMay be too restrictive zCant always do at MU (disconnection) zIsolation at lower levels in transaction zCommitment at different levels of transaction zCooperating transactions

65. 2/24/98ICDE/SMU - Dunham64 Durability for MT zDurability for partial results zMay want durability for parts of transactions. zDue to conflicts at reconnect, even durability of subtransactions may not be guaranteed. zLocal commit vs.. Global commit

66. 2/24/98ICDE/SMU - Dunham65 MT Concurrency Control zMobility of MUs may increase message traffic for lock management zMU failure may leave some data locked /unlocked 6) T1: Unlock(Xa); Commit; Server A Cell A Xa Ya Server B Cell B Xb Yb Server C Cell C Xc Yc Zc 1) T1: Lock(Xa); Read(Xa) 2) T1 moves to B 3) T1: Lock(Yb); Read(Yb) 4) T1 moves to C 5) T1: Lock(Zc); Write(Zc); Unlock(Zc); Commit 6) T1: Unlock(Yb); Commit; Fig 2 from [48]

67. 2/24/98ICDE/SMU - Dunham66 Revised Optimistic Locking zO2PL-MT zRead locks may be executed at multiple servers. zRead unlock can be executed at any site zBenefit shown using analytic model zPurdue, [48] Figure 3 from [48]

68. 2/24/98ICDE/SMU - Dunham67 Kangaroo Transaction (KT) zBuilt on top of global transactions zCaptures data and movement behavior zDAA as BS - Maintains logging and transaction status zLogging at BS zFlexible atomicity zRestart after disconnect zManagement moves

69. 2/24/98ICDE/SMU - Dunham68 Kangaroo Transaction (contd) zLocal Transaction - Sequence of read and write operations ending in commit or abort zGlobal Transaction - Sequence of global or local transactions zJoey Transaction - Sequence of global and local transactions ending in commit, abort, or split zKangaroo Transaction - Sequence of one or more Joeys with last one ending in commit or abort. All earlier end in split zSMU, [47]

70. 2/24/98ICDE/SMU - Dunham69 KT and Movement

71. 2/24/98ICDE/SMU - Dunham70 Reporting and Co-Transactions zMobile transaction is a special type of multidatabase transactions. zGDMS exists at each base station. zSubtransactions of the mobile transaction will commit or abort independently. zAtomic and non-compensatable transactions. zReporting and co-transactions. zPittsburgh, [46]

72. 2/24/98ICDE/SMU - Dunham71 Clustering Model zViews mobile transaction as beginning on mobile and nonmobile hosts. zTransaction migration zTransaction model is designed to maintain consistency of the database. zDatabase is divided into clusters. zData is divided into core and quasi copies. zMobile transactions and operations are decomposed into a set of weak and strict transactions.

73. 2/24/98ICDE/SMU - Dunham72 Clustering Model (contd) zWeak operations access only data in the same cluster. Strict operations allowed database wide access. Two copies of data can be maintained (strict and weak). zClusters defined based on location and user profile. zTransaction Proxy: dual transaction of one executed at mobile host which includes only the updates. zPurdue, [51,52]

74. 2/24/98ICDE/SMU - Dunham73 Mobile Transactions and Ambulatory Care zMedical Personal Digital Assistant (MPDA) zBattlefield - Cache copy of soldiers medical records in MPDA zDistributed Medical Database - EMT obtains patients medical record and updates. zBSA (Base Station Agent) is responsible for logging and recovery. zRecovery based on sagas with save-points. zMailboxes used to save information. zPurdue, [49,50]

75. 2/24/98ICDE/SMU - Dunham74 Semantics-Based Mobile Transaction Processing zViews mobile transaction processing as a concurrency and cache coherency problem. zA stationary database server dishes out the fragments of an object on a request from a Mobile Unit. zOn completion of the transaction, the Mobile Units return the fragments to the server. zThese fragments are put together again by the merge operation at the server. zPittsburgh, [54]

76. 2/24/98ICDE/SMU - Dunham75 Multidatabase Transaction Processing Manager zMobile transactions built on top of multidatabase global transactions. zTimestamps used to enforce ordering zAllows voluntary disconnections. zMU part of MDS zMessage Queuing Facility (MQF) zMU sends request to designated coordinating node on FN. zMonash, [56]

77. 2/24/98ICDE/SMU - Dunham76 PRO-MOTION zMC/Database Transaction Processing approach zMultiple transaction types yControlled divergence yACID yUpdate cache and later DB at FH zCompact - Compact Agent at MU, Mobility Manager at BS, Compact Manager at Server zPittsburgh, [55]

78. 2/24/98ICDE/SMU - Dunham77 MT Research Limitations zArchitectural Assumptions zNo support for location dependent data zFew Implementations

79. 2/24/98ICDE/SMU - Dunham78 MT Management Options zMU zBS zCombination zFixed/Relocatable/Moving zAgent

80. 2/24/98ICDE/SMU - Dunham79 Outline zIntroduction & Data Management Issues zQuery Processing zCaching zData Broadcasting zTransaction Processing 4Agents Overview Client-Agent-Server Model Mobile Agent zProjects & Products zConclusion

81. 2/24/98ICDE/SMU - Dunham80 Agent zApplication dispatched by and working for the client. zAgent: ySolves disconnect problem ySolves slow bandwidth problem zClient-Agent-Server zAgent Classification: zType - Client,Server,Application,User xMovement - Static, Relocatable, Migrating (Mobile) xNumber - Single, Multiple, Clonable ClientServerClientAgentServer

82. 2/24/98ICDE/SMU - Dunham81 Itinerant Agent (Mobile Agent) zProgram dispatched from mobile unit that roams through the fixed network to satisfy clients data request. zAt a server the agent is sent to an Agent Meeting Point (AMP) where desired server functions are determined and requested. zClient, Migrating, Single zIBM, [58]

83. 2/24/98ICDE/SMU - Dunham82 Migrating User Agent zUser process that mimics MU. zProcess migrates as user moves. zClient, Migrating, Single zMassachusetts, AT&T, [63]

84. 2/24/98ICDE/SMU - Dunham83 Remote Programming zLanguage for communication required. zUser and server communication without using network. zPlaces - Meeting points for agents and servers zAgents - Application is set of agents. Agent is either at a place or travelling between places. zTravel - Go instruction zMeetings - Agents communicating at a place. zGeneral Magic Telescript, [59]

85. 2/24/98ICDE/SMU - Dunham84 Concordia zMitsubishi Electra ITA zJava Objects; JDBC zCollaborating Agents zAgent Server - FN zUser Agent - MU to BS zQuery Agents- BS to Server zCollaborator - BS zMitsubishi Electric ITA, [60,61] Adapted from Fig 6 in [61] User Agent Query Agent Query Agent Collaboration Oracle Server Notes Server Concordia

86. 2/24/98ICDE/SMU - Dunham85 Outline zIntroduction & Data Management Issues zQuery Processing zCaching zData Broadcasting zTransaction Processing zAgents 4Projects & Products zConclusion

87. 2/24/98ICDE/SMU - Dunham86 Some DB/MC Projects URLs zMobiDick - Monash Univ. (Australia); http://www.ct.monash.edu.au/~mobidick zMobisaic - Univ. of Washington; http://www.cs.washington.edu/homes/voelker/mobisaic zPurdue; http://www.cs.purdue.edu/research/cse/mobile zSMU; http://www.seas.smu.edu/~mhd/mobile.html zMCC - Collaboration Managment Infrastructure; http://www.mcc.com/projects/transaction zUniversity of Ioanina; http://zeus.cs.uoi.gr/ zMichigan - CITI; http://www.citi.umich.edu/projects/mobile.html zUCLA - Ficus; http://ficus-www.cs.ucla.edu/ficus zColumbia; http://www.mcl.cs.columbia.edu

88. 2/24/98ICDE/SMU - Dunham87 Rover zFigure 6.1 from [15]

89. 2/24/98ICDE/SMU - Dunham88 Oracle Mobile Agent zCommercial Product zApplication, Static, Multiple zMessage Manager - MU zMessage Gateway - BS zAgent - FN (Server) z[67,69] Message Manager Gateway Corporate Network Agent Database Server

90. 2/24/98ICDE/SMU - Dunham89 Sybase - SQL Anywhere zDesigned for Windows, (95, 3.x, NT), OS/2, DOS zLimited memory requirements zFull TP capabilities zIncludes SQL Remote zCompatible with Sybase SQL Server z[68] Remote Database SQL Anywhere standalone engine Message agent Consolidated Database SQL Anywhere network server Message agent

91. 2/24/98ICDE/SMU - Dunham90 Sybase (contd) - SQL Remote zTwo way replication based on message passing. zRemote database are synchronized with consolidated DB zMessage Agent required at DB server zReplication of subscribed fragments zPeriodic changes sent from consolidated DB to remote DBs zUpdates from committed transactions at remote submitted to consolidated database. zConflicts: Consolidated is master; Triggers used. Consolidat ed DB Remote Databases

92. 2/24/98ICDE/SMU - Dunham91 Informix zI-Mobile 1.0 discontinued: yNo replication yThree tier approach appropriate for long term, but in the short term users wanted to be able to use existing client-server applications (not rewrite). ySmall DBMS server to run on mobile client yOnly dial up needed for now zInformix Dynamic Server/Personal Edition (IDS/PE) for Windows 95/NT. Mobiles and desktop clients z[64,66]

93. 2/24/98ICDE/SMU - Dunham92 Outline zIntroduction & Data Management Issues zQuery Processing zCaching zData Broadcasting zTransaction Processing zAgents zProducts 4Conclusion

94. 2/24/98ICDE/SMU - Dunham93 Future zCombine different approaches zSemantic caching zQuery Optimization zAdaptive Data Broadcasting zPerformance Benchmarks zSecurity zLocation Dependent Queries

95. 2/24/98ICDE/SMU - Dunham94 Acknowledgements and URL Bibliographies zEarlier version of this tutorial presented at the 1996 Brazilian Database Symposium. zWe particularly want to thank Evaggelia Pitoura for providing several tables and figures from her recent book [15]. zSome slide information obtained from slides presented at a database class at the University of Massachusetts, http://www-ccs.cs.umass.edu/mobile. zOnline bibliographies yhttp://www.seas.smu.edu/~mhd/mobile.html yhttp://www.ct.monash.edu.au/~mobidick