This article will describe the deployment process and the subsequent automatic update of the client's GUI with the help of the Java Web Start technology in a Windows environment. At present, Java Web Start may be used in Windows, Linux, Unix (Solaris), and not so long ago in Macintosh OS X. As for applications deployment, HTTP protocol is used; this makes it possible to use any of the many HTTP servers. To use all the possibilities that the Java Web Start technology provides, such as "versioning" of Java applications and "incremental updates," it's necessary to a Web server that supports Servlets or CGI scripts. We will use an application server; in our case it is JBoss 3.2.3. Included in its package is the Web container called Apache Tomcat. We will describe what is necessary to be done to configure JNPL protocol support.
We hope that our readers has certain practical Java development experience, and at least little knowledge and imagination of the JBoss application server, or at least of Apache Tomcat.
One should point out that the given article is not considered to be a full manual for Java Web Start. To get the full official information, go to the Sun Microsystems site: http://java.sun.com/products/javawebstart/.
Introduction to Java Web Start
We will start with, a general description on Java Web Start. It's a small, free of charge, widely used program for clients' PCs associated with a Web browser. Java Web Start is included in the Java Runtime Environment (JRE) as part of J2SE 1.4.2. It can be downloaded at http://java.sun.com/j2se/1.4.2/download.html. When a user clicks a link in the browser, pointing to a special JNLP (Java Network Launching Protocol) executing file with a Java application, it launches Java Web Start, which in turn automatically downloads application files from Web server; the user caches some of them and launches the described Java application. Java Web Start is given in a standard package, either in JRE 1.4 or in JDK 1.4. It's worth pointing out that Java Web Start is also allows you to easily solve the question of installation of Java application (as well as Java Applets), and its subsequent "automatic" update on any PC.
After an individual configuring of Java Web Start on the client's PC itself and the installation of your Java application, all the necessary files for working with JAR libraries will be cached on the user's PC. All the next application's update (during updates of application or while eliminating code bugs, etc.) will be carried out automatically on the client's PC. It means that Java Web Start will not allow you to take care of updates on local PC, but does it itself and automatically checks and downloads newer versions of not only modules written by you, but also of additional libraries used in your application. When you will have your application changed, you nly need to put new versions of JAR libraries into the application server (to be more exact, in your WAR package). At launching the installed and cached application on the client's PC, Java Web Start performs the comparison of local files and files from the server, and does selective downloads of only changed JAR libraries.
Requirements of the Java Application and Configuration of the Client's PC
Because Java Web Start's work is based on using the JNLP protocol, the configuration is carried on both the client and server sides.
To install a Java application on a local PC, we will need the installed Java Web Start (Application Manager) and Web browser. A Web browser is needed only for the initial launching of the Java application; after doing it, it can be closed, but the application will continue to function. For a Web browser, it's better to use Internet Explorer because it works properly from the very beginning. Nevertheless, other browser can be used, but you might need to do some fine tuning. However, tuning the Web browsers is out of the framework of this article and we will not dwell upon these questions.
If a Java application is launched often, one can create, in the Windows environment with the help of Java Web Start, a standard "application shortcut" on the desktop and launch the Java application without using a browser, but only with the help of a shortcut. It's also possible to launch a Java application from the command line.
As it was already said, Java Web Sart is always accessible after installing JRE 1.4, as well as JDK 1.4. It's a pity to mention that for younger versions of JDK/JRE it must be installed separately, but in my opinion it's unjustified because as it was mentioned more than once that certain problems at the work of such a variant used to appear. We insist on using version 1.4.
Java Web Start also makes definite demands on the written client's Java application. The application must be supplied as a set of JAR files and all application resources, such as images, configuration files, and libraries (DLL, SO) must be included into JAR files. Resources in code must be obtained with the help of the ClassLoader getResource() or similar methods. The application is launched on the client's PC with access rights issued for a standard "sandbox," with all that this implies. So, that's why, if you need unlimited access to the local files, it will be necessary to perform some additional tuning and signing of libraries with a certificate. Java Web Start also has a special PersistenceService API to store the local client's tuning, which is to some extent similar to "cookies" and allows the safe storing of local configurations on a PC. Besides, there are some other APIs—BasicService, ClipboardService, DownloadService, FileOpenService, FileSaveService, PrintService—but their discussion is beyond the framework of this article.
In my case, we used JDK 1.4 (located in C:\j2sdk1.4.1_02). That's why we will describe everything concerning this installed package.
To launch Java Web Start, one must launch the C:\j2sdk1.4.1_02\jre\javaws\javaws.exe file.
If, on local client's PC, you launched Java Web Start, you may consider that no more is required to install client's Java applications.
JNLP Configurations File for Your Application
One should point out at once that you will have to take small archives from the official Java site assigning for developers. We used javaws-1_2-dev.zip. It consists of the necessary information on JNLP configuration, and also JAR files of servlet classes, such as jardiff.jar, jnlp-servlet.jar, and jnlp.jar, which will be required on the server. You can download it here: http://java.sun.com/products/javawebstart/download-jnlp.html.
So, to set information about the definite files necessary for lthe aunching and functioning of your client's application into Java Web Start, it's necessary to create a special JNLP file in XML format. This file will be placed on the JBoss server in the Web application, assigned for GUI deployment.
We will illustrate the simplest example of a JNLP file and give some explanation about the file tags and their values.
... <jnlp spec="1.0+" codebase="http://localhost:8080/application" href="application.jnlp"> <information> <title>Demo Test</title> <vendor>Green</vendor> <description>Demo client by Green</description> </information> <resources> <j2se version="1.3+" /> <jar href="demotest.jar" main="true" /> </resources> <application-desc main-class="demo.green.client.DemoTest" /> </jnlp> ...
To begin with, here are a few words about the used arguments that can be the most interesting for us.
- codebase—Points out the place where we will store libraries, JAR files of our application, as well as JAR files of "additional" required libraries. It's worth noting that in this parameter one may indicate the $$codebase value, the factual meaning of which JNLP servlet will state independently while processing the request.
- href—Name of the JNLP description file that describes our application. This argument we also can change with the $$name value, the factual meaning of which JNLP servlet will state independently while processing the request.
- jar—A library, in which classes of our application are located. At the same time, the main="true" argument shows that the given JAR archive contains a launchable class of the GUI application.
- property—This way, we can enumerate all the properties transmitted as arguments to our application, which can be received by calling the System.getProperty() method.
- application-desc—The indication of the launching class. Java Web Start also supports Java applets. In this case, instead of application-desc, we will use applet-desc.
More detailed information about all other arguments can be found in the official documentation and manuals.