Configuring the client for enabling JMS messaging between multiple Liberty servers

To enable JMS messaging on multiple servers, you must configure the wasJmsClient-2.0 feature on a different Liberty server.

Procedure

Enable the JMS client feature on the client. If you want to perform a JNDI lookup, then you must also add the jndi-1.0 feature.
```
<featureManager>
	<feature>wasJmsClient-2.0</feature>
	<feature>jndi-1.0</feature>
</featureManager>
```
Configure the required JMS resources.
```
<jmsQueueConnectionFactory jndiName="myQCF" connectionManagerRef="ConMgr4">
	<properties.wasJms
	remoteServerAddress="meserver.ibm.com:7276:BootstrapBasicMessaging" />
</jmsQueueConnectionFactory>
<connectionManager id="ConMgr4" maxPoolSize="2"/>

<jmsQueue jndiName="myQ">
	<properties.wasJms queueName="libertyQ" />
</jmsQueue>
```
Note: To enable the JMS application to perform a remote TCP/IP connection with the remote messaging engine, configure the <remoteServerAddress> property of the connection factory. The <remoteServerAddress> property refers to the server that has to be contacted, where the messaging engine exists. The property declaration must be as follows:
```
remoteServerAddress="hostname:port:mode"
```
where the hostname is the name of the host where the messaging engine is running; port is the JMS inbound port that is configured at the server side; and mode is BootstrapBasicMessaging if SSL is not used, and BootStrapSecureMessaging if SSL is used.
If the <remoteServerAddress> is not specified, then the JMS application tries to connect to a local messaging engine by default in the same Liberty server.
Optional: Configure additional properties.
- When the clients are configured to connect remotely to the messaging engine, you can create custom channels, which the application can use to connect to the messaging engine. The two default channels are BootstrapBasicMessaging and BootStrapSecureMessaging. If you want to override these two channel definitions and use a custom channel, use the <wasJmsOutbound> element as follows:
```
<featureManager>
	<feature>wasJmsClient-2.0</feature>
	<feature>jndi-1.0</feature>
</featureManager>

<wasJmsOutbound id="CustomChain"/>

<jmsQueueConnectionFactory jndiName="myQCF" connectionManagerRef="ConMgr4">
	<properties.wasJms
	remoteServerAddress="meserver.ibm.com:7276: CustomChain" />
</jmsQueueConnectionFactory>
<connectionManager id="ConMgr4" maxPoolSize="2"/>
```
- When the application uses the myQCF connection factory, it uses CustomChain to connect to the remote messaging engine instead of using BootStrapBasicMessaging. Similarly, if you want to use a secured channel, then you can use the <useSSL> option in the <wasJmsOutbound> element as given in the following example.
```
<featureManager>
	<feature>wasJmsClient-2.0</feature>
	<feature>jndi-1.0</feature>
</featureManager>

<wasJmsOutbound id="CustomChainSecured" useSSL="true"/>

<jmsQueueConnectionFactory jndiName="myQCF" connectionManagerRef="ConMgr4">
	<properties.wasJms
	remoteServerAddress="meserver.ibm.com:7276: CustomChainSecured" />
</jmsQueueConnectionFactory>
<connectionManager id="ConMgr4" maxPoolSize="2"/>
```
The messaging engine is configured to run on the client.