Object Eventing Service

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…