-2

Imagine a (HipChat-like) chat application, featuring private and multi-user chats, offline messages, status tracking, history search and so on. The frontend will be JavaScript application using WebSockets; the backend is going to be JavaEE7-based. With the above, do you think it's a good idea to use JMS for internal processing, with each peer being a JMS client, chatroom being JMS topic etc.? I suppose that it will let us not reinvent the wheel by delegating multiple functions to JMS (asynchronous broadcasts, message archiving, offline message storage and delivery, etc.)

On the other hand, JMS is more about integration, asynchrony and loose coupling between components. Do you think it will suit the needs of a chat service?

P.S. It is a requirement that the application does NOT use external infrastructure like Jabber/XMPP.

Martin Schmidt
  • 189
  • 8
  • You don't need anything as heavyweight as JMS for this. Just use TCP. – user207421 Oct 21 '14 at 00:31
  • TCP is an OSI Level 4 protocol, while JMS is a messaging infrastructure; please be more concentrated. In our case _transport_ technology is already chosen (WebSocket). What I'm asking about is message _processing_ technology. – Martin Schmidt Oct 21 '14 at 02:14

1 Answers1

0

A (probably) conflicting property of JMS is that you can't create topics programatically after deployment. I.e., with single JMS topics backing single chatrooms, you'd have to create chatrooms upfront and can't rename them or create new chatrooms on-the-fly. I would therefore think that JMS is not a good fit.

Alexander Langer
  • 2,883
  • 16
  • 18
  • Seems like [Session.createTemporaryTopic()](http://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createTemporaryTopic%28%29) still can do the trick. – Martin Schmidt Oct 21 '14 at 08:42
  • So you want all your chat rooms be gone when there is a slight network outage? – Alexander Langer Oct 21 '14 at 08:46
  • You mean "power outage"? :) Network outage won't bring JMS broker down, only disconnect WebSocket endpoints. But you're right, chatrooms created this way will have temporary nature. – Martin Schmidt Oct 21 '14 at 08:59
  • See, e.g., http://activemq.apache.org/how-can-i-support-auto-reconnection.html and this related question: http://stackoverflow.com/questions/6432672/activemq-how-to-handle-broker-failovers-while-using-temporary-queues – Alexander Langer Oct 21 '14 at 09:01