Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 26 Sep 2012 22:28:20 -0700 (PDT)
From: kmansari <kamran_ansari@yahoo.com>
To: users@activemq.apache.org
Message-ID: <1348723700453-4657072.post@n4.nabble.com>
Subject: Concerns about ActiveMQ implementation over the WAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=99s refe=
r to each
cluster as a =E2=80=9CJob Site=E2=80=9D (the number of these =E2=80=9CJob S=
ites=E2=80=9D 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, i=
t
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 don=
e
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
=E2=80=9CMessage Bus=E2=80=9D. 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 (mos=
t
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.=09*Performance Concern:* A Message Bus doesn=E2=80=99t perform well on t=
he WAN.
After doing a search on the forum, it seems like a =E2=80=9CNetwork of Brok=
ers=E2=80=9D
topology would be able to address the performance related concern. Are ther=
e
any more arguments besides the =E2=80=9CNetwork of Brokers=E2=80=9D to alle=
viate the
performance concerns?

2.=09*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 =E2=80=9Cexposes the message bus to the internet, thus making i=
t
vulnerable to security threats=E2=80=9D.  Among the solutions proposed to m=
itigate
the risk:
a.=09Use a web service instead of message bus.
b.=09Implement 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/Concern=
s-about-ActiveMQ-implementation-over-the-WAN-tp4657072.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.