Skip to end of metadata
Go to start of metadata

This page describes how the Listener Pattern is typically implemented within Asterisk SCF.


The Listener Pattern is a simple pattern in which an interface is defined by some event publisher with methods of the interface representing each of the events that the publisher produces, at least for a specific category of events. In this example, there is a Server component which exposes an interface of FooOperations. In addition to the operations join() and visit() the FooOperations interface also supports adding and removing listeners to those operations. The Listener interface is defined in another interface named FooListener. The FooListener interface provides a callback operation that serve as notification of each of the two primary operations of the FooOperations interface. In addition to providing the parameters provided to the original operations, the listener callback notifications can additionally provide arguments that described the outcome of the operation (such as success/failure), or provide any other information that might be useful. Since the Listener interface is typically custom designed for a specific set of operations, the interface designer can choose what type of additional information (if any) would be useful.

Figure 1. The Listener Pattern

When a Client of the Server process invokes the operations of the Server, notifications are sent to all registered listeners. Figure 2 below shows how IceStorm is typically used in Asterisk SCF to propagate the listener notifications. The Server process in this examples accepts the listener from the ListeningComponent, and creates (or retrieves) an IceStorm topic specific to it's needs. The Server then subscribes the FooListener proxy to the IceStorm topic on behalf of the ListeningComponent.

As Client operations are invoked on the FooOperations interface, the Server forwards notifications to the relevant IceStorm topic, which handles propagating the notifications to all registered listeners. This offloads the routing of notification messages from the Server to IceStorm, which is specifically designed to handle Quality of Service and other needs of a scalable messaging system.

Figure 2. IceStorm used to propagate notifications.

It should be noted that from the ListeningComponent perspective, the use of IceStorm to propagate notifications is totally transparent. From the listener's point of view, the messages could just have well come directly from the Server.

  • No labels