By Kyle Downey (kyle@webconcepts.com)

The Web is filled with nuggets of information, some of it updated on an daily, hourly or even minute-by-minute basis. A Java applet's graphing capabilities and its ability to sit on a page and display continuously changing data make it an ideal viewport for these sorts of pages. Rather than forcing your viewers to reload to see new data, the applet can stay running and continuously pull in the required data. The best part is that you do not need direct access to the headline, weather or stock feed data: Java can access HTML pages directly, so any source of data that is available on a Web page is in theory accessible to your applets.

Unfortunately, using an applet as a dynamic filter for information is not easy. The Java security model for JDK 1.0.2 prevents applets from accessing URLs outside of the web server on which the applet itself is hosted. JDK 1.1 and the 4.0-level browsers let you sign applets and selectively permit network access, but unless you can control the browsers hitting your site (as on an intranet), you are out of luck if you want to directly access another site from your applet. Many designers solve this by writing a custom Java or C++ server that runs on the Web server and communicates with the applet over the network. The applet (legally) talks to this server, the server (which is free to go to any Web address) fetches and reads the Web page, and then hands it to the applet.

Such a design is very inefficient from both a resource and a programming standpoint, though. Your weather server, your server and your ABC news headline server each take up memory on your server, and each has to sit and listen on its own network port. Furthermore, they all basically do the same thing: they fetch a Web page, decipher the information on it in an application-specific manner, and then communicate this information to the applet. Object-oriented design encourages us to find such patterns and ask whether there's a generic way to solve the problem rather than constantly reinventing the wheel.

An "applet proxy server" is one possible solution to this problem. The idea of a proxy server comes from the world of firewalls. A proxy server sits outside of the firewall and fetches Web pages for Web browsers inside the firewall. The browsers talk to the proxy server, the proxy talks to the destination site, and it acts for (thus proxy) the browser on the Internet. An applet proxy server does the same thing if you think of the sandbox as a firewall. The proxy server runs on the Web server (which the applet can talk to) and fetches the pages, then hands the complete page to the applet to interpret how it pleases. Since the proxy server does not care what the applet does with the page, any applet can use it to get any page.