A listener notification works in conjunction with a listener object to create a much more powerful model for detecting and processing events in the adapter resource than is possible with polling notifications. You need to implement one listener notification template class for each listener notification the adapter will support.

A listener object is connected to an adapter resource, waiting for the server to deliver event notifications. The listener object is instantiated and is given a connection when the associated node is enabled. The listener object remains active with the same connection to monitor the resource activity until it is explicitly disabled.

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. The first listener notification to return true from this call will be invoked.

The ADK includes both a synchronous and an asynchronous processing model. An asynchronous listener notification publishes a document to a webMethods Broker queue, using the doNotify method. Adapter users may process the document's data any way they want to. For example, they can create an Integration Server trigger that receives the document and executes an IS service.

A synchronous listener notification invokes a specified IS service, and potentially receives a reply from the service and delivers the results back to the adapter resource. In this case, the notification object's runNotification method calls invokeService (instead of doNotify), to process the data produced by the notification. A synchronous listener notification does not publish a document.

For more information, see Listener Notifications.