Fix Pack 8550

Liberty embedded JMS messaging provider

Liberty messaging is an embedded messaging feature in the Liberty profile. It is a composable, flexible, and dynamic JMS messaging engine that runs within the Liberty profile. Liberty messaging is JMS 1.1 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:

The messaging engine runs as a singleton instance in a Liberty profile, 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 profile that is hosting the messaging engine.
  • In a different Liberty profile that is not hosting any messaging engine.
  • In a WebSphere® Application Server full profile.
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 the Liberty profile 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

Icon that indicates the type of topic Concept topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Monday, 21 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-express-iseries&topic=cwlp_msg_embedded
File name: cwlp_msg_embedded.html