Good call, sounds like a plan. Here is the link and a copy of the latest
set of my notes trying to do the same.
ref: http://pastebin.com/0WaMT8Yx
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. Destinations must specify a type in the configuration
3. Destinations 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 destination
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 destination 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
destination name)
8. [STOMP, AMQP and other protocols] will support appropriate prefix
mapping to their destination 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. (Not currently the behavior)
Q-1: What destination type should be created by default for STOMP, AMPQ
and MQTT unqualified addresses?
Q-2: What destination type should be looked up by default for STOMP,
AMPQ and MQTT of unqualified addresses?
Q-3: How would queue://$broker/$host fully qualified destinations 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.
On 11/18/16 11:29 AM, Martyn Taylor wrote:
All,
I think we need to take a step back here and try to capture all the use
cases discussed thus far, we've had a few use cases outlined here and
plenty of discussion @ #apache-activemq channel. I think it's difficult to
discuss solutions until everyone is on the same page when it comes to the
requirements.
I'll start pulling this together, and reply here once I am done.
Thanks for all the input so far.
On Fri, Nov 18, 2016 at 4:00 PM, Matt Pavlovich <[email protected]> wrote:
No. What I am thinking is that all addresses are prefixless. What you are
really saying when you say “queue://foo” is not that I want to
send/consume
to/from an address “queue://foo” but that you want to send/consume to/from
an address named “foo” and that you expect queue semantics on that
address.
If you don’t specify semantics with the address name. For example, let’s
say in MQTT you send to “foo”. This message would be sent to 1 consumer
that have specified “queue://foo” and all consumers that specified
“topic://foo”. As far as Artemis is concerned the address is just "foo".
The prefixes are added in the clients, and used by the protocol managers
to
ask Artemis for certain behaviours.
How do you see this use case working out? If a JMS client sends a message
to session.createQueue("foo") and Artemis auto-creates a "foo"
type="anycast". Then two MQTT clients (MQTT being topic-based) come around
a subscribe to "foo" do the MQTT clients round-robin the data or each get a
copy of the message?.
Can we shelve this for now and pick it up once we have outlined all the use
cases.
