This can be done with ActiveMQ using a hub-and-spoke topology on a network of brokers. The spoke brokers should use duplex connections to the hub so the hub broker doesn't need to enumerate them all.
You can either embed a broker within each client or run standalone brokers at each spoke location. The former is simpler to configure, but has the significant disadvantage that any messages in a client's embedded broker will either be lost (if the client broker doesn't use a persistent store) or unavailable until the client reconnects. If possible, you should use standalone brokers colocated with your clients, to enable that messages are delivered as expected. Tim On Sep 22, 2016 6:34 AM, "Christian Schneider" <ch...@die-schneider.net> wrote: > I am looking for a best practice to communicate between a central system > and several remote systems that are only connected for certain time periods. > > The remote system sends logs to the central system, the central system can > dispatch batch jobs running on the remote system. The job should send > regular heart beats and also report failure or success. > > The core requirement is that all operations should be asynchronous. > > So for example when sending a log event the remote system should not block > even if the connection to the central system is not available at the time. > So I am sure that I will need local queueing and some forwarding mechanism. > > Can this be done with activemq? How would such a setup look like? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
