270 likes | 472 Views
Object Eventing Service. Michael Boyle and Michael Rounding. Today’s Presentation…. Project objectives, motivation Design concepts Hypothetical Walk-through Application Example: IM. Objectives. Design a shared dictionary/notification service architecture
E N D
Object Eventing Service Michael Boyle and Michael Rounding
Today’s Presentation… • Project objectives, motivation • Design concepts • Hypothetical Walk-through • Application Example: IM
Objectives • Design a shared dictionary/notification service architecture • Emphasis on flexibility, programmability • Persistency of shared distributed objects • Simplicity of notification service
Proposed Applications • Real-time synchronous groupware • e.g., Tele-pointers — need speed! • Semi-synchronous groupware • e.g., NC — persistent state! • Generic file system • E-mail, IM, other groupware
Motivation • Lack of existing toolkits • Deficiencies in existing toolkits • Learning opportunity
Design Topics • Tree • Subscriptions • Notifications • UPLs, Blockades • Subscription Pools • Qualities of service
OES Tree root mikey logons name value workstation1 136.159.7.220 • Hierarchy of named nodes • Like a file system • Global namespace • Nodes have values and children • Values are arbitrary binary data workstation2 136.159.7.220 home_pc 136.159.7.220 Hypothetical tree showing logons
Subscriptions Mikey: changes <= 2 levels • Says what sub-tree to watch for changes • Says how far down the tree to watch for changes • Leased by clients • Grouped into contracts
Notifications • Generated on every action • Subscriptions evaluated up the hierarchy • Start at modified node • One delivery per action per contract I’ll let my subscribers know and pass it on. I’ll let my subscribers know and pass it on. Value changed! Sure is quiet today…
I’ll let my subscribers know, but it goes no further! Barricades and UPLs I’ll let my subscribers know and pass it on. • Barricades explicitly block notification passing • Upward propagation limit • Says how far up the tree to process subscriptions • No more subscriptions processed Value changed! I’ll let my subscribers know and that’s it. I’ll let my subscribers know and pass it once… Change! Pass it twice, please.
Subscription Pools • Arbitrarily re-route subscription processing • Non-hierarchical subscription topologies • “A common meeting point” As a subscription pool, I can track a specific, custom set of notifications. We subscribers need to know about the same set of information
Qualities of Service • Notification generation • Two puts but only notification for most recent • Notification delivery • Clients know of delivery failures • Notification receipt • Cache latest notification for partially disconnected clients
Implementation Preliminaries • Database tables • Wire protocol
NODE Table Nodeid Parent_Nodeid Nodename Content Upl QoS Barricade SubscriptionPool CONTRACT Table Contractid Connectinfo SUBSCRIPTION Table Expiry QoS Contractid Nodeid Depth QoS Last notif. info Database Tables
Wire Protocol • Based on HTTP • Request-response • Small vocabulary • XML content bodies • Extensible, portable
An Application In Depth • Instant Messaging • Buddy list • On-line presence status • Instant inboxes for exchanging messages • Group on-line presence awareness
Hypothetical Tree IMRoot People boylem Status: Online Instant Inboxes rounding saul rounding Status: Idle Instant Inboxes boylem saul Groups GroupLab Status Subscription Pool
When boylem’s Client Starts… • Set boylem\Status • Lease contract • List Instant Inboxes • For each, place a subscription on that person’s Status • Reflect state in UI boylem Status: offline Status: online Instant Inboxes rounding saul Subscribe: boylem rounding Status: Idle
When boylem’s Client Starts • Subscribe boylem\Instant Inboxes subtree • Subscription pool to \Groups\ GroupLab\ Status • Subscribe \Groups\ GroupLab\ Status boylem Status: online Instant Inboxes rounding Subscribe: boylem saul Groups GroupLab Status Subscription Pool Subscribe: boylem
When rounding IMs boylem… • Post to boylem\Instant Inboxes\rounding • Guaranteed notification generation • Subscription on boylem\Instant Inboxes triggers UI boylem rounding says: “Monkey!” Status: online Instant Inboxes rounding saul
Mike Boyle Mike Boyle Says: Mike Rounding Says: Monkey! Subscribe from boylem to rounding When rounding IMs boylem • New window • Subscribe to boylem\… \rounding
If rounding’s status changes • Set rounding\Status • Sub. pool to GroupLab\Status • Notify boylem • Reflect in UI rounding\status: idle rounding\status: online Groups GroupLab Status Subscription Pool boylem Mike Boyle Contacts: Mike Rounding Saul Greenberg
What this example showed • Subscriptions • Notifications • Subscription pools
What wasn’t shown • Upward propagation limits • Barricades/blockades • Subscription depths These provided to prevent server from being swamped processing subscriptions!
Challenges Not Yet Faced • Implementation • Scalability • Robustness • Performance • Security • Transactionality
Summary • Goals: flexibility, generality • Concepts: tree, subscriptions, notifications • Advantages: haven’t cornered ourselves • Good ideas: based on robust platform • Outlook: needs implementation