What's the best way to notify a non-web application about a change on a web page?

Question

Let's say I have two applications which have to work together to a certain extent.

1. A web application (PHP, Ruby on Rails, ...)
2. A desktop application (Java, C++, ...)

The desktop application has to be notified from the web application and the delay between sending and receiving the notification must be short. (< 10 seconds)

What are possible ways to do this? I can think of polling in a 10 second interval, but that would produce much traffic if many desktop applications have to be notified. On a LAN I'd use an UDP broadcast, but unfortunately that's not possible here...

I appreciate any ideas you could give me.

Answer 1

I don't know exactly what to do to achieve your task but I can suggest to create a windows service at the desktop application PC.

This service checks the web application every interval of time for new changes and if changes occurred it can run the desktop application with notification that there is a change in the web application and in the web application when any change occurrs you can response with acknowledgment

I hope that this may be useful I didn't try it exactly but I am suggesting using like this idea.

Answer 2

I can see two ways:

• Your desktop application polls the web app
• Your web app notifies the desktop application

Your web app could publish an RSS feed, but your desktop app will still have to poll the feed every 10 s.

The traffic need not be huge: if you use an HTTP HEAD request, you'll get a small packet with the date of the last modification (conveniently named Last-Modified).

Answer 3

I think the "best practice" here will depend on the number of desktop clients you expect to serve. If there's just one desktop to be notified, then polling may well be a fine approach -- yes, polling is much more overhead than an event-based notification, but it'll certainly be the easiest solution to implement.

If the overhead of polling is truly unacceptable, then I see two basic alternatives:

1. Keep a persistent connection open between the desktop and web-server (could be a "comet"-style web request, or a raw socket connection)
2. Expose a service from within the desktop app, and register the address of the service with the web-server. This way, the web-server can call out to the desktop as needed.

Be warned, though -- both alternatives are chock full of gotchas. A few highlights:

• Keeping a connection open can be tricky, since you want your web-servers to be hot-swappable
• Calling out to an external service (eg, your desktop) from a web-server is dangerous, because this request could hang. You'd want move this notification onto a separate thread to avoid tying up the webserver.

To mitigate some of the concerns, you might decouple the unreliable desktop from the web-server by introducing an intermediary notification server -- the web-server could post an update somewhere, and the desktop could poll/connect/register there to be notified. To avoid reinventing the wheel here, this could involve some sort of MessageQueue system... This, of course, adds the complexity of needing to maintain the new intermediary.

Again, all of these approaches are probably quite complex, so I'd say polling is probably the best bet.

Answer 4

A layer of syndication would help to scale out the system.

The desktop app can register itself with a "publisher" service (running on one of several/many machines) This publisher service receives the "notice" from your web app that something has changed, and immediately starts notifying all of its registered subscribers.

The number of publishers you need will increase with the number of users.

Edit: Forgot to mention that the desktop app will need to listen on a socket.