Part 5 - Messaging Best practices - TIBCO BW Best Practices

This is Part 5 of the series on Best practices for TIBCO BusinessWorks (BW) 5.x platform. You can check out previous parts at Part 1, Part 2, Part 3 and Part 4. For evaluating against these and more best practices, do a code review of your BW 5.x projects or EAR files using our free online version at BW5 Code Scanner

This post covers the best practices about messaging best practices

Message Selectors

A message selector evaluates to a boolean that helps the JMS provider determine whether the message should be delivered to the client or not. When a client retrieves a message from a destination, the selector expression is evaluated on each and every message. Even when the server keeps track of the evaluated expressions for the messages to reduce subsequent evaluation, each message retrieval begins a new search on the destination. The computational complexity of retrieval is thus O(n), where n is the number of messages in the queue. When there are a large number of messages on the destination, this can cause significant performance impact on EMS. For every message consumer which uses different selectors the JMS provider needs to perform the search.

Moreover, if the consumers are off-line for an extended period of time and messages pile-up on the server side, consumers with selectors will be impacted as the JMS provider must search through all the messages to match the selector criterion which impacts the performance of both the JMS provider and the consumer.

Use of client-side JMS message selectors is discouraged. As an alternative, use EMS configuration that bridges the original destination to a separate queue for each client with message selectors being used on the bridge.

Messaging Best Practices

Following messaging best practices are recommended for an enterprise.

• For publish-subscribe pattern, if message loss is not tolerable for any subscriber, use topic to queue bridge and create a queue listener for that subscriber. Use durable subscribers cautiously. Load balancing may not be seamless the durable subscribers even though shared subscription was introduced in the recent JMS versions
• For messages of significant size, enable message compression by setting the property JMS_TIBCO_COMPRESS to true. This lets the client side libraries compress the messages and reduce the load on EMS since they are stored in a compressed format at the server.
• Based on the SLA for message processing, set the expiration property on the message. The expiration can also be set at the destination level. The expiration set on the destination overrides the value on the message.
• For messages that hold significant business value, set the property JMS_TIBCO_PRESERVE_UNDELIVERED to true. When these messages expire, they are transferred to $sys.undelivered queue 
• When the acknowledgment mode is Client or Explicit Client Acknowledge, ensure that all error handling paths have a confirm path or have max redelivery set up on the destination.
• Use JMS properties extensively. The message traffic across routes can be reduced by using route selectors on JMS properties. JMS properties also provide the ability to route messages internally within the process scope with little concern for payload.
• Whenever applicable, consider using headers that define the processing logic for the message since parsing the data is expensive.

In Summary

Do not use client side selectors. Use topics bridged to queues with selectors. Use compression for large messages and JMS expiration for messages based on SLA.