[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1518) Support for XPath filtering on JMS subscriptions

[Tim Fox (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1518:
---------------------------------

    Fix Version/s: 2.1.0.beta


> Support for XPath filtering on JMS subscriptions
> ------------------------------------------------
>
>                 Key: JBMESSAGING-1518
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1518
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Lisa Winkler
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> Does JBoss Messaging have any expectations to support using XPath predicates (instead of SQL) in a message selector on a JMS message consumer?  
> Basically, we would like to perform as much filtering as possible on the server side and/or within the JMS infrastructure, to avoid clients having to create business logic to actively filter their received messages.
>  
> BACKGROUND:
> We are using JBoss SOA Platform v4.3.  We are developing a set of ESB services that will provide some basic processing, transformation, and routing for messages among heterogeneous clients.  Our internal message format (inside the ESB message) includes XML metadata and arbitrary payload.  The XML metadata contains (among other application-specific data) the who/what/when/where type of information about the payload.  Clients will typically be interested in only a small subset of the available messages, based on the information in the XML metadata.  
>  
> As part of our design, we want the ESB to provide the "matchmaking" between consumers of information and the data which meets their predicate.  The subscribers, at run time, assert their predicates stating what data they are interested in.  For example, a subscriber may state in XPath that they want data within a geographical area of interest which meets a certain timeliness standard and contains some keyword like "TEL".  All of that is expressed in XPath and pushed to the ESB which uses it to filter data on behalf of that client.
>  
> The advantage of this approach is that the publishers and the subscribers don't have to implement any filtering business logic - that logic exists in one place in the ESB.
>  
> Here is where we get to the question.  It would be most efficient if we could enforce that predicate in JMS so that the delivery of the data could all be within one topic.  If two subscribers have two predicates, no problem, JMS will filter that data to them even though they are on the same topic.  However, if JMS doesn't support XPath, then we have to either:
> 1 - assign a unique topic or queue per subscriber, or 
> 2 - implement a complex mapping of XPath to SQL (we implemented this on a similar project, but doing so required a good amount of business logic), or 
> 3 - use a content based router transport protocol in the ESB which does accept XPath
> We are essentially using a combination of 1 and 3 to implement this today, but this is less efficient because we have to essentially duplicate the subscription management capabilities of JMS to route based on subscription predicate. 
> Note:  we've discussed this issue with Burr Sutter (bsutter at redhat.com) who recommended that we submit a feature request.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira