With the use of the optional MicroBrokerBridgeJNDI bundle, a connection can be made to a JMS provider that supports JNDI. There are different requirements for using this additional functionality so ensure you meet the prerequisites.
Configuring your JMS provider
To support sending messages to another JMS provider using QoS 2, a synchronization queue must be defined. This queue is used to temporarily store messages to ensure they are delivered at the correct quality of service.
If your JMS provider does not support point-to-point messaging and a queue can not be created, QoS 2 messages can not be sent to your provider.
There is no default synchronization queue for a JNDI connection however the default name for the MQJMS connection is fmb.sync.q. This synchronization queue can be shared between different micro broker and pipes within the same micro broker. However, in order to ensure the queue is used correctly, two micro broker with the same name must not use the same queue. If two micro broker with different names are using the queue and their pipe names are the same, this is acceptable. Failure to use the queue correctly could lead to the loss of messages.
Setting up your environment
To bridge messages to a JMS server using JNDI, the JMS provider's client bundles must be made available to the target OSGi runtime. To provide access to the required packages in the provider JMS client, the JAR files can be packaged as an OSGi bundle using the Expeditor Toolkit. The steps to do this are similar to those for packaging the WebSphere® MQ 5.x and 220.127.116.11 JARs as shown in Bridging to WebSphere MQ
. The differences for a third-party JMS provider are as follows:
- Your Client Services project name must reflect that of your JMS provider rather than WebSphere MQ.
- You will need to determine exactly which JAR files are required for your provider for copying into the root of the new Client Services project. These will be provider specific rather than those of the WebSphere MQ client.
- The META-INF / MANIFEST.MF file must display Bundle-Name and Bundle-SymbolicName attributes as appropriate for your provider. Similarly, the Bundle-ClassPath attribute must contain the list of JAR files for the JMS provider that were copied into the project previously rather than those of the WebSphere MQ client.
- The Export-Package attribute must contain the list of packages that your JMS provider provides for client applications. This list will be provider-specific rather than those of MQ and will expose only those packages required by JMS applications to use the provider implementation of JMS.
Note that the Expeditor platform contains bundles providing the javax.jms package and some providers might include an implementation of this package within their JMS client code. If your Expeditor runtime already contains the Expeditor javax.jms packages, your Client Services project must not export them as well. If your Client Services project must export the javax.jms package, you must ensure that your Expeditor runtime does not also include the Expeditor implementation of the javax.jms package.
Parent topic: Using the bridge: XPD622