Liberty embedded JMS messaging provider

Liberty messaging is an embedded messaging feature in Liberty. It is a composable, flexible, and dynamic JMS messaging engine that runs within Liberty. Liberty messaging is both JMS 1.1 and JMS 2.0 specifications compliant and supports both the point-to-point and publish/subscribe messaging models.

Liberty messaging runs only in the Liberty run time, and you can use the Liberty feature manager to enable or disable the messaging features as required. Because the messaging run time is highly composable, you can enable the basic messaging features for the run time, and dynamically enable more messaging features, such as security, transactions, and remote communication, based on your requirement.

Liberty messaging can be classified into two parts:
  • JMS Server run time: Provides all the runtime capabilities for connections, transactions, persistence, security, and so on.
  • JMS Client connectivity: Provides the resource adapter support to allow JMS clients to perform synchronous and asynchronous messaging activities.

The messaging engine runs as a singleton instance in Liberty, which means that at any specific time, there can be only one messaging engine that is running in a Liberty kernel.

Liberty messaging architecture

Liberty messaging is highly composable and dynamic in nature. Liberty messaging consists of several other internal messaging subcomponents, which are implemented as OSGi bundles, that can be enabled or disabled based on the user requirements. OSGi services are used to manage component lifecycles and the injection of dependencies and configurations.
Figure 1. Liberty messaging architecture
Diagram shows the basic Liberty messaging service components

In the previous figure, the core messaging runtime service is connected to send and receive data from the utility service and to send data to the persistent store service, which in turn is connected to the file store. These components are necessary for the messaging runtime to be initialized. Also depicted are the security service, the transaction service, and the comma service, which receive data from the core messaging service. These services, along with the resource adapter service and the JMS resource service, which are also depicted but not connected to the core messaging runtime, are not a part of the core messaging runtime. These services can be enabled or disabled on requirement.

The messaging run time and the other messaging subcomponents are run as OSGi bundles in an OSGi framework. This enables the Liberty kernel to load or unload the messaging bundles based on the usage. For example, if the user does not use the messaging security, then the bundles that are related to the messaging security are not initialized.

Application deployment

Liberty messaging supports three types of JMS application connectivity. The application can run in any of the following ways:
  • In a Liberty that is hosting the messaging engine.
  • In a different Liberty that is not hosting any messaging engine.
  • In WebSphere® Application Server traditional.
Figure 2. Application deployment model
Diagram shows the three types of JMS application connectivity that the Liberty messaging supports

The previous figure shows the three types of JMS application connectivity that the Liberty messaging supports. The messaging engine is connected to a JMS application running on the same Liberty server, a JMS application running on a separate Liberty server, and a JMS application running on WebSphere Application Server traditional.

Liberty messaging supports both in-process and network TCP/IP connectivity for applications. When the JMS application is deployed in the same JVM where the messaging engine is running, the application can communicate with the in-process messaging engine, without going over the TCP/IP layer. This provides significant performance benefits for the applications to send and receive messages.

JMS applications that are running on Liberty that is not hosting the messaging engine must connect over TCP/IP in order to communicate with the messaging engine.

Message handling

Destinations (queues or topics) are always localized to the messaging engine where the destinations are defined. If the application needs to send or receive a message from a destination, it must always connect to the messaging engine that localizes the destination.
Figure 3. Message handling in Liberty messaging
Diagram showing how the Liberty messaging handles messages

The previous figure shows the messaging engine connected to a JMS consumer and a JMS application that are on the same Liberty server as the messaging engine. The engine is also connected to a JMS application that is running on a separate Liberty server and a WebSphere Application Server traditional JMS consumer.