Configure deployment attributes using the Assembly Toolkit

Use this task to configure the message-driven beans deployment attributes for an enterprise bean, to override the deployment attributes defined within the application EAR file.

You can configure the deployment attributes of an application by using the Deployment Descriptor Editor of WebSphere Studio Application Developer or the Assembly Toolkit.

This topic describes the use of the Assembly Toolkit to configure the deployment attributes of an application. This task description assumes that you have an EAR file, which contains an application enterprise bean developed as a message-driven bean, that can be deployed in WAS. For more details about using the Assembly Toolkit, see Assembling applications with the Assembly Toolkit.

To configure the message-driven beans deployment attributes for an enterprise bean, use the Assembly Toolkit to configure the deployment attributes of the application to match the listener port definitions...

  1. Starting the Assembly Toolkit

  2. Create or edit the application EAR file.For example, to change attributes of an existing application, use the import wizard to import the EAR file into the Assembly Toolkit. To start the import wizard...

    1. Click File-> Import-> EAR file

    2. Click Next, then select the EAR file.

    3. Click Finish

  3. In the J2EE 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. Specify general deployment properties.

    1. In the property pane, select the Beans tab.

    2. Specify the following properties...

      Transaction type Whether the message bean manages its own transactions or the container manages transactions on behalf of the bean. All messages retrieved from a specific destination have the same transactional behavior. To enable the transactional behavior that you want, configure the JMS destination with the same transactional behavior as you configure for the message bean.

      Bean The message bean manages its own transactions

      Container The container manages transactions on behalf of the bean

  5. Specify advanced deployment properties.

    1. Specify the following properties...

      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.

      Acknowledge mode How the session acknowledges any messages it receives.

      This property applies only to message-driven beans that uses 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 using Message.acknowledge() to acknowledge messages. If a value of CLIENT_ACKNOWLEDGE is passed on the createxxxSession call, then messages are automatically acknowledged by the appserver 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.

      Subscription 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's 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.

  6. Specify bindings deployment properties.

    1. Specify the following property...

      Listener port name Type the name of the listener port for this message-driven bean.

  7. Save your changes to the deployment descriptor.

    1. Close the deployment descriptor editor.

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

  8. Verify the archive files.

  9. Generate code for deployment for EJB modules or for enterprise applications that use EJB modules.

  10. (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 from the Assembly Toolkit to a WAS installation on a UNIX operating system such as Solaris.

    Important:

    Use Run On Server for unit testing only. Assembly Server Toolkit controls the WAS installation and, when an application is published remotely, the Toolkit overwrites the server configuration file for that server. Do not use on production servers. For instructions on remote testing, see the article "Setting Up a Remote WAS in WebSphere Studio V5" at http://www7b.boulder.ibm.com/wsdd/techjournal/0303_yuen/yuen.html .

After assembling your application, use a systems management tool to deploy the EAR file onto the appserver that is to run the application; for example, using the administrative console as described in Deploying and managing applications.