 that it has received and logged the message. Since the used connectivity stratum is unreliable (if UDP is used), an SNMP-OSF should also poll the traf- fic nodes it manages occasionally. CORBA defines an "event service" paradigm that can be used for reporting spontaneous events in management applications. The CORBA event is defined as "an occurrence within an object," i.e., it could be anything. That occurrence is specified by using IDL for the particular object type. A GIOP message that con- tains information on events that have happened are called "notification". Since CORBA is an open platform for distributed objects, it defines a mecha- nism that allows objects to register their interest in particular events, and for dis- tribution of notifications to one or many objects. This mechanism is called "event channel," which in reality is a standard object that is available to all CORBA applications, such as the AFs and OSFs of our management model in Fig. 5.8. It could be applied in a management application as in the following scenario: An object in the OSF that is an "event-consumer" object, tells its "event -channel" object that it is interested in a particular event of a particular "event-supplier" object (in this case an object in the OSF and an MO in an 5 Management and Traffic Systems The event-channel object registers that interest (event, event supplier, event consumer). It then tells the actual MO (via GIOP and the event-channel object in AF) to report the particular event. When the event happens, the MO reports the occurrence to the event-channel object in AF, which looks up which remote CORBA systems have registered for that particular event. It then uses GIOP to inform those systems, in this case the OSF. In an OSF, the event-channel object looks up which local event-consumer objects have registered for the event and informs them. This is called the "push scenario", and is supported by four event-channel oper- ations that any object can use. The "pull scenario" defines another four operations. In pull