A connection contains information on how to connect to a broker, WebSphere® MQ queue manager, or another JNDI-enabled JMS provider. The MQTT connection exists for specifying connection information to a broker. The MQJMS connection exists for connecting to a WebSphere MQ queue manager. The JNDI connection exists to connect to a JMS provider in a generic way by using JNDI to retrieve further connection details.
Three types of connections are available:
The MQTT connection allows specific MQTT properties to be set, such as a keepalive value. This connection uses the MQTT version 3 protocol.MQJMS Connection
This connection can be used to connect to other micro broker components and MQTT version 3 or higher enabled brokers.
The MQJMS connection is a specific connection to a WebSphere MQ queue manager. Properties such as broker version, queue manager name and channel can be set. This connection supports both publish and subscribe and point-to-point messaging. To support publish and subscribe messaging, the queue manager must be running a broker. Refer to the WebSphere MQ documentation for details on setting up a broker. JNDI Connection
This connection also requires access to a synchronization queue to provide assured message delivery and a dead letter queue for unsupported message types. The default dead letter queue should always be present on your queue manager as it is a system queue but the default synchronization queue will need to be created the first time the queue manager is used as part of a connection to the micro broker. If either queue can not be accessed the connection will not be started.
The JNDI connection creates a connection to any JMS client that can be administered using JNDI. This connection is a generic connection and provides the most flexibility. It can be used to create a connection to a WebSphere MQ queue manager using JNDI, or other JMS providers that support JNDI. This connection requires an Initial Context Factory and URL to be defined in order to connect to the JNDI repository. Once it can access the JNDI repository, it also requires a connection factory lookup key. All provider specific information is then retrieved using this JNDI repository. If the repository requires any other JNDI properties to be set, these can also be defined when creating the JNDI connection.
This connection can optionally define a synchronization queue and a dead letter queue. As this is not a required parameter, there is no default, but if a synchronization queue is not set, QoS 2 messages can not be sent as message delivery cannot be assured. (QoS 2 messages can still be received as this does not require the use of the synchronization queue.) If dead letter queue is not defined and an unsupported message type is placed onto a queue or topic, the connection is listening or subscribing to the message will be taken from the queue or topic and discarded.
There are a few well defined JNDI security properties that can be set using the connection definition. They will not be encrypted when the configuration data is saved. Another way to provide these properties is to use a JNDI security class. This is a class that must be written and must provide any security parameters required to use the JNDI repository.
Details on how to create and use the JNDI security class framework can be found in Adding JNDI security properties
Parent topic: Components of the bridge: XPD621