A hub-and-spoke topology is one of the topologies often suggested for ActiveMQ 5.x networks of brokers. See for example https://access.redhat.com/documentation/en-us/red_hat_amq/6.1/html/using_networks_of_brokers/fmqnetworkstopologies#FMQNetworksHubSpoke and https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/network-of-brokers.html#nob-topologies-hub .
I personally haven't done it for Artemis but see no reason it would be any less appropriate for your use case. It does seem like an appropriate choice for allowing your teams the independent control you say they want, though I don't know if a single Artemis cluster could be configured with RBAC permissions that would control teams' access to private vs. shared destinations. If that were possible, it might be more flexible since it could allow access for certain destinations to be limited to some but not all teams whereas the hub-and-spoke approach really only supports team-private or public. But someone who knows Artemis better than me will have to say if that's possible. I didn't follow why a cluster would use 3 VMs to run 2 replicated brokers; what's the other VM for? Tim On Thu, Jan 20, 2022, 12:59 AM Didier Clabaut < didier.clab...@integrationdesigners.com> wrote: > Hi, > > My client is looking at Artemis MQ for messaging. They have different > teams who want to be able to maintain their own queues and topics, without > other teams having any access to their setup. I'm thinking of suggesting a > hub-and-spoke architecture between clusters. > > Each cluster would consist of 3 VM's with two broker instances > interconnected as a symmetrical cluster, they also have a static connection > to a central hub cluster. Most of the messaging would occur inside the team > cluster, but communication between teams would pass via the central hub > cluster (max-hops=2). > > I can't find any references to such an architecture, making me wonder if > it's a good idea. Has anyone done such an architecture? > > Kind regards, > > Didier >
