You can configure the message-driven bean deployment attributes
for a J2EE Connector Architecture (JCA) 1.5-compliant enterprise application,
to override the deployment properties defined within the application
EAR file.
Before you begin
This task assumes that you have an EAR file that contains
an enterprise application, developed as a message-driven bean, that
can be deployed in WebSphere® Application Server.
About this task
You
configure the deployment attributes of a message-driven bean application
by using an assembly tool. Detailed steps given in this task are for Rational® Application
Developer, but other tools have very similar steps.
Procedure
- Start an assembly tool. See
"Starting WebSphere Application Server Toolkit" in the Application
Server Toolkit documentation for more information.
- Edit the application EAR file. For example,
use the Rational Application Developer import wizard
to import the EAR file into the assembly tool. To start the import
wizard:
- Click File-> Import-> EAR file
- Click Next, then select the EAR
file.
- Click Finish
- Open the deployment attributes for editing. In
the Java EE Hierarchy view, right-click the EJB module for the message-driven
bean then click Open With > Deployment Descriptor Editor.
A property dialog notebook for the message-driven bean
is displayed in the property pane.
- Review and, if needed, change the deployment properties.
- In the property pane, select the Beans tab.
- Under Activation Configuration, review the properties.
Note: For EJB 3 message-driven beans, you can instead use an EJB 3 annotation to configure the activation configuration properties. Do not use an EJB 3 annotation to change or replace what is specified in the bean deployment descriptor. If an activation configuration property is specified in both places, the value used is the one that is given in the deployment descriptor.
- Acknowledge mode
- How the session acknowledges any messages it receives.
This
property applies only to message-driven beans that use bean-managed
transaction demarcation (Transaction type is
set to Bean).
- Auto Acknowledge
- The session automatically acknowledges a message when it has either
successfully returned from a call to receive, or the message listener
it has called to process the message successfully returns.
- Dups OK Acknowledge
- The session lazily acknowledges the delivery of messages. This
is likely to result in the delivery of some duplicate messages if
JMS fails, so it should be used only by consumers that are tolerant
of duplicate messages.
As defined in the EJB specification, clients cannot
use Message.acknowledge() to acknowledge messages.
If a value of CLIENT_ACKNOWLEDGE is passed on the
createxxxSession call, then messages are automatically
acknowledged by the application server and Message.acknowledge() is
not used.
- Destination type
- Whether the message bean uses a queue or topic destination.
- Queue
- The message bean uses a queue destination.
- Topic
- The message bean uses a topic destination.
- Durability
- Whether a JMS topic subscription is durable or non-durable.
- Durable
- A subscriber registers a durable subscription with a unique identity
that is retained by JMS. Subsequent subscriber objects with the same
identity resume the subscription in the state it was left in by the
earlier subscriber. If there is no active subscriber for a durable
subscription, JMS retains the subscription messages until they are
received by the subscription or until they expire.
- Nondurable
- Non-durable subscriptions last for the lifetime of their subscriber
object. This means that a client sees the messages published on a
topic only while its subscriber is active. If the subscriber is not
active, the client is missing messages published on its topic.
A
non-durable subscriber can only be used in the same transactional
context (for example, a global transaction or an unspecified transaction
context) that existed when the subscriber was created. For more information
about this context restriction, see The effect of transaction context on non-durable subscribers.
- Message selector
- The JMS message selector to be used to determine which messages
the message bean receives; for example:
JMSType='car' AND color='blue' AND weight>2500
The
selector string can refer to fields in the JMS message header and
fields in the message properties. Message selectors cannot reference
message body values.
For more details about these properties, see Message-driven bean deployment descriptor properties.
- Under WebSphere Bindings, select the JCA Adapter option
then specify the bindings deployment properties:
- ActivationSpec JNDI name
- Type the JNDI name of the J2C activation specification that is
to be used to deploy this message-driven bean. This name must match
the name of a J2C activation specification that you define to WebSphere
Application Server.
- ActivationSpec Authorization Alias
- The name of a J2C authentication alias used for authentication
of connections to the JCA resource adapter. A J2C authentication alias
specifies the user ID and password that is used to authenticate the
creation of a new connection to the JCA resource adapter.
- Destination JNDI name
- Type the JNDI name that the message-driven bean uses to look up
the JMS destination in the JNDI namespace.
- Save your changes to the deployment descriptor.
- Close the deployment descriptor editor.
- When prompted, click Yes to indicate
that you want to save changes to the deployment descriptor.
- Verify the archive files.
- From the popup menu of the project, click Deploy to
generate EJB deployment code.
- Optional: Test your completed module on a WebSphere Application Server installation.
Right-click a module, click Run on Server,
and follow the instructions in the displayed wizard. Note that Run
on Server works on the Windows®,
Linux/Intel, and AIX® operating systems only; you cannot deploy
remotely to a WebSphere Application Server installation
on a UNIX® operating system such as Solaris.
Important: Use Run On Server for unit
testing only. When an application is published remotely, the assembly
tool overwrites the server configuration file for that server. Do
not use on production servers.
What to do next
After assembling your application, use a systems management
tool to deploy the EAR file onto the application server that is to
run the application; for example, using the administrative console
as described in
Deploying
and managing applications.