An event has an event type, and may contain associated data to be passed to the receiver. For example, most events, when generated may pass context information to determine which session or connection the event belongs to. The following types of events can be generated in the AMPS model:

• Request events
  These events represent a request for a particular type of service from another module, directed towards any module that could provide the service. The requester does not know at the time of generating the request event which module is going to serve this request. It just blindly generates the request event, hoping that there is a module in the system that could provide the response. The requester however registers its interest in the response event corresponding to the request.
• Response events
  These events represent a response to an earlier generated request. They are always generated in response to a request. These are generated by modules who registered their interest for a particular request. Of course these would most likely register their interest in a request event, only if they are able to process the request and provide a response. When they receive the request (due to the fact that they registered interest in it) they generate the response event after request processing is complete.
• Notification events
  These events represent asynchronous notifications. They may be generated by modules that want to provide some information or a service for which no request is necessary. In other words, the information or the provided service is unsolicited. If it is of importance to any other module, that module would register its interest in it and thus receive the notification event.

Event Management in AMPS

• Listeners
  These are modules that want to receive an event whenever it will be generated. They register their interest in a particular event using the AMPS API. They may register their interest in request, response or notification events. When a module registers for an event as a listener, it must provide a callback function. This function is called when the event is delivered to the module.
• Notifiers
  These are modules that want to send requests, responses or asynchronous notifications events. They generate request, response or notification events, which in turn are propagated to listeners by the AMPS event management system.
• Event Manager
  This is the central component of the event management system. It manages registrations coming from listeners and notifications from notifiers. When an event is generated (notified), the event manager arranges for the delivery of event to listeners. If multiple events are generated concurrently, the event manager invokes the event scheduler to deliver them to listeners in a certain order.

When the application designer wants to add a new module into the system, he/she needs to perform the following steps:

• a. Determine the services this module would provide to the rest of the system.
• b. Categorize the services provided by the module into response events (the events the module would generate in response to requests) and asynchronous notifications that the module would generate to announce some information to the rest of the system.
• c. Determine the services this module would need from other modules.
• d. Categorize the services this module would need from other modules into requests the module would make to the rest of the system, and asynchronous notifications it would need to process if supplied by any other module in the system.
• e. Add new request, response and notification events in the application if required as a result of step b.
• f. Write an initialization function that:
• Registers itself as a listener for the request events determined in step (b) above so that the request events it serves could be routed to it.
• Registers itself as a listener for responses to the requests generated by the module itself determined in step (d) above so that the responses to its own requests could be routed to it.
• Registers itself for asynchronous notifications it wants to process determined in step (d) above so that those notifications could be routed to it.
• g. Write event handlers for all the events the module has registered for as a listener.
• h. Write event handlers in other modules who need services provided by this module as determined in step (b) above.

Event registrations can be done either in the initialization functions, or from inside event handlers as well since the framework provides an API for registration of events that could be called from any function. There is no restriction that it would be called from initialization function only.