Versions Compared

Old Version 9

changes.mady.by.user Former user

Saved on

compared with

New Version 10

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

JMS Synchronous Invocations : Quad Channel JMS-to-JMS

 Diagram 5 : Quad-channel JMS synchronous invocations

 

The following example code shows configuration of WSO2 ESB for quad-channel JMS synchronous invocations.

 

 

 

Code Block
languagehtml/xml
titleExample Code 5
<proxy name="QuadJMS" transports="jms">
      <target>
          <inSequence>
              <property action="set" name="transport.jms.ContentTypeProperty" value="Content-Type" scope="axis2"/>
              <send>
                  <endpoint>
                      <address uri="jms:/BEReq?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;                 java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;java.naming.provider.url=tcp://localhost:61616&amp;transport.jms.DestinationType=queue&amp;transport.jms.ReplyDestination=BERes"/>
                  </endpoint>
              </send>
          </inSequence>
          <outSequence>
              <send/>
          </outSequence>
      <target>
      <parameter name="transport.jms.Destination">ClientReq</parameter>
</proxy>

 

 

 

 

 

 

 The message flow of the above sample code is as follows:

  1. JMSReplyTo property of JMS message is set to ClientRes. Therefore, the client sends a JMS message to ClientReq queue.
  2. Next, the transport.jms.ReplyDestination value is set to BERes. This enables the ESB proxy to pick messages from ClientReq queue, and send to BEReq queue.
  3. Next, the back-end picks messages from the BEReq queue, processes and places response messages to BERes queue.
  4. Once a response is available in BERes queue, the proxy service picks it and sends back to ClientRes queue.
  5. Finally, the client picks it as the response message.