I haven't done this, but believe it should be possible.
But I was surprised to see that your diagram only shows the use of
websockets for the hop from local broker to reverse proxy, and uses TCP
elsewhere. From your description, it sounded like you were intending to use
websockets on all network links; is the diagram wrong? If not, why do some
links use one protocol and others use the other?
Have you considered what will happen when the cloud-based broker goes down,
either unexpectedly (hardware failure, etc.) or due to your choices (e.g.
you choose to roll out a new host with a new version of ActiveMQ)? Do you
need to have (almost) no time where no cloud broker is available to relay
messages (you probably need either a master/slave cluster or a second
independent broker behind the reverse proxy/load balancer), or will you
accept having messages not flow for as long as it takes to bring up a
replacement broker (a single instance is sufficient)? If you broker dies,
do you want its replacement to have access to any messages that were on the
broker at the time it died (you need to send them persistently, and store
them in something that will survive the death of the host), or are you OK
losing those messages forever (local storage is sufficient)?
Your Network of Brokers topology is called hub-and-spoke, and typically the
edge brokers initiate all broker-to-broker connections. Is that your plan?
Note that MQTT over TLS
secured Websockets would be "mqtt+wss://", as I understand it.
Tim
On Wed, May 13, 2020, 10:46 AM BBruhn <benjamin.br...@forcam.com> wrote:
> I need to connect one or several on-premise (client-side) instances of
> ActiveMQ to connect / send data to a single ActiveMQ deployed in a cloud
> environment (server-side). The interface for all connections towards the
> cloud application is a reverse proxy. The on-premise instances might be
> located at different sites.
>
> Because of client-side Firewall restrictions and the server-side (IIoT)
> cloud environment, the connection can only be established via MQTT over TLS
> secured Websockets ("wss://"). The reverse proxy will connect towards its
> ActiveMQ via TPC. The documentation calls this scenario a network of
> brokers. The examples only show configurations with a TCP connection. It
> does mention (https://activemq.apache.org/networks-of-brokers) that other
> connections (network connectors) are possible. In a book, I have seen that
> a
> connection with a reverse proxy inbetween two ActiveMQs is possible. I am
> at
> the early phases of designing an architecture for my thesis, working on a
> bigger system in a software company. I cannot easily test this scenario
> currently.
>
> *Long story short:*
> Has someone experience with successfully deploying the following ActiveMQ
> network of brokers architecture, respectively is this scenario possible?:
>
> Event Producer --(MQTT/TCP)--> ActiveMQ ------\
>
> ------(MQTT/TLS/Websockets)---->Reverse Proxy --(MQTT/TCP)--> ActiveMQ---->
> …
> Event Producer --(MQTT/TCP)--> ActiveMQ ------/
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
