Beyond the Backchannel: Blending Student Content with Open Discourse
JMS Backchannel
-
Upload
rupeshkrsinha -
Category
Technology
-
view
182 -
download
4
Transcript of JMS Backchannel
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
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
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