Listeners and listener notifications work together to create a much more powerful model for detecting and processing events in the adapter resource than is possible with polling notifications.

When the adapter user enables the polling notification node, the server instantiates and initializes a polling notification object with settings from the node. The server then invokes the object (via a call to its runNotification method) on a periodic basis. The polling notification object must retrieve a connection and use it to determine if publishable events have occurred in the adapter resource. If an event has occurred, the polling notification object must generate a WmRecord object conforming to the output signature of the polling notification node, and publish it by calling the doNotify method. Then the polling notification object "goes to sleep" until the next time it is invoked. If the overlap option is enabled in the notification schedule, a second object may be instantiated while a previous instance is still processing events detected in a previous invocation. The second instance retrieves another connection, and interrogates the resource again. This model can make state management significantly more difficult.

With a listener notification, the responsibility for monitoring the adapter resource and processing any events is divided between a listener and its notification(s). A listener object is instantiated and is given a connection when the adapter user enables the associated node. The listener object remains active with the same connection to monitor the resource activity until it is disabled (either explicitly or by disabling the containing package, the adapter, the connection, or webMethods Integration Server). When the listener detects a publishable event in the resource, it passes an object back to the server. The server will interrogate a configured list of listener notifications associated with the listener node until it finds a listener notification node that can process the event. To do this, it calls the listener notification's supports method. The first notification to return true from this call will be invoked using its runNotification method. This behavior is similar to a polling notification in that any data about the event that was provided by the listener is passed as an argument to runNotification.