Enable JMS messaging for Liberty

Use the wasJmsServer-1.0 and wasJmsClient-2.0 Liberty features, we can enable the Java Message Service (JMS) on a single server. To use the wasJmsServer-1.0 feature in a secure mode, we must enable the wasJmsSecurity-1.0 feature.

The wasJmsClient-2.0 feature supports the features of both JMS 1.1 and JMS 2.0 specifications. However, we can choose to use the wasJmsClient-1.1 feature to use only the features that are compliant with JMS 1.1 specification.

JMS messaging
Liberty supports asynchronous messaging as a method of communication that is based on the Java Message Service (JMS) programming interface. The JMS interface provides a common way for Java programs (clients and Java EE applications) to create, send, receive, and read asynchronous requests as JMS messages. With Liberty, we can configure multiple JMS messaging providers, which can be used by the JMS applications.
Enable JMS messaging for a single Liberty server
In a development environment, to run the JMS application and JMS messaging run time components on the same server, we can configure the wasJmsServer-1.0 and wasJmsClient-2.0 features on the same server. In this scenario, the application is deployed on the same server where the messaging engine and the JMS resources exist. When the application and the messaging engine are deployed on the same server, the application can connect to the messaging engine either over TCP/IP or in-memory API function calls. We can also configure the wasJmsSecurity-1.0 feature to enable secure connection of the application to the messaging engine.
Enable JMS messaging between two Liberty servers
In a typical production scenario, users might want to run the wasJmsServer-1.0 and the JMS applications on separate servers to distribute the workload. In such scenarios, we can configure the wasJmsClient-2.0 Liberty feature on one server, which acts as the client, and configure the wasJmsServer-1.0 feature on a different server. The JMS applications deployed on a remote server always use TCP/IP to connect to the messaging engine running on a different server. We can also configure the wasJmsSecurity-1.0 feature to make the applications to connect securely to the messaging engine, and configure the transportSecurity-1.0 feature to enable the TLS communication between the two Liberty servers.
Enable secure JMS messaging for Liberty
Use the wasJmsSecurity-1.0 Liberty feature to make the wasJmsServer-1.0 feature work in a secure mode. Secure the messaging resources ensures that only authenticated and authorized users can access the messaging resources such as queues, topics, and messages.
Secure JMS communications in Liberty using SSL
We can configure the transportSecurity-1.0 feature to enable secure communication between the two Liberty servers.
Enable interoperability between Liberty and WebSphere Application Server traditional
The JMS applications deployed within the Liberty can connect to the messaging engine that runs in WebSphere Application Server traditional (that is, service integration bus). Similarly, the JMS applications deployed within WebSphere Application Server traditional can connect to the messaging engine that runs in Liberty.
Configure connection pooling for JMS connections
We can customize the number of concurrent connections (default is 50) that can be created from a JMS connection factory. We can configure connection pooling for a specific JMS connection factory by defining the <connectionManager> element and then associate that element with the JMS connection factory in the server.xml file.

Parent topic: Administer Liberty manually

Related information

Deploy messaging applications to Liberty