As wildfirexy suggests, without saying so in these words, "it depends."
Not only do you need to factor in the type of application and response requirements (such as embedded vs. interactive) but it's also important to assess how often the expected data will become available vs. how often to poll (if you consider a polling approach) and how expensive the network round-trip is in the runtime environment.
How many clients will be polling? A polling solution that works well with a handful of clients may not scale well to hundreds or thousands or more clients.
The polling approach can be very network-unfriendly if the polling interval is significantly faster than the actual arrival rate of the data. In that case polling generates many network messages that return no new information. Of course, no one would purposefully set up this sort of overly-aggressive polling frequency but in many situations you cannot predict how often new data will be available and therefore how often to poll.
I have also seen applications with dynamically adaptive polling rates. The algorithm polls less and less frequently if several successive requests return no new data and polls more and more frequently if successive requests do return new data. Well-designed approaches that use this technique will need to limit how fast or slow the polling occurs to avoid flooding the network and the server with too many requests or, in the other extreme, being too slow to discover when new data is available.
As with many application design decisions, the "best" choice is going to depend on the specific requirements in a particular case. Most apps I've come across would be best handled with a "push" approach, due to high network costs associated with unneeded messages. Having said that, the predictability aspects of a "pull" approach as wildfirexy mentioned is a very interesting twist on this discussion.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=234586