Versions Compared

Key

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

Anchor
toc
toc
Contents
Table of Contents
maxLevel4
minLevel4

...

The following table lists the main components.

 

JMS ProviderThis is the messaging system that implements the JMS API interfaces and
provides certain control features.
JMS ClientsSystem components or programs that send or receive messages.
Messaging DomainsJMS supports both the point-to-point and publish/subscribe message domains.
MessagesThese are the objects used to communicate between JMS clients.
QueuesUsed to hold messages in the point-to-point domain.
TopicsUsed to hold messages in the publish/subscribe domain.
ConnectionA client’s active connection to the JMS provider
SessionOne or more sessions can be created for each connection. Used to create
senders and receivers and administer transactions.

Back to Top ^


What is point-to-point message passing?

With point-to-point, the sender and receiver agree on a message destination, also known as a queue. The sender leaves the message and the receiver picks it up at any time thereafter. The message remains in the queue until the receiver removes it.  

Back to Top ^


What is publish/subscribe message passing?

...

The following values can be used.

Duplicates Allowed

Consumer applications specify this acknowledgement mode using DUPS_OK_ACKNOWLEDGE constant defined in the Session interface. Using this mode, the session acknowledges messages lazily, which provides faster message processing times although some duplicate messages might be delivered multiple times if JMS fails.

Recommended only for applications that are tolerant to message duplicates.

Auto acknowledge

This is the default acknowledgement mode, which is specified using the AUTO_ACKNOWLEDGE constant defined in the Session interface. For each message, the session automatically acknowledges that a client has received a message in either of the following instances:

  • Right before the call to a message consumer's receive.
  • When receiveNoWait returns a message.
  • Right after the onMessage method returns successfully after invoking the consumer's MessageListener.

If a JMS provider or the message consumer crashes while it is processing a message, the message will either be re-delivered or lost when using the automatic acknowledgement mode.

Client acknowledge

Consumer applications specify this acknowledgement mode using the CLIENT_ACKNOWLEDGE constant defined in the Session interface. It gives consumer more control over when messages are acknowledged. A consumer can group a number of messages, and then invoke the acknowledge method of the message to instruct the JMS provider that the message and all other messages received until this point have been consumed.

 When a consumer uses client acknowledge, it can use the recover method of the session to revert back to its last checkpoint. This causes the session to re-deliver all messages that have not yet been acknowledged by the consumer.

 If a client crashes and later re-connects to its queue or topic, the session will effectively be recovered and the consumer will receive all unacknowledged messages.

Transactional Acknowledge

A transacted session is a related group of consumed and produced messages that are treated as a single work unit. A transaction can be either committed or rolled back. 

 When the session's commit method is called, the consumed messages are acknowledged, and the associated produced messages are sent. When a session's rollback method is called, the produced messages are destroyed, and the consumed messages are recovered. As soon as either the commit or rollback method is called, the current transaction ends and a new transaction is immediately started.   

For example, if an application moves messages from one destination to another, it should use a transacted session to ensure that the message is either successfully transferred, or not transferred at all. In this case, the commit method should be called after each message.

...

This can be achieved with the following configuration. R eplace the following line according to your end point URI: <address uri=" http://localhost:9000/services/SimpleStockQuoteService "/>.

Code Block
languagehtml/xml
 <definitions xmlns="http://ws.apache.org/ns/synapse">
  <registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
     <parameter name="cachableDuration">15000</parameter>
  </registry>
  <proxy name="StockQuoteProxy"
         transports="http"
         startOnLoad="true"
         trace="disable">
     <description/>
     <target>
        <inSequence>
           <property name="OUT_ONLY" value="true"/>
           <clone>
              <target>
                 <endpoint>
                    <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
                 </endpoint>
              </target>
              <target sequence="test"/>
           </clone>
        </inSequence>
        <outSequence>
           <send/>
        </outSequence>
     </target>
  </proxy>
  <sequence name="test">
     <payloadFactory>
        <format>
           <ns:a xmlns:ns="http://services.samples">
              <ns:b>Accepted</ns:b>
           </ns:a>
        </format>
     </payloadFactory>
     <property name="HTTP_SC" value="202" scope="axis2"/>
     <header name="To" action="remove"/>
     <property name="RESPONSE" value="true"/>
     <send/>
  </sequence>
  <sequence name="fault">
     <log level="full">
        <property name="MESSAGE" value="Executing default 'fault' sequence"/>
        <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
        <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
     </log>
     <drop/>
  </sequence>
  <sequence name="main">
     <in>
        <log level="full"/>
        <filter source="get-property('To')" regex="http://localhost:9000.*">
           <send/>
        </filter>
     </in>
     <out>
        <send/>
     </out>
     <description>The main sequence for the message mediation</description>
  </sequence>
</definitions> 

...

This will ensure that no messages will be lost even if the data source is not available at the initialization. You might notice exceptions in the log but the inserts will be done to the database accordingly.

Back to Top ^

 

...

How can you access and modify JMS headers from within a proxy service?

 

You can set custom values for JMS headers from within a proxy service using the Property mediator as follows:

 

Code Block
<property name="JMS_PRIORITY" value="2" scope="transport"/>
<property name="JMS_COORELATION_ID" value="1234567" scope="transport"/>
<property name="JMS_MESSAGE_ID" value="CustomMessageID" scope="transport"/>

 

You can then retrieve these values using get-property function (e.g., get-property('transport','JMS_PRIORITY')).

 

Back to Top ^