1. Relevant Systems Issues Motivation 1. A Group Calendar application available through web and partially disconnected portable information appliances will be a generally useful application 2. Explore building applications for information appliances and away from desktop (Post-PC) 3. Explore building scalable, highly available, fault tolerant apps (Ninja) or, building partially disconnected, highly available, fault-tolerant, and scalable groupware systems in a single semester What We Learned OSKI System Architecture Architecture 1. Three-tier system to access calendar data 2. User Service manages all user data and prefs 3. Sync Manager / Disconnected Cache Manager for partially disconnected devices 4. Virtual Calendars aggregate individual calendars and subscriptions 5. Notifications for new events, auto accept / deny 6. Access control lists for event visibility and access Design Goals 1. Highly available, fault-tolerant, scalable service 2. Scale for large number of users and wide area 3. Disconnected operation / eventually consistent 4. Work with existing software (desktop / Pilot) 5. Provide rich mechanism, minimal policy 6. vCalendar 1.0 Compliant Jason I. Hong Brad Morrey Mark Newman CS262 Operating Systems Fall 1998 Lack of Post-PC tools increases development complexity Separating system properties (e.g. high availability) from functionality simplifies design, saving time and effort Designing application interfaces is challenging Designing for extensibility and flexibility is very difficult Conforming to standards is very time-consuming Supporting legacy systems also very time-consuming Build one to throw away... Data Consistency Relaxed consistency for performance Data is cached in all the tiers, eventually consistent No direct access to database, remote data servers only Sync Service and Disconnected Cache Manager resolves data conflicts in infrastructure and info appliance. All conflict resolution policies implemented in Sync Service. Extensibility Each type of information appliance needs its own type of Disconnected Cache Manager Each information appliance has its own Disconnected Cache Manager on machines you sync on. Disconnected Cache Manager is point-of-entry into system for devices. Future User Authentication High Availability, Fault-Tolerance, and Scalability Disconnected Cache Managers for New Devices Initial deployment of system here at UC Berkeley OSKI - Open Shared Kalendaring Infrastructure User Service Users Database Calendar Service Calendars Database Java Applet Sync Service Disconnected Cache Manager (Pilot) Disconnected Cache Manager (WinCE) Virtual Calendar User Service Users Database Calendar Service Calendars Database 1 Virtual Calendar created from: All calendars owned by user New events in subscriptions All existing event notifications Ask a User Service where a user’s home calendar is located. If needed, redirect query like DNS or LDAP. 2 3 Ask a Calendar Service for a user’s calendar. 1 HotSync is initiated 2 Disconnected Cache Manager is the bridge between device and infrastructure. Converts device date format to OSKI format and detects changes. 3 Sync Service handles conflict resolution logic. Virtual Calendar 4 Virtual Calendar generated same as above. Differences between the infrastructure and device are resolved. Disconnected Cache Manager (Toaster) Disconnected Cache Manager (Barney) Connected Access to OSKI Disconnected Access to OSKI Hot Sync User Service Users Database Calendar Service Calendars Database Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Calendars Database Calendar Service Sync Service Java Applet OR Tier 2 Data Objects Tier 3 Database Clients Tier 1 Application Objects Disconnected Devices vCalendar Compliant Calendar App User (Remote) User (Local) NinjaRMI Hot Sync Virtual Calendar (Remote) Virtual Calendar (Local) NinjaRMI