1. Object Eventing Service Michael Boyle and Michael Rounding

2. Today’s Presentation… Project objectives, motivation Design concepts Hypothetical Walk-through Application Example: IM

3. Objectives Design a shared dictionary/notification service architecture Emphasis on flexibility, programmability Persistency of shared distributed objects Simplicity of notification service

4. 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

5. Motivation Lack of existing toolkits Deficiencies in existing toolkits Learning opportunity

6. Design Topics Tree Subscriptions Notifications UPLs, Blockades Subscription Pools Qualities of service

7. OES Tree Hierarchy of named nodes Like a file system Global namespace Nodes have values and children Values are arbitrary binary data Hypothetical tree showing logons rootmikeylogonsnamevalue workstation1 workstation2 home_pc 136.159.7.220

8. Subscriptions Says what sub-tree to watch for changes Says how far down the tree to watch for changes Leased by clients Grouped into contracts Mikey: changes <= 2 levels

9. Notifications Generated on every action Subscriptions evaluated up the hierarchy Start at modified node One delivery per action per contract Value changed! I’ll let my subscribers know and pass it on. Sure is quiet today…

10. Barricades and UPLs 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 pass it on. Change! Pass it twice, please. I’ll let my subscribers know and pass it once… I’ll let my subscribers know and that’s it. I’ll let my subscribers know, but it goes no further!

11. Subscription Pools Arbitrarily re-route subscription processing Non-hierarchical subscription topologies “A common meeting point” We subscribers need to know about the same set of information As a subscription pool, I can track a specific, custom set of notifications.

12. 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

13. Implementation Preliminaries Database tables Wire protocol

14. Database Tables SubscriptionPoolBarricadeQoSUpl ContentNodenameParent_NodeidNodeid NODE Table QoSExpiry ConnectinfoContractid CONTRACT Table Last notif. infoQoS DepthNodeidContractid SUBSCRIPTION Table

15. Wire Protocol Based on HTTP Request-response Small vocabulary XML content bodies Extensible, portable

16. An Application In Depth Instant Messaging Buddy list On-line presence status Instant inboxes for exchanging messages Group on-line presence awareness

17. Hypothetical Tree People boylem Status: Online Instant Inboxes rounding saul boylem saul Status: Idle Instant Inboxes Groups GroupLab Status Subscription Pool IMRoot rounding

18. Status: offline When boylem’s Client Starts… 1. Set boylem\Status 2. Lease contract 3. List Instant Inboxes 1. For each, place a subscription on that person’s Status 2. Reflect state in UI boylem Status: online Instant Inboxes rounding saul Status: Idle rounding Subscribe: boylem

19. When boylem’s Client Starts 4. Subscribe boylem\Instant Inboxes subtree 5. Subscription pool to \Groups\ GroupLab\ Status 6. Subscribe \Groups\ GroupLab\ Status boylem Status: online Instant Inboxes rounding saul Subscribe: boylem Groups GroupLab Status Subscription Pool Subscribe: boylem

20. When rounding IMs boylem… 1. Post to boylem\Instant Inboxes\rounding 2. Guaranteed notification generation 3. Subscription on boylem\Instant Inboxes triggers UI boylem Status: online Instant Inboxes rounding saul rounding says: “Monkey!”

21. When rounding IMs boylem 4. New window 5. Subscribe to boylem\… \rounding Mike Boyle Says: Mike Rounding Says: Monkey!Mike Boyle Subscribe from boylem to rounding

22. If rounding’s status changes 1. Set rounding\Status 2. Sub. pool to GroupLab\Status 3. Notify boylem 4. Reflect in UI Groups GroupLab Status Subscription Pool rounding\status: idlerounding\status: online boylem Mike Boyle Contacts: Mike Rounding Saul Greenberg

23. What this example showed Subscriptions Notifications Subscription pools

24. What wasn’t shown Upward propagation limits Barricades/blockades Subscription depths These provided to prevent server from being swamped processing subscriptions!

25. Why have UPLs, Barricades? NC-style application Board not interested when some properties of items change Only when items added/removed

26. Challenges Not Yet Faced Implementation Scalability Robustness Performance Security Transactionality

27. Summary Goals: flexibility, generality Concepts: tree, subscriptions, notifications Advantages: haven’t cornered ourselves Good ideas: based on robust platform Outlook: needs implementation

28. Thanks…