[
https://issues.apache.org/jira/browse/ARTEMIS-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated ARTEMIS-1880:
------------------------------------
Attachment: artemis-multibroker-uc1.png
artemis-multibroker-uc2.png
> 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
> Priority: Major
> Attachments: artemis-multibroker-uc1.png, artemis-multibroker-uc2.png
>
>
> 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)
