Steps in Developing a JWS Application


JWS Downsides

Using JWS has downsides. One is the need to have JWS present on the client machine before the application is downloaded. For existing Java users, this isn't a problem since JWS is installed as part of J2SE or JRE. But what about game players who don't have any desire to join the Java faithful? The answer is somewhat messy since it requires the web page containing the deployment link to detect whether the client machine has JWS installed. If it hasn't, then a JRE must be downloaded before the application. Unfortunately, the standardization problems with browsers complicate this detection work.

Another problem with JWS is version skew. There have been several versions of JWS: JWS 1.0 shipped with JRE 1.4, JWS 1.2 was included with JRE 1.4.1, and JWS 1.4.2 arrived with JRE 1.4.2. J2SE/JRE 5.0 comes with a considerably revamped JWS 5.0, which replaces the application manager with a control panel and a cache viewer. The earlier versions of JWS (before 1.4.2) have problems correctly setting up proxy network settings and placing the cache in an accessible location on multiuser machines.

JWS cannot be (legally) modified or reconfigured prior to its installation. For example, you cannot distribute a version of JWS that never places an application icon in the menu list or always pops up a console window to display output. The location of the cache cannot be preset, and there's no way to create an uninstallation menu item. Many of these things can be changed, but only after JWS is present on the client machine, which means these actions must be carried out by the user rather than the developer or deployer. These tasks may be beyond the ability of novices. To be fair, the deployment file does allow some installation elements to be configured, including what is displayed during the retrieval process.

The automatic updating of an application requires that JWS checks the home server for changes every time the program is run, which causes a (small) delay. Normally, an entire JAR will be downloaded, even if only one line of it has changed. The solution to this problem is jardiff, which specifies the changes necessary to update a JAR to its current version. jardiffs are much smaller than JARs since they only need to store modifications. However, jardiffs require specialized server settings before they can be utilized.

JWS deployment files need the JNLP MIME type to be set up in their host server. For example, the mime.types file in Apache must include this line:

     application/x-java-jnlp-file   JNLP 

The problem is that the application developer may not have access to the server to do this. However, this is not much of an issue as most current web servers come preconfigured with the JNLP MIME type.

Though JWS is aimed at web-based downloads, it's possible to a supply a link to a local deployment file (using the ">file://<path> notation). However, the file must contain a reference to its current location, which will often be unknown to the developer at build time. For instance, at installation time, the file may be stored on a CD created by a third party, and it may be mounted on a drive with a name that could be almost anything. There are add-on JWS tools for building CD installers, including Clio (http://www.vamphq.com/clio.html) and Jess (http://www.vamphq.com/jess.html). Clio adds a built-in web server to the CD, and Jess writes the application directly to the JWS cache. JWS 5.0 offers improved support for CD-based installation.



Killer Game Programming in Java
Killer Game Programming in Java
ISBN: 0596007302
EAN: 2147483647
Year: 2006
Pages: 340

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net