Although polling notifications are structurally similar to adapter services, the dynamic model is similar only in the way in which metadata is initialized, which is described as follows

As with adapter services, Designer caches metadata values for polling notifications. These values include resource domain values and template descriptor information. The following figure shows the interactions within the adapter as Designer loads its cache for a polling notification. This interaction occurs either when a new polling notification node is created, or an existing one is viewed (if the data is not already held in the Designer cache).

When a user of the adapter creates a new polling notification node, or loads an existing node during server startup or package startup, the server instantiates the appropriate class and executes the initCallBack method. The package containing the polling notification node, holds the object reference of the polling notification node for the lifetime of the package. If this interaction is initiated by a package load, and the polling notification node is enabled, the enable/startup interaction occurs immediately afterwards.

Unlike with adapter services, polling notification parameter values are updated each time a user of the adapter saves the values in Designer. After the "set" methods pass the modified values to the object instance, the notification calls the updateCallBack method. If that method throws an exception, it prevents the values from being persisted in the notification node.

When a user of the adapter enables a polling notification using Integration Server Administrator, the notification calls the enableCallBack method before the startupCallBack method. If the node was previously enabled, and the user is simply starting up the notification after the package loads, then the enableCallBack call is skipped. An exception from either method call disables the notification node.

The server calls the runNotification method at regular intervals, based on the scheduling parameters that specify the interval at which Integration Server must invoke the notification. The same object instance is always used unless the schedule is configured to allow overlapping, and the previous call to runNotification has not completed.

The figure shows the interactions that occur when a user of the adapter explicitly disables a polling notification node. If a node is shut down by any other means, the disableCallBack is skipped.