No, I don't think you've misunderstood anything. I'd use embedded Camel routes on the test broker to forward messages between the appropriate queues on the two brokers. This obviously means that you have to have different configurations on the two brokers, but I think that's unavoidable and the scope of these differences is pretty limited. It's the same concept as running your own client, but you don't have to worry about monitoring it separately.
Tim On Apr 28, 2017 4:46 AM, "Chro" <chromoman...@gmail.com> wrote: > I have a specific question at the end of this, but I've read a lot of > documentation and FAQs and I am posting to ask if there is something I've > missed, or if my understanding is wrong. So I have to summarise what I > think > I've understood, and explain the problem -- I'll keep it as short as I can, > but it's still quite long. > > I'm working on a system being developed using a micro service architecture. > We are using ActiveMQ as the message broker. The volume of messages is low > enough that one broker, running on one of the machines, should easily be > enough for all the services. I could be wrong, but let's assume one is > enough. > > I've been asked to look into how we connect brokers to pass messages > between > them. "Why?" you ask: I just said one broker was enough. I'll come to why > in > a moment. > > As far as I can see, from the documentation, there are only two ways to > connect brokers: > * master/slave, for high availability (messages are replicated in a > number > of machines) > * store and forward, messages are routed via several brokers, e.g. for > communicating between different LANs, each with its own broker > > The second is close to what I need, but not right for it, because the above > assumes that the same queue (or topic) on two different brokers is > essentially the same queue: it is a distributed queue. > > This is not appropriate when we want to duplicate a "live" or production > micro-service architecture in a test environment. In this case, ideally we > would like all the configuration data (e.g. properties or XML files) to be > identical, so the same queue name in production is really a different queue > in test. The live and test systems should be completely separate. > > "So what's to stop you?" you ask. The problem is that, typically (and in > our > case), some of the live services need to talk to external, third party, > systems and cannot be replicated in the test environment. Creating mock-ups > would be expensive, so we want to "cheat" by allowing some leakage between > the live and test systems, as follows: > > Suppose this live service is called S, and we send messages to it on a > queue > called Squeue. On the test system, we want the same test service, S, > listening to Squeue (on the test broker) - but S won't work on the test > system. What we can do instead, is run a copy of S, listening to a > different > queue (let's call it Tqueue) on the live server. > > This isn't really part of the live system: it's part of the test system. > Specifically the live configuration files don't need to know about it. What > I want now, is for messages sent to Squeue on test, to be forwarded to > Tqueue on the live system. (Similarly for replies.) > > There is nothing to stop a process connecting to two different brokers, so > I > can write a tiny test service to do this (a dummy S service in test) but -- > specific question -- is this the best solution? > > Have I missed something? Would you do it differently? > > Thanks for any comments/advice. > > Chro. > > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/broker-to-broker-testing-scenario-tp4725331.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
