JMS Backchannel

16
Implementing JMS backchannel Prepared By: Rupesh Sinha

Transcript of JMS Backchannel

Implementing JMS

backchannel

Prepared By: Rupesh Sinha

Overview

• What is JMS backchannel?

• Implementing JMS backchannel using request-

response JMS outbound and inbound endpoints

• Implementing JMS backchannel using request-

reply message processor

• Testing and observations

• Request-response Vs Request-reply approach

• Conclusion

What is JMS backchannel?−Java Messaging Service are used mostly for

asynchronous communication between client and server. Mule ESB allows using JMS for synchronous communication where client and server can be decoupled completely.

−JMS synchronous communication is also referred to as “Backchannel”.

−JMS backchannel is not provided automatically by the JMS protocol or any JMS brokers. Backchannel must be implemented by the applications.

Implementing JMS backchannel

• Mule ESB supports two ways to

implement synchronous messaging

between client and server using

JMS−Using request-response JMS outbound

and inbound endpoints−Using request-reply message

processor

Active MQ Connector Configuration

Click on Global Elements tab in your main flow

Click on Create Button

Select Active MQ (type Active MQ in the Filter

textbox to easily find Active MQ connector)

Add Broker URL, User Name & Password

Click on OK

A sample screen and XML configuration is

shown in the next slide

Implementing backchannel using request-response JMS outbound and inbound endpoints

Request-response JMS endpoints internally creates a temporary response queue for JMS backchannel

The response is sent to client via the temporary queue The response queue is anonymous and Mule automatically sets

the JMS_REPLY_TO property. This property instructs mule where to send reply message

The response queue is created for every message exchange and is destroyed immediately after response is received by the client

JMSCorrelationId ensures proper sequencing

Client Flow

Server Flow

Implementing backchannel using request-reply message processor

JMS outbound and inbound endpoints are nested in the request-reply message processor

Sends requests to target queue through JMS outbound-endpoint

Receives responses through the JMS inbound-endpoint

Both request and response queues are explicitly specified and are named queues

JMSCorrelationId ensures proper sequencing

Client Flow

Server Flow

Testing and observations

Open a browser and hit the below URL

http://localhost:1111/backchannel

This will invoke the “jmsmessagepublisher” flow and will send

a message to request queue

“Jmsmessagereceiver” queue will log the request message

received and will return a new message

“Jmsmessagepublisher” flow will receive the message returned

from the “Jmsmessagereceiver” queue and will log the final

response

The final response will be printed on the browser

If using request-response JMS endpoints and running in INFO

mode, you will observe the temporary queue and correlation id

logged in logs

Request-Response Vs Request-Reply backchannel

Request-Response is exchange pattern whereas Request-Reply is a

message processor in Mule

Request-Response based backchannel is useful if message has to be

sent and received on the same queue whereas Request-Reply based

backchannel is useful if you have two different queues for sending and

receiving messages

Request-Response approach creates a temporary queue for

synchronous communication between client and server whereas

Request-Reply approach uses two named queues

Request-Response approach creates and destroys the temporary queue

for every message exchange and hence consumes additional CPU

cycles and memory compared to Request-Reply based implementation

Request-Response approach can become a performance and resource

utilization concern

For more details, please refer the MuleSoft reference document at below URL

http://www.mulesoft.org/documentation/display/current/JMS+Transport+Reference

Thanks for watching