Browse Prior Art Database

Web Server Detection and Automatic Switching to Local Cached Applet

IP.com Disclosure Number: IPCOM000024641D
Original Publication Date: 2004-Apr-02
Included in the Prior Art Database: 2004-Apr-02
Document File: 3 page(s) / 60K

Publishing Venue

IBM

Abstract

Design for enabling a Java applet normally loaded from a Web server to continue to run even though the Web server is unavailable.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

Web Server Detection and Automatic Switching to Local Cached Applet

Disclosed is a design for enabling a Java applet normally loaded from a Web server to continue to run even though the Web server is unavailable. This design builds on other design considerations where the applet run-time code is "cached" or separately downloaded and managed on the client's local workstation.

In a previous design, a user would point their web browser to an HTML web page that contains the HTML tags necessary to load and start a secondary applet that performs version checking of the main applet run-time code. If the run-time code was up to date and no additional code needed to be downloaded, this secondary applet would startup the primary (or main) applet. However, if the Web server was not available to launch this secondary applet, the primary applet would never be launched.

This proposal solves this problem by storing the information necessary to activate the applet (and the applet itself) directly on the client computer. In addition, by creating a common method to start the user's applet (regardless of whether or not the web server is available); we simplify the user's task in starting the applet.

In this design, a web page will be installed (cached) on the end user's computer, along with a small applet. The HTML will load the applet, which will then attempt to connect to the Web server. If the Web server is available, then the user's browser will be redirected to a web page on the Web server and the secondary applet will run just as if the user pointed directly to the Web server (i.e. check for updates, etc). If the connection attempt fails, the original HTML page will then load a version of the applet that has been locally cached, and the end user will be able to use the applet normally.

In the remainder of this proposal, the following terms will be useful: ContactApplet - the applet that will attempt to contact the web server, and switch control to the web server if it is available. TargetApplet - the applet that will ultimately be loaded, and will do the useful work for the client. CachingAppet - an applet that will download and store classes that are necessary for the TargetApplet to run.

We solve this problem by creating three parts to the solution.

1) An HTML file will be stored on the client computer, along with a small applet, called the ContactApplet. The purpose of the applet will be to try to contact the web server. If the attempt is successful, this applet will immediately redirect the client's browser to the web server, and the client can execute the TargetApplet normally.

2) If the ContactApplet is not successful in contacting the web server, then it will generate dynamic HTML that will start a locally cached version of the TargetApplet.

1

Page 2 of 3

3) The third part of this solution is the TargetApplet itself, which must be downloaded...