[JMS_SPEC-41] Support topic hierarchies Created: 05/Aug/11 Updated: 08/Jan/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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.
|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"
with TIBCO EMS and ActiveMQ, separators (. instead of /) and wildcards are different,
"Sport.>.Results" is invalid
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()