Full implementation of the JMS selector specification 1.1.
The framework is transport neutral - it can work with any messaging protocol. In fact, the framework can and should be used in any context where there is a need to evaluate conditional expressions based on a subset of the SQL92 conditional expression syntax. For example, the framework could be used to select data from a datastore that does not natively support complex selection. Or, the framework could be used to select data items from a application cache at run-time.
The framework provides built-in support for JMS and TIBCO/Rendezvous . This support is provided in the form of value provider classes that are able extract identifier values for JMS and TIBCO/Rendezvous messages. Applications are free to write their own value provider classes for other protocols and/or for application-specific requirements.
The framework provides extremely high performance and minimal object creation. In performance tests against the leading JMS implementations this framework was at least 4 times faster than the closest contender.
Applications frequently require message filtering based on the content of the message instead of just the message header and properties. In such cases, applications have to be modified to publish message content fields as properties for the sole purpose of filtering. To address this requirement, the framework allows selection based on message content including nested messages (when supportd by the specific protocol and implementation). For example, TIBCO/Rendezvous and TIBCO/JMS both support nested message fields.