Use JMS 2.0 shared subscriptions

In WebSphere Application Server traditional Version 9.0, we can configure and use JMS 2.0 shared subscriptions with IBM MQ Version 9.0.


The JMS 2.0 specification introduced the concept of shared subscriptions, which enables a single subscription to be opened by one or more consumers. The messages are shared amongst all of these consumers. There is no restriction where these consumers are so long as they connect to the same queue manager.

Shared Subscriptions can be either durable or non-durable, with the same semantics as what are now referred to as unshared subscriptions.

For a consumer to be able to identify which subscription to use, it needs to supply a subscription name. This is similar to unshared durable subscriptions, but a subscription name is required in all cases where a shared subscription is required. A clientID, however, is not required in the case of a durable shared-subscription; one can be supplied but it is not mandatory.

Whilst shared subscriptions can be thought of as a loading balancing mechanism, neither in IBM MQ nor the JMS 2.0 specification is there any commitment as to how the messages are distributed amongst consumers.

In WebSphere Application Server traditional Version 9.0 an IBM MQ Version 9.0 resource adapter is pre-installed.

The following steps show how to configure an activation specification to use a shared durable or a shared non-durable subscription using the WebSphere Application Server traditional administrative console.


Procedure

First create the objects in JNDI.

  1. Create a topic destination in JNDI as normal (see Configure JMS resources using the administrative console).
  2. Create the activation specification (see Configure JMS resources using the administrative console). We can create the activation specification with exactly the properties that you need. If you want to use a durable subscription, we can select it on creation and specify a name. If you want to use a non-durable subscription, we cannot specify a name at this point. Instead, you need to create a custom property for the subscription name.

Update the activation specification that you created with the required custom properties. There are two custom properties that you might need to specify:

  • In all cases, you must create a custom property to specify that this activation specification should use a shared subscription.
  • If the subscription was created as non-durable, the subscription name property needs to be set as a custom property.
The following table shows the valid value that we can specify for each custom property:
Property Name Type Valid values
sharedSubscription String true, false
subscriptionName String Non-zero length java String

  1. Select the activation specification from the list displayed in the Activation specification collection form. The details for the activation specification are displayed in the IBM MQ messaging provider activation specification settings form.
  2. On the IBM MQ messaging provider activation specification settings form, click Custom properties. The Custom properties form is displayed.
  3. If you are using a non-durable subscription, create the subscriptionName custom property. On the Custom properties panel of the activation specification, click New, then enter the following details:

      Name

      The name of the custom property, which in this case is subscriptionName.

      Value

      The value for the custom property. You could use the JNDI names in the Value field , for example WASSharedSubOne.

      Type

      The type of the custom property. Select the custom property type from the list, which in this case must be java.lang.String.

  4. For both a shared durable and shared non-durable subscription, create the sharedSubscription custom property. On the Custom properties panel of the activation specification, click New, then enter the following details:

      Name

      The name of the custom property, which in this case is sharedSubscription.

      Value

      The value for the custom property. To specify that the activation specification uses a shared subscription, set the value to true. If you later wanted to stop using a shared subscription for this activation specification, you could do this by setting the value of this custom property to false.

      Type

      The type of the custom property. Select the custom property type from the list, which in this case must be java.lang.String.

  5. When the properties are set, restart the application server. The message-driven beans (MDB)s for the activation specifications are then driven when messages arrive, but only the MDBs share the messages that are sent.