Application Server Facilities (ASF) is used with messaging providers that include the optional ASF extensions to the JMS specification. On z/OS® these extensions are implemented by the WebSphere® MQ messaging provider. From WebSphere Application Server Version 7.0 onwards, JCA is preferred to the older ASF technology.
ASF support for message-driven beans in WebSphere Application Server is known as the message listener service. When you install an ASF message-driven bean application you provide configuration information as a message listener port.
For WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.1 and some at Version 7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to Version 7.
The following figure shows WebSphere MQ ASF messaging flow when the message listener is listening in the controller.
In the z/OS WebSphere Application Server, ASF supports message-driven processing where the message-driven bean listener is in the CR and the work is distributed to the message-driven bean dispatcher in the SRs. Note that for publish-subscribe there is one listener that registers one subscription for the entire server, not separate subscriptions for each SR.
The following figure shows WebSphere MQ ASF messaging flow when the message listener is listening in a servant region.
The figure shows a special form of ASF message-driven bean processing where both the message-driven bean listener and the message-driven bean dispatcher run in the same SR. WebSphere Application Server uses this configuration for non-durable publish-subscribe messaging. Each SR registers its own subscription so that one server, potentially, receives and processes multiple copies of the same publication (that is, one copy of the same publication for each SR).