Application Server Facilities (ASF) mode is the default
method by which the message listener service in WebSphere® Application Server processes messages.
This topic explains how WebSphere Application Server processes
messages in ASF mode.
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.
Note: If you are using WebSphere MQ as
your messaging provider, in the examples in this topic, JMS provider
refers to your WebSphere MQ queue
manager.
Main features of ASF mode
By default, message-driven
beans (MDBs) that are deployed on WebSphere Application Server for use with listener
ports, use ASF mode to monitor JMS destinations and to process messages.
In ASF mode, a thread
is allocated for work when a message is detected at the destination
for it to process. The number of work records that can be held on
the workload management (WLM) queue is dictated by the value specified
for the Maximum Sessions property for the listener
port.
If
WebSphere MQ is your messaging provider,
there are several configurations you can use in ASF mode. With the
following configurations each thread uses a separate physical network
connection:
- A WebSphere MQ Version 6.0 queue
manager.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 6.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 0.
With the following configuration, threads share a user-defined
number of physical network connections:
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 1 or higher. In this case
each thread represents an individual connection to a queue manager.
However, each thread does not have its own physical network connection,
Instead, the threads share the number of network connections specified
in the SHARECNV (sharing conversations) parameter.
How messages are processed in ASF mode
In
ASF mode, server sessions and threads are only allocated for work
when a message that is suitable for the message-driven bean (MDB)
is detected.
The default value for
Maximum
Sessions on listener ports is
1.
This means that the MDB can only process one message at a time. The
example shows how messages are processed in ASF mode when
Maximum
Sessions is set to
1:
- When the listener port is started, it opens a connection to the
JMS provider and creates an internal queue agent.
- The queue agent listens to the JMS destination for messages.
- The queue agent detects a message and checks whether it is suitable
for the MDB that is using the listener port.
- If the message is suitable for the MDB, the queue agent passes
the message ID into a work record. The work record is then sent to
the workload management (WLM) queue.
- The queue agent starts listening for messages again.
- The WLM queue starts an ASF dispatcher inside a servant region
to process the work record.
- The ASF dispatcher allocates a server session from the server
session pool.
- The server session use the message ID from the work record to
retrieve the message from the destination.
- The server session processes the message by calling the onMessage() method
of the MDB.
- When the message is processed, the server session exits and returns
to the application server session pool. The connection that the server
session has opened to the JMS provider remains open so that the server
session does not need to re-establish the connection the next time
it is used.
- The thread exits and returns to the message listener service thread
pool.
The following diagram shows how messaging
takes place between WebSphere Application Server and WebSphere MQ
in ASF mode, with Maximum Sessions set to 1.
The numbers on the diagram correspond to the numbers in the list.

ASF mode enables you to process more than
one message concurrently. To do this, set
Maximum Sessions to
a value higher than
1. If, for example,
Maximum
Sessions is set to
2, messages are
processed in the following way:
- The queue agent detects the first message and sets up a work record,
as in the first example.
- The work record is sent to the WLM queue and an ASF dispatcher
is set up in a servant region.
- The ASF dispatcher allocates a server session and the message
is processed using the onMessage() method
of the MDB.
- Whilst the first message is processing, the queue agent starts
listening for messages again.
- The queue agent detects the second message and allocates a second
thread and a second server session. The message is processed using
the onMessage() method of the
MDB.
- When the first message is processed, the first server session
exits and returns to the server session pool. The first thread exits
and returns to the thread pool.
- When the second message is processed, the second server session
exits and returns to the server session pool. The second thread exits
and returns to the thread pool.