In article <94fcfac6-eff5-4e84-956a-8a7970867867@googlegroups.com>,
me2 <winona_whitener@yahoo.com> wrote:
I am a newbie to JMS and would appreciate some advice.
Has anyone compared JMS to socket programming? If I have N number of clients
that need to connect to and send messages to 1 server, what is the
comparison? I would guess that sockets--direct from a client to the
server--would be the fastest for speed and maybe take the least bandwidth.
But I would expect that there would only be negligible size increases for the
JMS overhead once the connection was established and I would expect that a
pub-sub topic would be able to smoke through sending the N number of clients
messages, rather than loop through the connections/sockets and sending the
message to each of them.
Has anyone else looked at this? I'm going through the exercise to set up a
JMS server, but I thought maybe someone else could point me in the right
direction.
JMS is about topic management, queue management, message persistence,
and reliable distribution in a complex environment prone to failures.
If you don't need any of that, like a log host, you'll be much happier
with a plain socket. If you do need that stuff you probably want a JMS
implementation rather than writing it yourself.
JMS services are typically very heavy weight. Memory and disk space are
needed to buffer data to nodes that temporarily fall behind or go
offline. Configuration can take a while too.
JMS is just an API. Different message queue software comes
Clustering, persistence, transactions etc. are optional