Relevant Systems Issues

1. OSKI - Open Shared Kalendaring Infrastructure User Service Users Database Users Database Calendar Service Calendars Database Sync Service User Service Users Database Calendars Database Calendar Service Calendars Database Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Calendar Data Object Sync Service Java Applet Calendars Database Hot Sync Hot Sync Hot Sync Hot Sync Hot Sync Jason I. Hong Brad Morrey Mark Newman CS262 Operating Systems Fall 1998 or, building partially disconnected, highly available, fault-tolerant, and scalable groupware systems in a single semester Motivation Relevant Systems Issues 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) • 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 System Architecture 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 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 Tier 1 Application Objects Tier 2 Data Objects Tier 3 Database Ask a User Service where a user’s home calendar is located. If needed, redirect query like DNS or LDAP. Connected Access to OSKI User Service 1 Ask a Calendar Service for a user’s calendar. 2 User (Local) User (Remote) • Virtual Calendar created from: • All calendars owned by user • New events in subscriptions • All existing event notifications Clients NinjaRMI 3 Java Applet What We Learned VirtualCalendar Calendar Service Disconnected Access to OSKI • 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... 1 HotSync is initiated Disconnected Cache Manager (Pilot) Disconnected Cache Manager is the bridge between device and infrastructure. Converts device date format to OSKI format and detects changes. 2 OR Virtual Calendar (Local) Virtual Calendar (Remote) Disconnected Cache Manager (Toaster) NinjaRMI Sync Service handles conflict resolution logic. 3 Disconnected Cache Manager (Barney) Disconnected Devices VirtualCalendar vCalendar Compliant Calendar App Calendar Service Disconnected Cache Manager (WinCE) Virtual Calendar generated same as above. Differences between the infrastructure and device are resolved. 4