Addressing Behavior Use Cases [Draft]
—————————————————
1. Destination addresses will be stored in canonical form without prefixes
    ie.  queue:///foo will be stored as name=“foo” type=“anycast”
          topic://bar will be stored as name=“bar” type=“multicast”

2. Addresses must specify a type in the configuration

3. Addresses may be auto-created when the intersection of protocol support, broker-side configuration and user permissions permits

4. [JMS] session.createQueue(“foo”) must be translated to the fully qualified name of “queue:///foo” in the client provider library (or some internal core protocol/api equiv)

5. [JMS] session.createQueue(“queue:///foo”) and session.createQueue(“queue://foo”) and session.createQueue(“foo”) refer to the same address

6. [STOMP and AMQP] will default to “anycast” address type (configurable at broker transport?) during lookup and throw an exception if there is a name collision when using unqualified address name.
    ie. User specifies “blah” and both types exist

7. [MQTT] will default to topic name unless fully qualified to use the queue address (needs research.. MQTT may not allow URI format in topic name)

8. [STOMP, AMQP and other protocols] will support appropriate prefix mapping to their address name format.  For example:  /queue/foo and /topic/foo will be translated to foo  type=“any cast” and foo  type=“multicast” internally

Questions:

Q-0: Does Artemis support the separation of queue-like and topic-like addresses?  ie.. foo type=“anycast” and foo type=“multicast” can co-exist and are distinct addresses.

Q-1: What address type should be created by default for STOMP, AMPQ and MQTT unqualified addresses?

Q-2: What address type should be looked up by default for STOMP, AMPQ and MQTT of unqualified addresses?

Q-3: How would queue://$broker/$host fully qualified address names be supported in STOMP, AMQP and MQTT?

Discussions:

D-1: jbertram would like to table support for Q-3 fully qualified names (host+destination) until after ARTEMIS-780 is done. The reasoning is to keep things simple and avoid uncertain future complexity.

D-2: mattrpav recommends planning for fully qualified names before 2.0 is released (doesn’t need to be part of 780) in order in order to avoid any impacts post-2.0. The reasoning is that in order for Artemis to compete as a replacement with majority of EMS products (IBM MQ, Tibco EMS, etc) host+destination routing is a must-have.