Java Message Service(JMS) defines a standard message API (Java API) for reliable and robust Enterprise Messaging. In other words, JMS facilitates a simple, yet very powerful communication between different software components or applications.
Fig.1 System without JMS
How JMS Add value to Web services:
Web services enable applications across the world to communicate and integrate with each other through XML. But there are certain scenarios that need to be considered while deploying Web services. Do we loose the Web services data incase our application crashes? Is it possible to replicate the Web services clients across several applications? Is it possible to establish connections between the Web-services-facing applications and the back-end systems?
Java Message Service (JMS) is considered to be one of the best methods that can be deployed to handle these scenarios. Web services and JMS, together create an architecture that can communicate across the Internet, reliably handle data, and integrate with backend systems.
Fig.2 System with JMS
The components in an application based around the message service do not communicate directly with each other. Instead of this, they send messages to the message server.
Fig.1 System without JMS
How JMS Add value to Web services:
Web services enable applications across the world to communicate and integrate with each other through XML. But there are certain scenarios that need to be considered while deploying Web services. Do we loose the Web services data incase our application crashes? Is it possible to replicate the Web services clients across several applications? Is it possible to establish connections between the Web-services-facing applications and the back-end systems?
Java Message Service (JMS) is considered to be one of the best methods that can be deployed to handle these scenarios. Web services and JMS, together create an architecture that can communicate across the Internet, reliably handle data, and integrate with backend systems.
Fig.2 System with JMS
The components in an application based around the message service do not communicate directly with each other. Instead of this, they send messages to the message server.
JMS protocols :
Fig.3 JMS Messaging Models
Many JMS implementations provide both the messaging models, but the specification defines compliance for each messaging style separately.
Point-To-Point Messaging:
Characteristics:
- Point-To-Point Messaging is appropriate when one application/client needs to send a message to another application/process.
- There may be a single or multiple senders of messages but only a single receiver.
- The sender posts messages to a particular queue and a receiver reads messages from the queue.
- The sender knows the destination of the message and posts the message directly to the receiver's queue.
- The receiver need not have to be active at the time the message is sent, nor does the sender need to be active at the time the receiver receives the message.
- receiver acknowledges all the messages which are processed successfully.
Publish-Subscribe Messaging:
Characteristics:
- Publish-Subscribe Messaging is appropriate when multiple applications need to receive the same messages.
- This model supports publishing messages to a particular message topic.
- Multiple Clients/Publishers may send messages to a Topic, and interested Clients/Subscribers receive the messages by subscribing to that topic.
- There may be multiple Senders and multiple Receivers.
- In this model, neither the publisher nor the subscriber knows about each other.
- Publisher has to create a subscription in order for clients to be able to subscribe. Subscriber has to remain continuously active to receive messages, unless it has established a durable subscription.
- The messages will be redistributed to the subscriber if it was not connected when the message was published.
Advantages
- As discussed, one important advantage is that the JMS specification supports two popular messaging models: point-to-point and publish/subscribe.
- JMS provides a reliable, scalable, and loosely coupled architecture for messaging.
- Senders and receivers are totally decoupled from each other.
- An application that becomes busy will have its Web services data automatically queued in the JMS server until it is able to process the messages.
- XML by itself doesn't have a reliable transport mechanism. JMS provides a simple yet robust way of transporting XML data between applications.
- With JMS server the sender need not check whether the receiver is currently connected or not, if a network failure occurred during the send operation, and so on.
- JMS supports both synchronous and asynchronous messaging.
Considering the advantages of the JMS, we can see how important the JMS adapter is, for integration in SAP Exchange Infrastructure.
JMS adapter in XI
Adapters enable different systems to communicate with each other. In XI, adapters enable the Integration Engine and the Partner Connectivity Kit (PCK) to communicate with different applications/messaging systems.
There are various adapters that are used in XI like File adapter, Idoc adapter, JDBC adapter, RFC adapter and so on. Here, I have mentioned only the JMS adapter as the topic deals with JMS.
Fig.4 As illustrated above, the JMS adapter exchanges JMS messages with the JMS messaging system.
Prerequisites
In order to use the JMS adapter, we need to first install the relevant JMS driver. The required Java libraries are product-specific and must be obtained from either the product vendor or other providers. Following installation, we must deploy the Java libraries on the J2EE server so that the JMS adapter can access the required Java classes at runtime. If we are using MQSeries 53x.xxx, we must enter the following JAR files in aii_af_jmsproviderlib.sda.
- com.ibm.mq.jar
- com.ibm.mqbind.jar
- com.ibm.mqjms.jar
- connector.jar (use the Jar file from the J2EE client directory)
For details, we can check out Install and Conf drivers in JDBC n JMS adapters
Integration:
We configure the adapter in the configuration part - Integration Directory of the Integration Builder/PCK in XI. In the adapter configuration, we specify whether an adapter is located at the inbound channel (sender adapter) or at the outbound channel (receiver adapter) of the PCK.
Features:
- Sender JMS adapter:
In order to send the JMS messages from a messaging system to the Integration Engine/PCK we must configure the sender JMS adapter.
It is done when we define the communication channel (sender channel) in the Integration Server, under the Parameters tab page. For the detailed steps, please refer sender JMS adapter .
Sender adapters of the Adapter Engine do not request any acknowledgments.
- Receiver JMS adapter:
In order to send the XML messages from the Integration Engine/PCK to a messaging system, we must configure a receiver JMS adapter. This will convert the XI messages to JMS messages.
Similarly, this configuration is done while defining the communication channel (receiver channel) in the Integration Server, under the Parameters tab page.
Receiver adapters that run on the Adapter Engine support system acknowledgments if they are requested by the sender. Acknowledgements are triggered when a message is successfully processed by the adapter or if an error occurs while it is being processed. Receiver adapters do not support application acknowledgments.
For the detailed steps, please refer receiver JMS adapter .
- JMS-provider-specific specifications
We can find the details about JMS-provider-specific specifications here JMS-Provider-Specific Settings .
Module Processor
We can enhance the functionality of the adapters that is configured in the communication channel (both in inbound and outbound) by defining generic modules. If it is not possible to add modules to an adapter, we will not be able to select the Module tab page. To configure modules for the JMS adapter, we can check out JMS adapter modules .
JMS Correlation ID : A correlation ID can be defined as a unique identifier that correlates the request message and its reply. The sender sends a message to a receiver and also requests for a reply message. In this scenario, the sender assigns a unique identifier to the request that is different from those for all other currently outstanding requests. The receiver receives this message and saves the identifier. When the receiver replies to the message by sending a response, it adds the request's identifier to the reply. This way the correlation ID is used to match the reply message to the request message. The correlation ID is usually put in the header of a message as the ID is not a part of the data being transmitted between the sender and the receiver.
There is a new parameter in JMS adapter now. There is an option of saving the JMS correlation ID of the request in the receiver JMS adapter. In the sender adapter, one can then set the XI conversation ID to the saved JMS correlation ID of the request. This makes the additional parameters that were required in previous Support Packages obsolete. However, the configuration settings that were made prior to SP7 are still valid.
I believe that this blog is helpful specially who are new to JMS and heading forward to use JMS adapter in SAP XI.
4 Comments
