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.
