A JMS activation specification is a configurable resource that
enables a message-driven bean (MDB) to communicate with the default messaging
provider.
Why and when to perform this task
The JMS activation specification is based on the Java Connector
Architecture (JCA) 1.5 standard, and provides Java connectivity between application
servers such as WebSphere Application Server, and enterprise information systems.
It provides a standardized way of integrating JMS providers with J2EE application
servers, and provides a framework for exchanging data with enterprise systems,
where data is transferred in the form of messages.
For earlier versions
of WebSphere Application Server, the interface between an MDB and its destination
is the listener port. A listener port is a messaging component that can be
manually started and stopped by the administrator. When a listener port stopped,
the MDB associated with it can no longer process messages. If an MDB fails
to process a message several times, the listener port is automatically stopped
by the application server. Listener ports are used with the MQ Client Link
(the WebSphere Application Server Version 5 provider), and with WebSphere MQ when used as an external
JMS provider.
With WebSphere Application Server Version 6, the interface
between an MDB and its destination is the JMS activation specification. Because
a JMS activation specification is a group of messaging configuration properties
not a component, it cannot be manually started and stopped. For this reason,
to prevent an MDB from processing messages, you must complete the following
tasks:
- Stop the application that contains the MDB.
- Stop the messaging engine.
It is possible to share a single JMS activation specification
with multiple MDBs. This simplifies administration because it is only necessary
to provide a single set of messaging configuration properties.
Note: Although
it is not possible to use the listener port configuration settings with the
WebSphere Application Server Version 6 default messaging provider, listener
ports can still be configured for earlier messaging providers, for example
the WebSphere MQ messaging provider.
The
following guidelines show which scenarios use activation specifications or
listener ports:
- If you are using J2EE 1.2 and EJB 1.1 with WebSphere Application Server
v4, MDBs are not used so you do not need listener ports or activation specifications.
WebSphere Application Server v4 uses message beans, but these are not MDbs
or EJBs.
- If you are using J2EE 1.3 and EJB 2.0 with WebSphere Application Server
Version 5, you must use listener ports. The MDBs are JMS MDBs that implement MessageListener,
and there is no JCA support. WebSphere Application Server Version 5 uses listener
;ports to associate MDB classes with their JMS destinations.
- If you are using J2EE 1.4 and EJB 2.1 with WebSphere Application Server
Version 6, you must use activation specifications. A connector MDB uses JCA to access
its resources, so the connector must therefore be configured with an activation
specification. This is for new bean development, and does not affect the
conversion of MDBs from EJB 2.0 to EJB 2.1.
- If you are using J2EE 1.4 and EJB 2.1 with WebSphere Application Server
Version 6, the decision depends on whether your JMS provider API is implemented with
JCA. In J2EE 1.4, the JMS 1.1 API can now be implemented with the JCA 1.5
API. If so, your MDB is a JMS MDB that is implemented as a connector MDB,
and must therefore be configured with an activation specification. If not,
this is the same JMS situation as for J2EE 1.3, and you must configure this
EJB 2.1 MDB in the same way as you would configure an EJB 2.0 MDB, which in
WebSphere Application Server is to use a listener port.
To configure
a JMS activation specification for the default messaging provider, you use
the administrative console to complete the following steps. This task contains
an optional step for creating a new JMS activation specification:
Steps for this task
- Display the default messaging provider. In the navigation
pane, expand .
- Select the default provider for which you want to configure an
activation specification.
- Optional: Change the Scope check
box to the scope level at which the activation specification is to be visible
to applications, according to your needs.
- In the content pane, under the Additional properties heading, click Activation
specifications. This lists any existing JMS activation
specifications for the default messaging provider in the content pane.
- Display the properties of the JMS activation specification. If you want to display an existing JMS Activation Specifications, click
one of the names listed.
Alternatively, if you want to create a new JMS
activation specification, click
New, then specify the
following required properties:
- Name
- Type the name by which the activation specification is known for administrative
purposes.
- JNDI name
- Type the JNDI name that is used to bind the activation specification into
the JNDI name space.
- Destination type
- Whether the message-driven bean uses a queue or topic destination.
- Destination JNDI name
- Type the JNDI name that the message-driven bean uses to look up the JMS
destination in the JNDI name space.
Select the type of destination on the Destination type property.
- Bus name
- The name of the bus to connect to.
Specify the name of the service integration bus to which connections are made. This must be the name
of the bus on which the bus destination identified by the Destination JNDI name property is defined. The server to which associated
message-driven beans are deployed must be a member of this bus.
You
can either select an existing bus or type the name of another bus. If you
type the name of a bus that does not exist, you must create and configure
that bus before the activation specification can be used.
- Specify properties for the JMS activation specification, according
to your needs.
- Optional: Specify custom properties of the JMS activation specification,
as J2C activation specification custom properties.
- Click OK.
- Save your changes to the master configuration.