|
|
|
|
|
Using Java Web Start, developers can deploy full-featured Java 2 applications over a network. As easy to use as accessing a web page, Java Web Start provides one click activation and guarantees that users are always running the latest, centrally controlled version of the application all made possible using the new Java Network Launch Protocol (JNLP). The possibility for peaceful coexistence of multiple applications all with unique runtime environments, security needs and system properties is reason enough to be excited about this technology.
The only catch is that the user must install the Java Web Start client program. When Java 2 SE v1.4 is released, the user can simply install the Java 2 Runtime Environment (JRE). There is also a small, time penalty for the first use of an application during the download from a web server (possibly including a security scan of the Java Archives for certification). This article will discuss how it all works and how to deploy client applications. Near the end we will show how to make a privileged application (requiring local file system access) network accessible using JNLP and Java Web Start.
In the dark ages of Java, a good user interface meant your web page could animate an image file. The age of the Applet soon followed, fueling Java's growth. Applets were innovative because they allowed a web page to present a full-featured user interface. Java's promise of Write Once, Run Anywhere seemed unstoppable.
As the browser wars erupted, incompatibilities emerged. Applet developers could not predict or control which version of Java the user had installed. Tradeoffs had to be made:
One popular solution to the applet issue was the Java Plug-in; a technology allowing JRE selection and caching through the browser. Unfortunately, support for the Java Plug-in was not the highest priority for web browser developers. The technology proved awkward, requiring custom downloads and complicated HTML (EMBED tags instead of APPLET). In the mean time, managers (who despise uncertainty) looked for alternatives. One of the most popular proved to be the use of markup language technology such as servlets combined with JavaServer Pages (JSP) to serve up dynamically generated web pages. Thus began a migration to server side development for Java developers and browser-based "thin" clients for users.
The server-centric model has met the challenge of a consistent, responsive user interface. It has not, however, met the challenge of a full-featured user experience. Sun's next release of the JRE changes all of that: version 1.4 includes Java Web Start.
Each application is deployed using a special file called a
deployment manifest, or .jnlp file. To make the
application launch from a web page, the deployment engineer
must place a Hypertext Reference (HREF) anchor tag pointing to the
deployment manifest file in the web page HTML file. Once the web
page containing the application link is served to a browser, the
user may click on the link. When they do so, the following occurs:
Lets look a little more closely at what happens, then discuss how to prepare the server.
For each application, Java Web Start prepares a dedicated directory containing compressed and name-mangled versions of the JAR files downloaded. All class files, property files, image files, etc. must be packaged in a JAR in order for this model to work. On demand, Java Web Start downloads a JRE to match the needs of each application (independent of the client machine's JRE setup).
Installation of Java Web Start requires JRE v1.3 (included with the install image). The cache strategy makes it possible to run applications without a connection to a network. This can be disabled forcing a reconnect to the server each time the client runs if, for example, the deployment team wants the option of tweaking the client using system properties controlled at the web server.
As a Java 2 application, Java Web Start takes advantage of a comprehensive security scheme. This restricted environment (called the Java sandbox) disallows access to the local file system and network. Applications can request additional system privileges (such as printing or access to the system clipboard), but they will only be granted if the user chooses to trust the application.
Trust requires using a certificate, which is used by the application developer to digitally "sign" their application. Once the user has a certificate from a certifying authority, they can verify where the application came from. They can then decide whether to trust it.
A certificate is a digitally signed statement from one entity (person, company, etc.), saying that some credentials (public key) really belong to some other entity. There are certifying authorities (such as VeriSign, Thawte and CyberTrust) that specialize in providing certificates for others for a fee.
Digital code signing involves a procedure (described in detail later) used to "sign" the JAR files holding application resources. Signing the JAR allows Java Web Start to verify that some third party has not altered the JAR after the developer signed it. This should not be confused with JAR sealing -- a process where packages stored in JAR files can be optionally sealed so that all classes defined in that package must be found in the same JAR file.
Java Web Start alerts the user to a request for access to system resources using a number of security dialogs. Here is an example for an application attempting to gain access to the local file system using the JNLP API:
Fig. 1 Security Advisory Dialog
Support for fine-grained permissions is specified in the JNLP specification, but not supported in Java Web Start. Unfortunately, this makes security an "all or nothing" proposition, at least at this point.
Applications launched with Java Web Start are deployed using JAR files. If an application also specifies it needs to break out of the security sandbox, all of the JAR files will need to be digitally signed. After each download of a signed JAR file, Java Web Start will verify that the contents have not been modified (since they were signed). If verification of a digital signature fails, Java Web Start will not run the application.
Java uses public key encryption to sign JAR files. This involves two keys, one private and the other public. Both keys are stored in a database called a keystore, with the private key being encrypted. Public keys are exported from the keystore in the form of a certificate.
For this example (and other testing needs) it is possible to use a
self-signed test certificate. These can be used to
temporarily avoid the cost and delays of getting a formal
certificate from a certifying authority. Test certificates do not
provide any guarantees about the identity of the source of the JAR,
but can be created on demand using the keytool program
included with the Java 2 SDK.
To begin, create a new keystore:
>keytool -alias myalias -genkey
The user is prompted for a password and some identifying
information. Next the command generates the keys (this may take
some time) and stores them in a file called .keystore.
The file location varies by platform
(c:\Documents and Settings\Username\.keystore on
Windows 2000 for example). To verify the process worked, list the
contents of the keystore file using the same command with different
arguments:
>keytool -list
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry:
myalias, Tue Nov 13 21:23:57 CST 2001, keyEntry,
Certificate fingerprint (MD5): 1C:D8:CF:F0:C2:87:BA:A8:A0:52:E9:A3:FB:1E:44:48
The procedure to prepare a signed jar file involves using the
jarsigner tool included with the Java 2 SDK:
>jarsigner FileChooserDemo.jar myalias
The altered JAR file is now ready for deployment with Java Web Start. For those interested in the details, the modifications to the JAR file include:
manifest.mf file, an enumeration of all
classes in the JAR is created with one-way hashes of each of the
class files (used to verify the class file has not changed).
Java Web Start reads the test certificate inside the JAR file and during application launch displays an imposing Security Warning dialog.
Fig. 2 Security Warning Dialog
If a proper certificate (from a certifying authority) had been used, the dialog would look the same except the warning text would be replaced by:
Caution: Brad Shuler asserts that this content is
safe. You should only install and run this application if you trust
Brad Shuler to make this assertion.
The name of the certifying authority would also be shown. Once all the JAR files are signed, the host can be prepared to serve them.
JNLP makes Java Web Start possible. This technology (defined through
the Java Community Process) defines the standard file format
describing how to launch applications -- the .jnlp
file. In addition to the Reference Implementation (RI) from Sun
(Java Web Start), several open source projects are attempting to
implement the JNLP specification (see References).
Web servers use a Multipurpose Internet Mail Extensions (MIME) lookup table to determine how to serve content to a browser. Java Web Start launch files use a new MIME type:
application/x-java-jnlp-file
This requires a mapping between the MIME type and the JNLP file
extension. For example, with Apache, add the following to the
configuration file mime.types:
application/x-java-jnlp-file JNLP
The JNLP file describes how the application will be launched and how it will appear in the Java Web Start Application Manager. The format for the file is the Extensible Markup Language (XML).
We will now demonstrate setting up a JNLP file for use with Java Web Start. The Java 2 Java Developers Kit (JDK) from Sun includes several demonstration applications utilizing the Java Foundation Classes (Swing). One very basic application is called FileChooserDemo (Figure 3). This program displays a Swing dialog allowing the user to configure a file selection dialog and then run it, browsing the local network (potential security hazard!).
Fig. 3 Java 2 SDK JFC/Swing FileChooserDemo Application
The corresponding deployment manifest (example.jnlp) is
shown here:
<?xml version='1.0' encoding='UTF-8'?>
<jnlp
codebase="http://www.bradshuler.com/jws"
href="example.jnlp">
<information>
<title>FileChooserDemo</title>
<vendor>Object Computing, Inc.</vendor>
<homepage href="index.html"/>
<description>Sun's JFC FileChooserDemo Application</description>
<icon href="oci_logo.gif"/>
<offline-allowed/>
</information>
<resources>
<j2se version="1.3"/>
<jar href="FileChooserDemo.jar"/>
<property name="key" value="value1"/>
</resources>
<security>
<all-permissions/>
</security>
<application-desc main-class="FileChooserDemo"/>
</jnlp>
The XML document shown above contains several key pieces of information:
codebase attribute of the jnlp
root element provides the base URL for all href
attributes which follow.
href attribute "example.jnlp"
specifies the name of the JNLP file itself (used by Java Web
Start to add the application to the list of installed programs
in the Application Manager).
information element provides data presented to
the user when viewing the description of the application in the
Application Manager or when viewing the desktop icon
(optionally installed by the user). The
offline-allowed element indicates Java Web Start
will allow the application to run if the deployment web server
cannot be reached.
resources element specifies:
security element is used to specify access to
the client machine and local network. This requires that all
JAR files be signed. As mentioned previously, fine-grained
permissions are not yet supported, making
all-permissions the only option at this time.
main class for the application, specified via
the application-desc element.
Resources Element
There are several features that can be configured using the
resources element:
download attribute set to
one of two values: eager (default) or
lazy. Eager resources must be downloaded before the
application will start. For example:
<jar href="application.jar" download="eager"/>
<jar href="fluffySounds.jar" download="lazy"/>
resources elements are allowed. This
allows a default set of resources with another set specified to
narrow down what to download to the client by locale, operating
system or architecture (i.e. Windows vs. Solaris). Here is an
example:
<!Common Resources for all -->
<resources>
<jar href="jars/windows/coreComponents.jar"/>
</resources>
<resources os="Windows">
<jar href="jars/windows/audio.jar"/>
<nativelib href="jars/windows/utilDLL.jar"/>
</resources>
<!-- Linux IBM J2RE -->
<resources os="Linux" arch="x86">
<jar href="jars/linux/i386/audio.jar"/>
<nativelib href="jars/linux/i386/util.so.jar"/>
</resources>
<!-- Linux SUN JRE -->
<resources os="Linux" arch="i386">
<jar href="jars/linux/i386/audio.jar"/>
<nativelib href="jars/linux/i386/util.so.jar"/>
</resources>
<resources os="Solaris" arch="sparc">
<jar href="jars/solaris/audio.jar"/>
<nativelib href="jars/solaris/util.so.jar"/>
</resources>
j2se element controls which JRE is used:
<j2se version="1.4.0-beta3"
href="http://java.sun.com/products/autodl/j2se"/>
<!-- Use production release of JRE 1.4 or use the beta if not available -->
<j2se version="1.4 1.4.0-beta3"
href="http://java.sun.com/products/autodl/j2se"/>
<!-- JDK 1.3 or better -->
<j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
extension element -- providing a powerful
CLASSPATH like capability across the Internet or
intranet (since the first JNLP file need not be on the same
server as referenced JNLP files).
The Java Web Start Application Manager GUI allows users to view, launch and configure downloaded applications. The main window is shown below:
Fig. 4 Java Web Start Application Manager
The information shown (home page, description and author) is derived from each application's JNLP file. The user launches an application by selecting the icon desired and pressing the Start button. Other, advanced features accessible from the Preferences dialog include:
Sun provides a JNLP API to provide additional information and features to Java Web Start enabled applications (even in restricted environments). Code examples for the following services are available in the Sun Java Web Start Developer's Guide (see References):
BasicService (query and interact with the host
environment)
ClipboardService (access the shared system-wide
clipboard)
DownloadService (allows an application to control
how it is cached)
FileOpenService (import files from the local disk)
FileSaveService (export files to the local disk)
PrintService
PersistenceService (store data on the client --
similar to cookies)
Java Web Start is relatively new deployment technology for Java 2 applications. It provides a seamless gateway between the client computer and Internet (or intranets) that allows the user to launch and manage applications right off the web. With point and click activation of applications, Java Web Start guarantees users they will always be running the latest version, eliminating installation and upgrade headaches. Java Web Start is available for a wide variety of platforms including Windows 95/98/NT/2000, Linux, Solaris and Mac OS X.
Object Computing, Inc (OCI) has been providing educational services to clients, industries and universities since 1993. We offer one of the most comprehensive distributed Object Oriented training curricula in the country. These curricula focus on the fundamentals of OO technology; with close to 40 workshops in OOAD, Java, XML, C++/CORBA and Unix/Linux.
For further information regarding OCI's Educational Services programs, please visit our Educational Services section on the web or contact us at training.
|
|