WAS v8.5 > Deploy applications > Deploy messaging resources > Deploy enterprise applications > Deploy enterprise applications developed as message-driven beans > Deploy an enterprise application to use message-driven beans with JCA 1.5-compliant resources

Configure deployment attributes for a message-driven bean against JCA 1.5-compliant resources

We can configure the message-driven bean deployment attributes for a JCA 1.5-compliant enterprise application, to override the deployment attributes defined within the application EAR file.

This task assumes that we have an EAR file containing an enterprise application, developed as a message-driven bean, that can be deployed in WebSphere Application Server.

We can continue to configure message-driven beans against a listener port. You might want to do this for compatability with existing message-driven bean applications. However, listener ports are stabilized, and you should plan to migrate all your message-driven beans to use JCA 1.5-compliant or 1.6-compliant resources. You configure the deployment attributes of a message-driven bean application using an assembly tool. Detailed steps given in this task are for Rational Application Developer, but other tools have very similar steps.

1. Start your assembly tool.
   
2. 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:

   1. Click File > Import > EAR file.
      

   2. Click Next, then select the EAR file.
      

   3. Click Finish.
      

3. 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.
4. Review and, if needed, change the deployment attributes.
   1. In the property pane, select the Bean tab.
      

   2. Under Activation Configuration, review the attributes.
      

      For EJB 3 message-driven beans, we 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.

      acknowledgeMode

      This attribute determines how the session acknowledges any messages it receives.

      Auto Acknowledge

      The session automatically acknowledges delivery of each message.

      Dups OK Acknowledge

      The session lazily acknowledges the delivery of messages. This setting is likely to result in the delivery of some duplicate messages if JMS fails, so it should be used only by consumer applications that are tolerant of duplicate messages.

      destinationType

      This attribute determines whether the message-driven bean uses a queue or topic destination.

      Queue

      The message-driven bean uses a queue destination.

      Topic

      The message-driven bean uses a topic destination.

      subscriptionDurability

      This attribute determines whether a JMS topic subscription is durable or nondurable.

      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

      Nondurable 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 nondurable 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.

      messageSelector

      This attribute determines the JMS message selector used to select which messages the message-driven 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.

   3. Specify bindings deployment attributes.
      

      Under WebSphere Bindings, select the JCA Adapter option then specify the bindings deployment attributes:

      ActivationSpec JNDI name

      This attribute specifies the JNDI name of the activation specification used to deploy this message-driven bean. This name must match the name of an activation specification defined to WAS.

      ActivationSpec Authorization Alias

      This attribute specifies the name of an authentication alias used for authentication of connections to the JCA resource adapter. An authentication alias specifies the user ID and password used to authenticate the creation of a new connection to the JCA resource adapter.

      Destination JNDI name

      This attribute specifies the JNDI name the message-driven bean uses to look up the JMS destination in the JNDI namespace.

5. Save your changes to the deployment descriptor:
   
   1. Close the deployment descriptor editor.
      

   2. When prompted, click Yes to indicate to save changes to the deployment descriptor.
      

6. Verify the archive files.
   

7. From the pop-up menu for the project, click Deploy to generate EJB deployment code.
   

8. Optional: Test your completed module on a WAS installation.
   

   Right-click a module, click Run on Server, then follow the instructions in the displayed wizard.

   Restriction: Run on Server works on the Windows, Linux/Intel, and AIX operating systems only. We cannot deploy remotely to a WAS installation on a UNIX operating system such as Solaris.

   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.

After assembling the application, use a systems management tool to deploy the EAR file onto the application server that will run the application; for example, use the dmgr console as described in Deploy and managing applications.

Related concepts:

Message-driven beans - automatic message retrieval

Related

Assemble applications

Related information:

Rational Application Developer documentation

+

Search Tips   |   Advanced Search