My sincere apology if this has been already addressed elsewhere. I am working on an architectural initiative, the scope of which is pretty broad compared to what I have done in the past. I thought it prudent to run it by the experts and others who may be more experienced than me in this domain.
The system in question is a distributed one, spanning multiple continents. It involves clusters of clients (about 100 or so), running across a mix of OS/platforms, in each continent. For sake of simplicity, let’s refer to each cluster as a “Job Site” (the number of these “Job Sites” is expected to grow over time). Each client in a given cluster performs a set of tasks, requested by a central server. These are long running tasks that could take from a few hours to a couple of days. Once a client is done with its job, it has to communicate the results of the job (an XML file, 5K to 10K in size) to the central server. The client needs a reliable and guaranteed way to convey the results back to the central server, because as soon as it is done with its tasks, it has to reboot and get ready for the next job that might be coming its way. The central server scales well and has the capacity to handle potential spikes in the incoming traffic. I concluded that it made sense to implement the communication layer using a “Message Bus”. ActiveMQ, in particular, piqued my interest primarily because it is cross platform, robust, reliable, and scales well. My proposal articulated that the clients will communicate with the ActiveMQ broker (most likely in a client-server topology), directly, without an intermediate web-services interface sitting in front of the message bus. Some stakeholders in my team have expressed the following concerns: 1. *Performance Concern:* A Message Bus doesn’t perform well on the WAN. After doing a search on the forum, it seems like a “Network of Brokers” topology would be able to address the performance related concern. Are there any more arguments besides the “Network of Brokers” to alleviate the performance concerns? 2. *Security Concern:* This is the bigger of the two concerns raised. The lack of a web-services interface for the clients to interact with the message bus “exposes the message bus to the internet, thus making it vulnerable to security threats”. Among the solutions proposed to mitigate the risk: a. Use a web service instead of message bus. b. Implement a web-service layer in front of the message bus. In my mind, that defeats the whole purpose of using a message bus in the first place. One might as well throw away the message bus and completely replace it with a REST/SOAP web service interface. Do the aforementioned concerns really have any merit? How are others implementing ActiveMQ based solutions on the WAN? Any other issues that I should be aware of or concerned about? Your thoughts are greatly appreciated. Thanks much! -Kamran -- View this message in context: http://activemq.2283324.n4.nabble.com/Concerns-about-ActiveMQ-implementation-over-the-WAN-tp4657072.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
