Design, Implementation and Evaluation of an Event Service by Kiran Anna Temitope Alo CDA 5937 Spring 2002

Roadmap Introduction Motivation Event Service Proposed Work –Objectives –Design criteria Background Literature

Introduction Increased Focus on complex distributed software systems that execute and interoperate over the Internet Why distributed software systems over internet?

Introduction contd. Distributed software systems –loosely coupled –heterogeneity –computing power Demand for suitable architecture styles and related run time infrastructures

Introduction Contd… Emerging middleware architecture –based on the notion of event –distributed software components interact by generating and consuming events –This paradigm supports a flexible and effective interaction among highly re- configurable distributed software components

Introduction Contd.. Event based architecture –The common infrastructure underlying event based systems is event service. –An event service is a facility that provides for observation and notification of events among the components. –Well developed for local area networks Broadcast mechanisms Vector clocks

Motivation Bond –Middleware infrastructure –Being developed to support applications to execute over the internet –Absence of mechanism to connect the distributed software components over the internet Lack of technologies to support event service at the scale of internet

Internet-Scale Event Service Components communicate by generating and receiving event notifications A component generates an event to inform the external world about a change in its internal state or in the state of other components with which it interacts

Internet-Scale Event Service Contd.. When an event notification is generated, it is propagated to any component that has declared interest in receiving it. The event generation and its propagation are performed asynchronously. Connector (Event Service) –In charge of managing the propagation of event notifications

Internet-Scale Event Service Contd. Publish events Event Service Component1 Component2 Component4 Component3 Subscribe events Notify events

Internet-Scale Event Service Contd. Subscribe events Event Service Component1 Component2 Safety Manager B Controller A Notify events Publish events Fire outbreak Someone in danger A – take actions on reception of fire alarm B – Call the rescue team

Proposed Work

Objectives Explore the existing design space of event based architecture Design an internet-scale event service which supports –Scalability –Well defined class of events, taxonomy and the notification structure –efficient delivery mechanism to the subscribers –Failure recovery

Approach to designing the ES System Start with a basic event model CREATOR Publishers Subscribers Rendezvous point EVENT SERVICE – Create Rendezvous Point 2 – Clients Subscribe 3 – Another Client Publishes 4 – Event Service notifies Subscriber

Approach to designing the ES System Event Service will include an abstraction(Rendezvous point) to which event publications are sent and to which subscribers make a request. A protocol will be designed for clients to subscribe to the Rendezvous point. A protocol will be designed for another client to publish an event to the Rendezvous point. The Event Service System will have another protocol that sends the event received from the publisher to the subscriber.

Design Criteria Subscription mechanism Mechanism that supports the selection of subscribers to be notified of events Structure of notification Consideration on event patterns using expressions over name and parameters e.g Alarm notification: Alarm(Room4, Fire Outbreak) Subscription: Alarm*( __, __ ) Scalability properties Scaling will be considered along the following dimensions: - number of subscribers and publishers - number of event subscription points - rates of event delivery

Design Criteria Failure Handling - In the presence of broken and disconnected components (publishers / subscribers) or broken communication link, Event Service System should still operate correctly. - Queuing events for disconnected clients until they reconnect Interaction Method Should communication between Publisher  Server and Server  Subscriber be a programmed interaction or human initiated interaction?

Design Criteria Filtering Should subscribers be delivered all available events or only events in which they are interested? Security Issues Possibility of restricting publishers / subscribers via access control to authenticated authorized parties Event History - Should System allow subscribers to request a history of published events (in case of disconnection)? - How much of it will be allowed without overloading the Event Service System?

Background Interest in event-based style has resulted in the development of a number of event- based middle ware infrastructures These variations have an impact on the structure, the behavior, and the performance of the applications built on top of them

Background Contd. CORBA –defines a simplified event service mechanism called channel –All the recipients that are connected to a channel receive all the notifications that are published by objects on that channel –drawbacks non-scalability non-flexible

Background contd. Smartsockets –accepts subscriptions based on subjects –notifications are characterized by subject and data parts –A component receives all the event notifications that belong to the subjects to which it has subscribed –drawbacks non-flexible

Background contd. Tibco (TIB/Rendezvous) –based on the subject as in smartsockets –drawbacks non-flexible

Background contd. Elvin –content based subscription –notifications are sets of named and typed data elements –Subscription is a declarative boolean expression over the components of event notifications a component can declare its interest in a number of notifications characterized by some common property

Background contd. JEDI –provides a similar mechanism for event subscription –notification is defined by a name and by a number of parameters example: Alarm(PC1,HALTED) is a notification whose name is Alarm and has two parameters whose values are PC1 and HALTED –event receivers subscribe for event patterns which are expressions over the name and parameters of notification

Background contd. SIENA –currently under development –content-based with patterns –aims at maximizing expressiveness in the selection mechanism without sacrificing scalability of the delivery mechanism

Literature Antonio Carzaniga, Elisabetta Di Nitto, David S. Rosenblum, and Alexander L.Wolf. Issues in Supporting Event-based Architectural Styles. ACM 1998, pg 17 – 20 H.Yu, D.Estrin, and R.Govindan. A hierarchical proxy architecture for Internet-scale event services. Technical Report , Dept of Comp. Sci., univ. of Southern Calif., Mar G.Cugola, E. Di Nitto, and A.Fuggetta, “Exploiting an Event-based Infrastructure to Develop Complex Distributed Systems”, In Proceedings of the 20 th International Conference on Software Engineering, Kyoto, Japan, April 1998 Antonio Carzaniga and Alexander L.Wolf. Design and Evaluation of a Wide-Area Event Notification Service. ACM Transactions on Computer Systems, Vol. 19, No. 3, August 2001, pg D.S. Rosenblum and A.L. Wolf. A Design Framework for Internet-Scale Event Observation and Notification. In Proceedings of the sixth European Software Engineering Conference, Zurich, Sept.1997

Literature Contd… Daniel J. Barrett, Lori A. Clarke, Peri L. Tarr, and Alexander E.Wise. A Framework for Event-Based Software Integration. ACM Transaction on Software Engineering and Methodology, Vol.5, No. 4, October 1996, pg V.Tsaoussidis, H. Badr, L. Na, J. Song. A CORBA-based Application Service Middleware Architecture and Implementation. IEEE 1999, pg Antonio Carzaniga, D.S Rosenblum and A.L Wolf. Design of a Scalable Event Notification Service: Interface and Architecture. Univ. of Colorado, Dept. of Comp. Sci., Technical Report, August Masoud Mansouri-Samani and Morris Sloman. A configurable Event Service for Distributed Systems IEEE, pg 210 – 217 Antonio Carzaniga, D.S Rosenblum and A.L Wolf. Interfaces and Algorithms for a Wide-Area Event Notification Service. Univ. of Colorado, Dept. of Comp. Sci., Technical Report, Oct. 1999