[JMS_SPEC-41] Support topic hierarchies Created: 05/Aug/11  Updated: 08/Jan/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-underreview

 Description   

This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

It is proposed that the JMS specification supports "topic hierarchies". These are also known as subject hierarchies or wildcard subscriptions.

The JMS 1.1 specification states that a topic is a "well-known node in a content-based hierarchy" but does not specify how this hierarchy is used, how topics are named, or define any special functionality to operate on more than one node of the hierarchy at the same time.

It is proposed that new features are added to JMS to explicitly support the use of topic hierarchies. More detailed proposals will follow: this JIRA issue is a placeholder.

Most JMS vendors and (and other pub/sub products) already support topic hierarchies, and they are integral to a variety of standards, including AMQP, Web Services Event Notification, and the Bayeaux protocol. They provide an intuitive solution for optimized message filtering, routing, and replication. Support for topic hierarchies would also be helpful for simplifying the integration of JMS applications into messaging environments that already depend on topic hierarchies.



 Comments   
Comment by axel_podehl [ 08/Jan/13 ]

I would think it'll be difficult and cumbersome to specify and use a provider-unspecific topic hierarchy. The ways wildcards actually work with different JMS providers are more diverse than you would initially think (or hope).

E.g. MQSeries Topics:

"Sport/#/Results" matches "Sport/Football/Spurs/Results"
while
"Sport/+/Results" only matches "Sport/Football/Results"
but also
"Sport/#" matches "Sport"

with TIBCO EMS and ActiveMQ, separators (. instead of /) and wildcards are different,
but also their meaning:

"Sport.>.Results" is invalid
"Sport.*.Result" would work as well
"Sport.>" does not match "Sport"

Also leaving it up to individual providers on how exactly topic names or hierarchies work is a great differentiator, leaving room for innovation. A simple String as topic name can be used to define additional properties of a topic on the fly, e.g. in ActiveMQ: "temp-queue://TEST?consumer.prefetchSize=10"

Nice-to-have though, when writing provider-unspecific code, would be these methods:

public boolean Destination.isWildcard()
public boolean Destination.isMatching(String wildcard)

Generated at Fri Dec 09 04:46:46 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.