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.)
+2
A:
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.
cletus
2009-11-13 09:08:57
Is that right? When the message arrives at the browser a new connection is opened?
djna
2009-11-13 09:11:37
The client should be programmed to open a new connection. If it doesn't the server has no way of communicating with the client.
cletus
2009-11-13 09:25:02
I'm sorry. Having trouble understanding. The client has opened an long-lived HTTP connection. Server sends messages up there - right? You then say "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." Sounds like we are opening a second connection. Why? The message we just received contained the data we want, doesn't it?
djna
2009-11-13 10:01:59
The new connection is to listen for the next message. The idea here is to keep an open connection to the server at all times that is just waiting for the server to do something with it. This allows the server to (in effect) initiate communications. Once the server uses the connection to send a message, a new connection needs to be opened up for the next message. All of this assumes we have a client that the server needs to be able to push data to. The alternative is to poll for changes at regular intervals, but that may create a delay in the event reaching a client.
Kris
2009-11-13 10:12:49
(Apologies for labouring the point, but this simply doesn't correspond to my experience). The connection is long lived, server squirts up data periodically, browser thread sucks that data and displays it. I don't see why we need to keep opening more connections. Right now, I've got real-time measurements updating in my browser, and just one connection (I think).
djna
2009-11-13 10:30:43
A:
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.
djna
2009-11-13 09:16:21
A:
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.
Kris
2009-11-13 10:20:08
A:
Atmosphere and DWR are both open source frameworks that can make Comet easy in Java.
Jason Gritman
2009-11-13 12:32:07