Friday, March 28, 2014

JMS Message Selectors and OSB

JMS Topics are a good way to keep publishing messages and multiple subscribers can fetch messages based on their criteria. How we define the criteria is one of the main decision points that should be considered while defining the message structure and headers of the message. In one of the implementations done recently there was a requirement where consumers wanted to filter the messages based on a status, that was part of the body .So instead of reading all messages and parsing the status ,they were looking for a way to easily filter the messages.
As per the JMS spec ::
A JMS message selector allows a client to specify, by header field references and property references, the messages it is interested in. Only messages whose header and property values match the selector are delivered. What it means for a message not to be delivered depends on the Message Consumer being used.
Message selectors cannot reference message body values.
A message selector matches a message if the selector evaluates to true when the message's header field values and property values are substituted for their corresponding identifiers in the selector.
A message selector is a String whose syntax is based on a subset of the SQL92 conditional expression syntax. If the value of a message selector is an empty string, the value is treated as a null and indicates that there is no message selector for the message consumer.
A property value may duplicate a value in a message's body, or it may not. Although JMS does not define a policy for what should or should not be made a property, application developers should note that JMS providers will likely handle data in a message's body more efficiently than data in a message's properties. For best performance, applications should use message properties only when they need to customize a message's header. The primary reason for doing this is to support customized message selection
Weblogic customized the message selector for weblogic JMS.
JMS_BEA_SELECT is a built-in function in WebLogic JMS SQL syntax. You specify the syntax type, which must be set to xpath (XML Path Language) and an XPath expression.
    Eg:- JMS_BEA_SELECT('xpath', '/message/status/text()') = ‘REQUEST_SUBMITTED’
But from OSB point of view, the message selector goes by strict JMS spec and the custom Message selector function - JMS_BEA_SELECT is not supported as it is designed to be more generic and needs to communicate with JMS Topics from different vendors. So the only supported options will be to have custom message headers defined on the message and consumers filtering on them, even it means duplicating the fields in header and body of the message.


Vamshi said...


In OSB, we have a scenario, where there are 2 proxy services, listening to a common topic.

Each proxy has a different message selector. What happens to the message which doesn't satisfy any of the message selectors in the above proxy.

we see that the message is not delivered and is lost. is there any way to track these lost messages

George Thomas said...

the messages wont be lost , it will be in the topic.Are you using a distributed topic. If multiple consumers are there and its having different message selectors you can use a distributed queue.