Best solution for Java HTTP push (messaging) [clos

Question

We want to push data from a server to clients but can only use HTTP (port 80). What is the best solution for messaging? One idea is Comet. Are there other ideas or frameworks which offer lets say JMS over HTTP. (Yes, ActiveMQ supports it too, but waggly IMHO. And JXTA supports it too but the configuration is complicated. Something simple is preferred.)

Answer 1

The simplest solution for many, many reasons is to use a Comet based approach (like you mention). This means the clients (to whom you want to "push" messages) open long-lived HTTP connections. Those connections stay open until they time out or you send the client a message. As soon as either happens the client opens a new connection.

Directly connecting to clients could be problematic for many reasons: they could be behind firewalls that disallow that, they could be behind proxies and so on.

Unless your clients are real servers (in which case you're really the client), have them contact you and send a response to mimic push.

Answer 2

Atmosphere and DWR are both open source frameworks that can make Comet easy in Java.

Answer 3

I created an example app using Comet, Raphael, Bayeux, Java and Maven running PaaS Cloudbees and wrote a blog post about it, hopefully it will be helpful to someone.

http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo

Answer 4

We used COMET in conjunction with JMS using WAS Web 2.0 Feature Pack; in effect the server did the JMS subscribe and COMET-pushed the message to the browser. as a developer it "felt" like the browser was subscribing to JMS. This "just worked" so we didn't look further for alternatives.

I could imagine a pure JavaScript JMS implementation in the browser, using HTTP as a transport but my instict is that this would be very heavyweight. I know of no such implementations.

Answer 5

The alternative approach to those already discussed (i.e. Comet etc.) is to implement polling in the client. The downside of that approach is that you inevitably have a delay from the time of the message/event and until the client receives it. If your application is very sensitive to such delays, polling is out.

If a certain amount of delay (at minimum in the order of a few seconds) is acceptable, polling is less of an abuse of the HTTP protocol. It is also more robust against temporary network troubles as the server by default queues messages and wont get upset if the client isn't available on its schedule.