Red Hat Training

A Red Hat training course is available for Red Hat Fuse

16.4. Advanced Provider Configuration

16.4.1. JMS Message Qualities of Service

Overview

JMS messages have a number of quality of service properties that can be set. These QoS properties include the following:
  • the message's relative priority
  • the message's persistence
  • the message's lifespan
These properties are stored in the JMS message header. By default, the JMS broker automatically populates their values. You can, however, configure an endpoint to override the broker's default.

Setting a message's priority

You configure the endpoint to set the priority for all out going JMS messages using the priority attribute. The value you provide for the priority attribute is used to set the JMS message's JMSPriority property.
JMS priority values can range from 0 to 9. The lowest priority is 0 and the highest priority is 9. If you do not provide a value, the JMS provider will use the default priority value of 4. The default priority is considered normal.

Setting a message's persistence

In JMS a message's persistence is controlled by its delivery mode property. You configure the delivery mode of the messages produced by a JMS provider by setting its deliveryMode attribute. The value you provide for the deliveryMode attribute is used to set the JMS message's JMSDeliveryMode property.
JMS implementations support two delivery modes: persistent and non-persistent.
Persistent messages can survive a shutdown of the JMS broker. This is the default setting for JMS messages. You can specify persistence by setting the endpoint's deliveryMode attribute to 2. This setting corresponds to DeliveryMode.PERSISTENT.
Non-persistent messages are lost if the JMS broker is shutdown before they are delivered. You can specify non-persistence by setting the endpoint's deliveryMode attribute to 1. This setting corresponds to DeliveryMode.NON_PERSISTENT.

Setting a message's life span

You can control how long messages persists before the JMS broker reaps them by setting the endpoint's timeToLive attribute. The value is the number of milliseconds you want the message to be available from the time it is sent. The default behavior is to allow messages to persist forever.
The value of the timeToLive attribute is used to compute the value for the message's JMSExpirary property. The value is computed by adding the specified number of milliseconds to the time the message is created.

Enforcing configured values

By default, a JMS provider endpoint will allow the JMS provider to set these values to default values and ignore any values set through the configuration. To override this behavior, you need to set the endpoint's explicitQosEnabled attribute to true.

Example

Example 16.5, “Setting JMS Provider Endpoint Message Properties” shows configuration for a JMS SOAP provider whose messages have a priority of 1.

Example 16.5. Setting JMS Provider Endpoint Message Properties

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
       ... >
  ...
  <jms:soap-provider wsdl="classpath:widgets.wsdl"
                     destinationName="widgetQueue"
                     connectionFactory="#connectionFactory"
                     priority="1"
                     explicitQosEnabled="true" />
  ...
</beans>

16.4.2. JMS Message Optimization

Overview

JMS message producers are able to provide hints to the JMS broker about possible message optimizations. These hints include whether or not JMS message IDs are required and whether or not timestamps are needed.
By default, Red Hat JBoss Fuse JMS provider endpoints require that messages have IDs and timestamps. However, if your application does not require them you can instruct the endpoint to inform the JMS provider that it can skip the creation of IDs and time stamps. The JMS provider is not required to take the hint.

Message IDs

By default, a JMS message broker generates a unique identifiers for each message that it manages and places the ID in the message's header. These IDs can be used by JMS applications for a number of purposes. One reason to use them is to correlate request and reply messages.
Message IDs take time to create and increase the size of a message. If your application does not require message IDs, you can optimize it by configuring the endpoint to disable message ID generation by setting the messageIdEnabled attribute to false.
Setting the messageIdEnabled attribute to false causes the endpoint to call its message producer's setDisableMessageID() method with a value of true. The JMS broker is then given a hint that it does not need to generate message IDs or add them to the messages from the endpoint. The JMS broker can choose to accept the hint or ignore it.

Time stamps

By default, a JMS message broker places time stamp representing the time the message is processed into each message's header.
Time stamps increase the size of a message. If your application does not use the timestamps, you can optimize it by configuring the endpoint to disable time stamp generation by setting the messageTimeStampEnabled attribute to false.
Setting the messageTimeStampEnabled attribute to false causes the endpoint to call its message producer's setDisableMessageTimestamp() method with a value of true. The JMS broker is then given a hint that it does not need to generate message IDs or add them to the messages from the endpoint. The JMS broker can choose to accept the hint or ignore it.

16.4.3. SOAP Specific Configuration

Overview

The SOAP provider has two specialized configuration properties. One controls if the endpoint needs to use the JBI wrapper to make messages consumable. The other determines if the endpoint checks its WSDL for compliance with the WS-I basic profile.

Using the JBI wrapper

There are instances when a JBI component cannot consume a native SOAP message. For instance, SOAP headers pose difficulty for JBI components. The JBI specification defines a JBI wrapper that can be used to make SOAP messages, or any message defined in WSDL 1.1, conform to the expectations of a JBI component.
To configure a SOAP provider to wrap messages in the JBI wrapper, you set its useJbiWrapper attribute to true.
Example 16.6, “Configuring a SOAP Provider to Use the JBI Wrapper” shows a configuration fragment for configuring a SOAP provider to use the JBI wrapper.

Example 16.6. Configuring a SOAP Provider to Use the JBI Wrapper

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
       ... >
  ...
  <jms:soap-provider wsdl="classpath:widgets.wsdl"
                     destinationName="widgetQueue"
                     connectionFactory="#connectionFactory"
                     useJbiWrapper="true" />
  ...
</beans>

WSDL verification

The WS-I basic profile is a specification describing the minimum set of requirements for a Web service to be considered interoperable. The requirement of the specification mostly constrain the binding of messages into SOAP containers.
By default, SOAP providers will verify that their WSDL complies to the WS-I basic profile before starting up. If the WSDL does not comply, the endpoint will not start up.
If you want to skip the WS-I basic profile verification, you can set the provider's validateWsdl attribute to false.