Message Expiration

This section explains, through an example scenario, how the Message Expiration EIP can be implemented using WSO2 ESB. The following topics are covered: 

Introduction to Message Expiration

The Message Expiration EIP allows a sender to indicate when a message should be considered stale and shouldn’t be processed. You can set the Message Expiration to specify a time limit in which a message is viable. For more information, refer to http://www.eaipatterns.com/MessageExpiration.html.

Figure 1: Message Expiration EIP

Example scenario

This example scenario simulates message expiration using the endpoint timeout property in WSO2 ESB. Message expiration sets a time limit for a sent message to be visible. If the limit is exceeded, the message will be discarded without being sent to the receiver. 

While setting a delivery timeout for a message in the Message Expiration EIP can be an inherent component of a sender process, WSO2 ESB can implement this EIP through the use of an endpoint timeout. Alternatively, you can use a MessageStore with a Time To Live duration set by WSO2 ESB, which expires messages if this duration is reached before passing the message to the intended receivers.

The diagram below depicts how to simulate the example scenario in WSO2 ESB.

Figure 2: Example Scenario of the Message Expiration EIP

Before digging into implementation details, let's take a look at the relationship between the example scenario and the Message Expiration EIP by comparing their core components.

Environment setup

1. Download and install WSO2 ESB from http://wso2.com/products/enterprise-service-bus. For a list of prerequisites and step-by-step installation instructions, refer to Installation Guide in the WSO2 ESB documentation.
2. Start the sample Axis2 server. For instructions, refer to the section Setting Up the ESB Samples - Starting the Axis2 server in the WSO2 ESB Documentation.

ESB configuration

Start the ESB server and log into its management console UI (https://localhost:9443/carbon). In the management console, navigate to the Main menu and click Source View in the Service Bus section. Next, copy and paste the following configuration, which helps you explore the example scenario, to the source view.

<definitions xmlns="http://ws.apache.org/ns/synapse">
<proxy xmlns="http://ws.apache.org/ns/synapse" name="MessageExpirationProxy" transports="https,http" statistics="disable" trace="disable" startOnLoad="true">
   <target>
      <inSequence onError="LogAndDropMessageFault">
         <log level="full"/>
      </inSequence>
      <outSequence onError="fault">
         <log level="full"/>
         <send/>
      </outSequence>
      <endpoint name="TimeoutEndpoint">
         <address uri="http://localhost:9000/services/SimpleStockQuoteService">
            <timeout>
               <duration>30000</duration>
               <responseAction>fault</responseAction>
            </timeout>
         </address>
      </endpoint>
   </target>
   <description></description>
</proxy>
<sequence name="LogAndDropMessageFault">
   <log level="full">
      <property name="MESSAGE" value="Executing default &#34;fault&#34; sequence"/>
      <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
      <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
   </log>
   <drop/>
</sequence>
</definitions>

Simulating the sample scenario

1. Send a request using the Stock Quote client to WSO2 ESB in the following manner. For information on the Stock Quote client, refer to the Sample Clients section in the WSO2 ESB documentation.
   

   ant stockquote -Dtrpurl=http://localhost:8280/services/MessageExpirationProxy -Dsymbol=foo

2. Notice the expected response for the request. Next, drop the Axis2 server instance and restart the ESB. The endpoint will time out and be suspended after the timeout period, causing a fault condition. 

How the implementation works

Let's investigate the elements of the ESB configuration in detail. The line numbers below are mapped with the ESB configuration shown above. 

• Endpoint [line 13 in ESB config] - Defines the back-end service the messages are passed to. 
• timeout [line 15 in ESB config] - Defines the timeout duration in milliseconds, and also the action to take (fault or discard) in the event of a response timeout. In this example scenario, when a timeout occurs, the LogAndDropMessageFault sequence activates where the message is dropped using the Drop Mediator. An alternative to dropping the message is to pass the message to a Dead Letter Channel.