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

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

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

Icono que indica el tipo de tema Tema de concepto



Icono de indicación de fecha y hora Última actualización: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_msg_embedded
Nombre de archivo:cwlp_msg_embedded.html