This video gives a brief overview of JMS backchannel and provides example implementation of JMS backchannel using JMS Request-Response endpoints and Request-Reply message processors
2. 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
3. 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.
4. 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
5. 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
6.
7. 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
10. 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
13. 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
14. 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
15. For more details, please refer the MuleSoft reference document at below URL
http://www.mulesoft.org/documentation/display/current/JMS+Transport+Reference