1. 1 Personal Activity Coordinator (PAC) Xia Hong UC Berkeley xiahong@cs.berkeley.edu ISRG retreat 1/11/2000

2. 2 Outline Motivation Design Goals Prototype Scenario PAC Overview Evaluation Future Work

3. 3 Motivation Increasing demand of Internet-based personal services –Email, Calendar, Banking, Stock-trading, etc. Information sharing among services is important –Spatial data: geo-location, active devices, traffic conditions, etc. –Temporal data: calendar information –Application: ICEBERG project Ninja: an ideal platform for deploying Internet-based services What’s missing? –Intelligent coordination among services

4. 4 Service Delivery Architecture Overview NewsReader Calendar Email Commute Advisory Etc. Ninja Base Internet Mobile Customers TCP WAP PDA Cell Phone On-board computing system Desktop PC Active Proxy NinjaRMI Service Coordination Layer (PAC)

5. 5 PAC Overview Coordination Layer (PAC) EmailCalendarNews Reader Commute Advisory Context Providers Context Consumers Global ViewLogical View Coordination Layer (PAC) Sharing contextual information among services –tracks past, current and future activities of the user Common API for services to deliver and retrieve contextual information

6. 6 Design Goals Managing and utilizing contextual information –Database repository –Publish contextual information –Wide area consideration Uncoupling of context providers and consumers –Anonymous communication –Uniform APIs Extensibility –Flexible data schemas Scalability, availability and fault tolerance –Leverage Ninja property Security and privacy

7. 7 Prototype Scenario PAC Email Service Calendar ServiceReminder Service Ê · Calendar on PDA Email Client Route Calculation Traffic information Email with an appointment attached Navigation information delivered to the car Reminder message delivered to the pager ¸ ¹ º » ¼ ½ ¾ ¿ 11 12

8. 8 Global View of PAC Hierarchical domain-based PAC organization –Personalized PAC –Name mapping scheme -- similar to DNS location GPSIP addressMailing address new appointments FaxEmail traffic trip time calendar locationperson root Classification of contextual information –Hierarchical category name space

9. 9 Global View of PAC cont. Schema definition and enforcement –Common schema structure for each category Schema definition file is provided in category basis –Schema definition file in XML format Similar to XML namespace Need for understanding semantics of contextual information –Schema checking Enforce on creation and updates of contextual information

10. 10 SUMMARY THE TITLE OF THE CALENDAR EVENT STRING OPTIONAL DTSTART THE STARTING TIME OF THE CALENDAR EVENT DATE REQUIRED DTEND THE ENDING TIME OF THE CALENDAR EVENT DATE REQUIRED LOCATION THE LOCATION OF THE CALENDAR EVENT STRING REQUIRED CATEGORIES THE CATEGORY THAT THE CALENDAR EVENT BELONGS STRING REQUIRED APPOINTMENT, BUSINESS, MEETING, PERSONAL, MISCELLANEOUS DESCRIPTION THE DESCRIPTION OF THE CALENDAR EVENT STRING OPTIONAL One Example:

11. 11 Internal View of PAC Repository database –Light-weight Simple query model (Index, And and Range queries) Relaxed ACID properties –Semi-structured Flexible data schema support across categories No integrity constraints checking –Distributed Soft-state replication Partitioning is preferable than replication –Solution XSet Database

12. 12 Internal View of PAC cont. Event driven model –Subscribe on category basis –Notification through NinjaRMI Authentication and access control –Separate access control list for read and write –Rules defined by the user through nice GUI –Public-key encryption scheme Garbage collector –Periodic refreshes on real-time changing data (e.g., location, traffic conditions, etc.)

13. 13 Putting it all together... root Name server subscriber 0 subscriber 1 subscriber 2 Subscriber server Data Repository: Contextual Information Server Garbage collector thread

14. 14 Evaluation Design Evaluation –Ease of use: 179 lines of Java codes to extend the ninja calendar service with the PAC functionality Performance Evaluation –Mainly due to XSet database and NinjaRMI calls

15. 15 Future Work Identifying the categories and schemas of collectable contextual information Utilization of the available contextual information –e.g., calendar events Need support from various service providers –e.g., GPS receiver service, in-car computing system Query-based notification mechanism Refined security model