Java Web Start Technology and Application Clients in the GlassFish Application Server

Print-friendly Version

Download PDF of All 4 Parts

Articles Index

Part 1 - Introduction
Part 2 - JNLP and Java Web Start Technology
Part 3 - GlassFish Application Clients: The Java Web Start Experience
Part 4 - Security, Advanced Topics, and a Look Ahead

As a Java developer, you need some way to get your application into the hands of your end users. You also need to make sure the application is started correctly and in the correct runtime environment (classpath, system properties, and so forth must be set correctly). If your user base is relatively small and conveniently accessible, you can package your application as a JAR file and copy that JAR to your end users' systems. You might also write a script to set up the environment and start the application, and perhaps you would create an icon on each user's desktop to run the script. When you change the application, you can go through the same steps again. But as your user base becomes larger, more remote, or both, this approach to distribution and launching can become a problem.

The Java Network Launching Protocol (JNLP) prescribed by JSR 56 addresses this whole area of distributing, updating, and launching Java applications over the network. The Sun implementation of JNLP is named Java Web Start and is part of the Java runtime environment. (See the references section at the end of the article for links to helpful articles and resources.) This section presents a brief (and very simplified) summary of JNLP and the Java Web Start technology that helps set the stage for its use in the GlassFish application server (hereinafter called the GlassFish app server).

Here is a simple example. Suppose you want to distribute and run a drawing tool. You could package your application into a JAR and launch it as shown here to draw an initial circle against a blue background:

java -classpath jarlib/drawtool.jar -Dbackground=blue com.mycorp.draw.DrawTool circle

For this command to work, the JARs or directories in the classpath must be present where the command indicates they are, and the runtime context, including system properties and command-line arguments, needs to be specified. In addition, you must specify the main class you want Java to run. In this example, the main class is specified in the command line, but it could alternatively be specified in the JAR file manifest.

At its core (and oversimplifying), the JNLP specification does the following:

• Prescribes an XML document format for describing an application — the JARs it needs, the system property settings it should use, the command-line arguments it should be provided, and the main class to run
• Mandates that the XML document (commonly called a JNLP document or JNLP file) and the JAR files it lists be retrieved using HTTP

As a developer, delivering an application according to JNLP means packaging all the required classes and resources into one or more JAR files, preparing the JNLP file that describes your application, and then making the JNLP and JAR files available on a web server.

This code fragment shows part of a hypothetical JNLP document for the drawing tool:

<jnlp codebase="http://myserver.mycorp.com/drawtool">
        <resources>
                <j2se version="1.5+"/>
                <jar href="drawtool.jar"/>
                <property name="background" value="blue"/>
        </resources>
        <application-desc main-class="com.mycorp.draw.DrawTool">
                <argument>circle</argument>
     </application-desc>
</jnlp>

The elements of the JNLP document correspond to the parts of the java command line that launches the same application.

An end user can download and launch an application simply by entering the URL for the JNLP file into a browser, or perhaps just clicking on a web page link that points to the JNLP file URL. (The Java Web Start implementation also provides the javaws command that accepts the URL for the JNLP file as a command-line argument and then fetches and launches the application without using a browser.) The Java Web Start technology itself retrieves the JNLP document from the URL and interprets it, downloading the required JARs, preparing the Java runtime environment, and loading and starting the main class.

At this point you might be wondering if the downloaded files can be cached and reused instead of downloaded each time (yes, this is done automatically), if a downloaded application can run even if the web server that provided the JNLP and JAR files is inaccessible (yes, this can be done at the developer's option), if the right things happen with security (yes), and so on. These are all important questions but are beyond what this brief introduction can cover. Read the specification, the Java Web Start documentation, and the online forum to get a much more complete picture.

An application client, as described in the Java Platform, Enterprise Edition (Java EE) specification, is the part of an enterprise application that runs on end-user systems and delivers a rich-client experience. Application clients are pure Java components of enterprise applications, and application client developers typically use the familiar Swing GUI framework to present a powerful and familiar user interface while taking advantage of enterprise components such as web services and EJBs that are deployed in the remote application server. As a developer, you can build an application client by itself or as part of a larger enterprise application (an EAR) that you deploy to the application server.

Application clients execute in a Java EE application client container (ACC). Java EE implementations include an ACC along with the more familiar containers, such as the web and EJB containers. But the ACC runs on the end-user's system — rather than on the back-end as the other containers do — and the ACC can typically be lighter-weight than other containers.

Before a user can run an application client, someone must place both the application client and the ACC on the end user's system. The Java EE specification allows different application server implementations to choose for themselves how to do this. For example, the GlassFish application server includes scripts that you can use to create a JAR file that contains a specific application client and the ACC. You can then copy the JAR to each end-user system, expand the JAR, configure the environment to recognize the ACC, and set up a script or a desktop icon to run the GlassFish appclient command to start the client.

Does this sound like a lot of work? Even with scripts to help it certainly can be, especially if you want to deploy an application client to many end-user systems. Or if you do not know in advance who all your end users will be. Or if you want to deliver a new release of your application client to your end users.

If it was not clear before, it should be clear now that adding built-in Java Web Start support to the GlassFish server makes a lot of sense. Next we look at how the developer, the end user, and the administrator use this new feature.

In Part 3 of this article, you will get a feel for Java Web Start technology in the GlassFish app server, as experienced by developers, administrators, and end users.

• Java EE SDK — contains Sun Java System Application Server, Sun's supported distribution of GlassFish
• The Aquarium — the GlassFish Community blog
• Sun Java System Application Server page — with links to the c Community site
• Java Web Start — all about Java Web Start technology
• JSR 56 — Java Network Launching Protocol and API
• Tim Quinn's blog — focused mostly on Java Web Start support in the GlassFish application server
• Java Training and Certification — professional development to enhance your skills
• Developer Support — online incident-based programming advice, telephone product support, developer training courses, service plans
• Sun Java System Application Server Support