Matt Pavlovich created ARTEMIS-1880:
---------------------------------------
Summary: Multi-broker virtual destination use cases
Key: ARTEMIS-1880
URL: https://issues.apache.org/jira/browse/ARTEMIS-1880
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Reporter: Matt Pavlovich
See discussion here: [GitHub
PR-1820|https://github.com/apache/activemq-artemis/pull/1820#issuecomment-360989445]
The ability for the broker to define server-side virtual destinations
(generally pub-sub-- aka Virtual Topics) enables two key multi-broker messaging
patterns.
Copy-pasta from the GitHub PR comments:
[@michaelandrepearce|https://github.com/michaelandrepearce] the IBM MQ scenario
I was referring to was the ability to use a named queue to back a topic
subscription, not cloned subscriptions-- this provides the separation of
producers from consumers in terms of "its a different destination". This
enables better wild card management for permissions and other access features
to destinations. ie.. topic://ORDERING.** and queue://BILLING.**
I agree JMS 2.0 topic subscriptions solve the "same broker" and "same
destination" use case for application-side ability to dynamically add
additional consumers to a message flow without broker config or existing
producer and consumer(s) impacts.
Note: on the exclusive consumer part, it sounds like Artemis has a gap vs 5.x
in that the exclusive consumer config is server-side only (separate issues
raised as [ARTEMIS-853] and [ARTEMIS-856]).
The key feature in the broker-to-broker message scenarios is that the
publishing destination is different than the consuming destination(s). In
ActiveMQ 5.x, this allows for two important multi-broker messaging patterns, as
well as enable the network of broker destination filtering (include / exclude),
client permissions and destination policy mapping via wild card syntax sugar
for administrators. See attached graphics
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)