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)

Reply via email to