If you're wondering how to handle browser-server information flow, especially when dealing with web remoting, you've come to the right place. This article, the first of a multi-part series, discusses call tracking; future articles in the series will explain other ways to handle this communication. This article is excerpted from chapter 10 of the book Ajax Design Patterns, written by Michael Mahemoff (O'Reilly, 2006; ISBN: 0596101805).
We've looked at the basic technologies for web remoting, which leads to questions about browser-server information flow. How will you deal with multiple calls? How will you keep the browser and the server synchronized? How will you access external domains?
Call Tracking is about tracking calls and dealing with the asynchronous nature of Ajax. The next three patterns concern synchronization. With Periodic Refresh, the browser keeps requesting fresh information from the server. The opposite is Submission Throttling, where the browser keeps uploading new information to the server. An alternative to Submission Throttling, Explicit Submission involves uploading only when the user performs some action.
All of those patterns help manage bandwidth, but keeping things in sync can still be quite complex when there are lots of entities in the server and a rich interface in the browser. Distributed Events help manage the complexity.
Finally, Cross-Domain Proxy is a technique for mediating the dialogue between the browser and external servers.
Dave is writing an Ajax chat client, and he's concerned the more vocal users will hog server resources, so he decides to enforce a policy of no more than three pending server calls at any time. Thus, the browser script pushes messages into a queue and tracks the progress of each XMLHttpRequest Call (Chapter 6) containing those commands. He can enforce his maximum call count policy by tracking the state of each call.
How can you control parallel XMLHttpRequest Calls (Chapter 6)?
Fast users and busy applications often stretch networks and servers to their limits.
Asynchronous interaction is the only practical approach for Ajax applications. You don't want to block all interaction just because the network happens to be slow.
The number of simultaneous requests must be controlled, because browsers can only handle a few at a time, and also to reduce the overall load.