Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      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.

        Activity

        Nigel Deakin created issue -
        Nigel Deakin made changes -
        Field Original Value New Value
        Tags eg eg prd-planned
        Nigel Deakin made changes -
        Tags eg prd-planned eg
        Nigel Deakin made changes -
        Tags eg eg pd20-planned
        Nigel Deakin made changes -
        Tags eg pd20-planned eg
        Nigel Deakin made changes -
        Tags eg eg pd20-forreview
        Nigel Deakin made changes -
        Tags eg pd20-forreview eg
        Nigel Deakin made changes -
        Tags eg
        Nigel Deakin made changes -
        Tags pd20-underreview
        Hide
        axel_podehl added a comment -

        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)

        Show
        axel_podehl added a comment - 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)

          People

          • Assignee:
            Unassigned
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: