Post on 19-Dec-2015
Object Eventing Service
Michael Boyle and Michael Rounding
Today’s Presentation…
Project objectives, motivationDesign conceptsHypothetical Walk-through Application Example: IM
Objectives
Design a shared dictionary/notification service architectureEmphasis on flexibility, programmabilityPersistency of shared distributed objectsSimplicity 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 systemE-mail, IM, other groupware
Motivation
Lack of existing toolkitsDeficiencies in existing toolkitsLearning opportunity
Design Topics
TreeSubscriptionsNotificationsUPLs, BlockadesSubscription PoolsQualities of service
OES Tree
Hierarchy of named nodesLike a file systemGlobal namespaceNodes have values and childrenValues are arbitrary binary data
Hypothetical tree showing logons
Hypothetical tree showing logons
root mikey logons name value
workstation1
workstation2
home_pc
136.159.7.220
136.159.7.220
136.159.7.220
Subscriptions
Says what sub-tree to watch for changesSays how far down the tree to watch for changesLeased by clientsGrouped into contracts
Mikey: changes <= 2
levels
Notifications
Generated on every actionSubscriptions evaluated up the hierarchyStart at modified nodeOne delivery per action per contract
Value change
d!
I’ll let my subscribers know and pass
it on.
I’ll let my subscribers know and pass
it on.
Sure is quiet
today…
Barricades and UPLs
Barricades explicitly block notification passingUpward propagation limit
Says how far up the tree to process subscriptions
No more subscriptions processed
Value change
d!
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 subscriber
s know, but it goes no further!
Subscription Pools
Arbitrarily re-route subscription processingNon-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.
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 tablesWire protocol
Database Tables
SubscriptionPoolBarricadeQoSUpl
ContentNodenameParent_NodeidNodeid
NODE Table
QoSExpiry
ConnectinfoContractid
CONTRACT Table
Last notif. infoQoS
DepthNodeidContractid
SUBSCRIPTION Table
Wire Protocol
Based on HTTPRequest-responseSmall vocabularyXML content bodiesExtensible, portable
An Application In Depth
Instant Messaging Buddy list On-line presence status Instant inboxes for exchanging
messages Group on-line presence awareness
Hypothetical TreePeople
boylem
Status: Online
Instant Inboxes
rounding
saul
boylem
saul
Status: Idle
Instant Inboxes
Groups
GroupLab
StatusSubscriptio
nPool
IMRoot
rounding
Status: offline
When boylem’s Client Starts…
1. Set boylem\Status
2. Lease contract3. List Instant
Inboxes1. For each, place a
subscription on that person’s Status
2. Reflect state in UI
boylem
Status: online
Instant Inboxes
rounding
saul
Status: Idle
roundingSubscribe:
boylem
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
saulSubscribe:
boylem
Groups
GroupLab
StatusSubscriptio
nPool
Subscribe: boylem
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!”
When rounding IMs boylem
4. New window5. Subscribe to
boylem\…\rounding
Mike Boyle Says:
Mike Rounding Says:
Monkey!
Mike Boyle
Subscribe from
boylem to rounding
If rounding’s status changes
1. Set rounding\Status
2. Sub. pool to GroupLab\Status
3. Notify boylem4. Reflect in UI
Groups GroupLab
StatusSubscriptio
nPool
rounding\status: idlerounding\status: online
boylem
Mike Boyle
Contacts:
Mike Rounding
Saul Greenberg
What this example showed
SubscriptionsNotificationsSubscription pools
What wasn’t shown
Upward propagation limitsBarricades/blockadesSubscription depths
These provided to prevent server from being swamped processing
subscriptions!
Challenges Not Yet Faced
ImplementationScalabilityRobustnessPerformanceSecurityTransactionality
Summary
Goals: flexibility, generalityConcepts: tree, subscriptions, notificationsAdvantages: haven’t cornered ourselvesGood ideas: based on robust platformOutlook: needs implementation
Thanks…