Personal Activity Coordinator (PAC)

1
Personal Activity Coordinator (PAC)

• Xia Hong
• UC Berkeley
• xiahong_at_cs.berkeley.edu
• ISRG retreat 1/11/2000

2
Outline

• Motivation
• Design Goals
• Prototype Scenario
• PAC Overview
• Evaluation
• Future Work

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
• Whats missing?
• Intelligent coordination among services

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

• 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
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
Prototype Scenario
Route Calculation
Email Client
Calendar on PDA
Email with an appointment attached
Calendar Service
Reminder Service
Email Service
PAC
Reminder message delivered to the pager
Navigation information delivered to the car
Traffic information
8
Global View of PAC

• Hierarchical domain-based PAC organization
• Personalized PAC
• Name mapping scheme -- similar to DNS

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
OneExample
ltXMLgt ltFIELDgt ltNAMEgtSUMMARYlt/NAMEgt
ltDESCRIPTIONgtTHE TITLE OF THE CALENDAR
EVENTlt/DESCRIPTIONgt ltTYPEgtSTRINGlt/TYPEgt
ltENFORCEMENTgtOPTIONALlt/ENFORCEMENTgt lt/FIELDgt
ltFIELDgt ltNAMEgtDTSTARTlt/NAMEgt
ltDESCRIPTIONgtTHE STARTING TIME OF THE CALENDAR
EVENTlt/DESCRIPTIONgt ltTYPEgtDATElt/TYPEgt
ltENFORCEMENTgtREQUIREDlt/ENFORCEMENTgt lt/FIELDgt
ltFIELDgt ltNAMEgtDTENDlt/NAMEgt
ltDESCRIPTIONgt THE ENDING TIME OF THE CALENDAR
EVENTlt/DESCRIPTIONgt ltTYPEgtDATElt/TYPEgt
ltENFORCEMENTgtREQUIREDlt/ENFORCEMENTgt lt/FIELDgt
ltFIELDgt ltNAMEgtLOCATIONlt/NAMEgt
ltDESCRIPTIONgtTHE LOCATION OF THE CALENDAR
EVENTlt/DESCRIPTIONgt ltTYPEgtSTRINGlt/TYPEgt
ltENFORCEMENTgtREQUIREDlt/ENFORCEMENTgt lt/FIELDgt
ltFIELDgt ltNAMEgtCATEGORIESlt/NAMEgt
ltDESCRIPTIONgtTHE CATEGORY THAT THE CALENDAR EVENT
BELONGSlt/DESCRIPTIONgt ltTYPEgtSTRINGlt/TYPEgt
ltENFORCEMENTgtREQUIREDlt/ENFORCEMENTgt
ltVALUESgtAPPOINTMENT, BUSINESS, MEETING, PERSONAL,
MISCELLANEOUSlt/VALUESgt lt/FIELDgt ltFIELDgt
ltNAMEgtDESCRIPTIONlt/NAMEgt ltDESCRIPTIONgtTHE
DESCRIPTION OF THE CALENDAR EVENTlt/DESCRIPTIONgt
ltTYPEgtSTRINGlt/TYPEgt ltENFORCEMENTgtOPTIONALlt
/ENFORCEMENTgt lt/FIELDgt lt/XMLgt
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
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
Putting it all together ...
root
subscriber 0
subscriber 1
subscriber 2
Name server
Subscriber server
Data Repository Contextual Information Server
Garbage collector thread
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
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