1. Requirements for Internet Scale Event Notifications David Rosenblum UC Irvine Surendra Reddy Oracle

2. Questions u What are the minimum requirements a technology must satisfy to qualify as an event notification service? –Does any kind of IPC qualify? u Can we define the event notification service for the Internet, or do we need several specialized services? –If the latter, then support for inter-service communication is needed

3. Core Requirements (I) u A separate service, available anywhere on the Internet u A programmatic interface u Notification subscription u Content-based subscription u Asynchronous notification delivery u Reliable notification delivery

4. Core Requirements (II) u Authenticated notifications u Decentralized/networked architecture u Anonymity of publishers & subscribers u Compatible with existing firewalls u Selectivity –All interested parties receive notifications –Only interested parties receive notifications

5. Core Requirements: Discussion u Protocol definition –(invisible) standard protocols vs. (visible) proprietary APIs u Decoupling of publishers & subscribers –But not necessarily anonymity u Subscriber for notification can be different from recipient

6. Core Requirements: Discussion u Persistence of notifications –Impact of Internet scale on persistence –Built into service? –Provided by service users through callbacks? u Standard terminology u Discoverability of quality of service u Extensibility of service features

7. Domain-Specific Requirements: Internet Printing u Multiple “channels” or classes of notifications u Grouping/patterns of events (“job done” vs. “page 3 done”) u Support for “large” numbers of clients u Multiple notification methods (email, programmatic, log files, etc.) u Eliminate redundancy—treat print requests as subscriptions

8. Domain-Specific Requirements: Satellite Services u 10 8 -10 9 events per day u Wide-area notification, at least continental US u Timely delivery (on the order of seconds), but not necessarily reliable u Aggregation of notifications

9. Domain-Specific Requirements: Financial Services u 1000 notifications to 5-10,000 workstations per second u Historical notification storage and matching u Reliable multicast

10. Domain-Specific Requirements: Discussion u Single service vs. single protocol w/multiple infrastructures vs. multiple protocols u Variation in (cost of satisfying) different quality of service requirements may result in multiple services –All providers agree on base level of QoS but can advertise additional capabilities

11. Domain-Specific Requirements: Discussion u Incompatibility between QoS requirements may result in multiple services –Example: notification delivery semantics »Idempotence vs. at-least-once vs. at-most- once vs. exactly-once

12. Other Issues: Discussion u Defining “minimal requirements” may result in multiple, domain-specific services u Notification schema –Message format, minimal information, fixed or variable media types, … –Reconciling users’ and providers’ view of the schema u Notification ordering