The most important JNLP implementation, and the reference implementation as well, is the Java Web Start from Sun. Other JNLP client implementations are still immature as products, or need to be better known among developers (JavaURL, or OpenJNLP for instance). JNLP server implementations are mentioned as well.
Java Web Start
The idea behind Web Start (see its home page at http://java.sun.com/products/javawebstart) and the underlying JNLP protocol is the use of an Application Helper that can interact with the Web browser, but is also usable without it. The Application Helper provides runtime services to the launched application. Web Start supports the deployment of applets as well. In the following discussion, we will refer to Figure 3.1 (in which we omitted the DS Management Phase because we are interested in client issues). For more detailed topics, we refer to Figure 2.5.
Figure 3.1 With JNLP and Java Web Start, the deployment lifecycle coverage is complete.
Figure 3.1 looks quite reassuring because Web Start seems to cover almost all the stages of the deployment process. It should be noted that Web Start is still an immature technology regarding the details of the deployment lifecycle phases covered.
As we know from Chapter 2, these kinds of services belong to the AH Application Support Phase shown in Figure 2.5. That is to say, Web Start works like an Application Container, offering runtime support to applications beyond the automatic download and installation from a Web site and related updates.
We will dedicate an important part of the book to Web Start and the underlying JNLP technology. Here, we will examine the Web Start software product (as of version 1.0) from an End-User perspective, without taking care of the behind-the-scenes mechanisms involved.
In Figure 3.2, a commercial application is launched from a Web page. This begins the installation process. This is one case of the Installation Entry Point we mentioned in Figure 2.8, in this case for applications launched with Web Start.
Figure 3.2 The installation entry point for an application deployed with Web Start.
Referring again to Figure 2.8, once launched, the download is clearly shown to the user. In Figure 3.3, we see the dialog box showing the download progress during an application installation.
Figure 3.3 The Application Installation Progress dialog box.
Web Start is important because of Sun's support (together with other industry leaders) that will allow the JNLP technology to establish itself as the de-facto standard Java deployment technology. This means that the lowest-common-denominator for deploying Java applications using J2SE will be JNLP and, on the client side, Web Start.
There are several reasons why Web Start is promising as the leading client-side JNLP client:
It is officially supported by Sun and other major vendors that collaborate on the JNLP specification. For additional references, see Appendix B, "The JNLP Specification."
It centralizes JRE management on the local platform. Different JNLP clients (or AHs in our more precise terminology) would store and manage JREs differently, in a possibly incompatible way.
A unique client look will help users as well, securing the investment in proposing it also to less-experienced end-users.
Developers will minimize the cost/barrier in deploying their own custom AH (the client launcher) on clients.
It will have a substantial head start against other possible JNLP client implementations.
Developers will use it as a reference scenario when building Web-deployable J2SE applications or applets, taking advantage of lowering development costs when developing to a well-known and documented standard.
Possibly, as the technology matures and stabilizes in the future, it will be incorporated in the J2SE JRE distribution.
Indeed, one may think of Web Start as the locomotive pulling the JNLP train.
The major features permitted by this technology are the following:
A Web-centric approach to Java applications
Native desktop integration of installed applications
Centralized management of different JRE versions
Automatic installation of any resource, from JAR files, extensions, native libraries, and JREs
Security features such as signed JAR files, hence signed applications, and the tuning of permissions with the aim of implementing different levels of restricted execution environment such as that found in the applet security mode
Applications can be launched independently of Web browsers or an Internet connection
Furthermore, as regards the AH, it presents a friendly Java Swing user interface that is perfectly integrated into the native platform.
There are other limitations as well, such as the restriction to use only Java 2 (1.1.x JREs are not supported), minimalism of some deployment options, or the fact that it is restricted to HTTP connections only. We will examine these problems and others in detail from a developer's perspective in the Part III of this book, "JNLP."
Web Start is quite fragile when it comes to dealing with broken connections or user-interrupted downloads. Unfortunately, these are common occurrences in the real world. Currently, in these cases, the user has to restart the download again. See Figure 3.4.
Figure 3.4 Java Web Start doesn't support the resumption of interrupted downloads.
AH & Application Configuration
As can be seen in Figure 2.5, the AH & Application Configuration phase is reachable from the menu EditPreferences. The End-User can administer Proxy connections (see Figure 3.5), install JREs, and select options for the creation of shortcuts and other launching facilities. Other options are related to security (see Figure 3.6); users can inspect all registered certificates. Also, the cache area is accessible (organized as folders containing the various resources on the local hard disk), together with information about the JVM's standard output (see Figure 3.7).
Figure 3.5 The Preferences Settings dialog box for proxy settings.
Figure 3.6 The Preferences Settings dialog box for security-related details.
Figure 3.7 The Preferences Settings dialog box for advanced settings.
Java Web Start has been designed for developers as well, as one can see from Figure 3.8, where in addition to the user error message, even the JNLP file has been reported for debugging.
Figure 3.8 The Error dialog box reports debugging information as well.
A useful feature of JNLP is its capability to manage multiple JREs (despite the handicap of being limited to specific J2SE editions) as shown in Figure 3.9. In the future, this will be very valuable when many different Java programs will be installed on the same computer, and developers can save bandwidth, packaging their applications without the related JRE.
Figure 3.9 The JRE Maintenance Facility in Java Web Start.
Some detailed features of Web Start are competitive with other more complex commercial products, intended for corporate enterprise scenarios. The versioning specification allowable in JNLP, for example, is more sophisticated than other more powerful deployment solutions such as DeployDirector.
We will see the details of Web Start when we extensively cover its underlying foundation, the JNLP protocol, from the developer's viewpoint in Part III, "JNLP."