Greetings, I have been investigating JMS, and in turn HornetQ, this past week as a solution for upgrading our existing product infrastructure. I've already reviewed most of the user manual and examples, but some aspects are still unclear.
Without going into too much detail, I have uploaded an abstract design here. http://www.tiikoni.com/tis/view/?id=f2be598
Essentially we have thousands of clients and we manage and deploy our software from a central location within our corporate network.
I'm proposing clustering HornetQ servers on our corporate side, while our clients have their own HornetQ server. What concerns me is the configuration behind the queues, topics and core bridges for the internet connections.
Here are some use-cases that concern me:
1) Starting on the client side, application 1 pushes messages to the respective queues on the client hornetQ server. It then bridges it to our corporate HornetQ cluster, which we consume and store in our enterprise database.
- This seems straightforward, I believe the only way to achieve this is to specify the hosts in the cluster explicitly on each client hornetQ server (since it's over the internet we can't use any form of auto discovery), a minor concern is if we add more servers to the cluster, we need to upgrade all of our clients HornetQ configurations. One option of pushing those updates out would be via spacewalk. Am I missing any other alternative?
2) Customers make changes to their software via the central administration web interface. Our application administration console produces an update message to our cluster.
- These messages will usually be for a specific client, should these be posted to an application specific response queue? Will each client require it's own queue since there is no guarantee the intended client will be available (ie: network failure)? Or should we just be posting to a topic, even though only one client will need it?
- How do the core bridge configurations work going back to each of our clients? Do we need to configure a remote-connector for each client and then a core bridge referencing each remote connector? I fear this would produce thousands of XML configurations and be unmanagable.
3) A client starts up and requests its application code from our Calgary server.
- It would post its initialize message to it's hornetQ server, which would relay it to the cluster and then our Calgary application consumer.
- We would construct it's code in a large message and push it to the cluster, which would then transfer it to the client, does this impact the implementation of use-case #2?
This turned into a longer message than I thought, sorry about that... any advice on if and how we should integrate JMS/HornetQ would be appreciated; or maybe I'm overcomplicating this whole thing. Thanks!