HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

The use of Java in Web browsers has had mixed results. Applications that run in browsers rather than locally find a host of different hurdles. They're more restricted, run slower at times and take a long time to load, thus making complex applications more difficult. Advances in security and virtual machine technology have addressed the first two items. The third item remains somewhat challenging. Faster modems, increased bandwidth and compressed file formats alleviate the problem somewhat but their impact varies. When fourth-generation browsers appeared, they included some new technology with features that allowed developers to have their applets and supporting classes installed permanently.

This article is focused on distributing Java classes that are permanently installed on a user's machine (see Figure 1). The next time a user visits the page, the classes are loaded locally instead of from the network. I'll start with a short explanation of some concepts and tools used in this process, and apply this knowledge to a working example for Internet Explorer and Netscape Communicator. We'll then look at some problems that can occur and some links to additional information.

Figure 1
Figure 1:

The examples in this article use a test certificate, not a production certificate from a Certificate Authority. For purposes of this article, I thought a test certificate - also referred to as a self-signed certificate - was best since not everyone has a certificate. It also teaches you how to generate a certificate for testing. Regardless, the procedures described here apply exactly the same when you're using a real certificate. When you have a real one, you can just skip the parts about generating a test certificate.

The software used in this article was:

  • IE4.0 40bit
  • NS Communicator 4.51 with SmartUpdate
  • MS Personal Web Server (create a virtual directory called "sample" to run samples)
  • MS Windows NT 4.0 SP4
In a typical scenario visitors to a Web page download any elements into their browser cache. This could include the page itself, and some images as well as applets. Depending on browser settings, the next time users visit the page all of these elements may be reloaded from the Web site. This is certainly feasible for elements such as HTML and images, but can be time-consuming and frustrating for users of your applets. Internet Explorer and Netscape have different approaches to the actual implementation of downloading and installing, but they also share some common ideas.

Digital Certificate and Signatures
The use of digital signatures and certificates to verify the authenticity of software is nothing new. Software downloaded over the Internet provides the user no assurance about the authenticity of the author, where the software came from or when it was created. A common metaphor for a digital certificate used in code signing is "shrink-wrap." Software bought off the shelf at your local retailer is packaged with labels and markings indicating the company of origin. Software downloaded over the Internet has no such visible labels or markings.

That's where digital certificates and signatures come in. The combination of digital certificates and signatures provides the labeling or shrink-wrapping that supplies information such as author name, time created and expiration date; they also ensure that the software wasn't tampered with since it was signed. A third party - a Certificate Authority (CA) - normally issues certificates. Basically, the Certificate Authority vouches for the identity of the individual using the certificate to sign his or her software. Popular CA's are Verisign and Thawte. You may also be able to obtain a certificate from your own company, if they're set up to issue certificates.

Netscape and Internet Explorer certificates are based on the standard x509, but deviate after that to produce certificates that are incompatible with each other. Internet Explorer has its Authenticode certificates; Netscape, its Object-Signing certificates.

Packaging
The use of packaging mechanisms to bundle your code and supporting files is common in both browsers. Internet Explorer uses the CAB format and Netscape uses the JAR format. This provides for quicker download times and is a requirement if you want to use managed installation mechanisms provided by Internet Explorer and Netscape Communicator. The former recognizes the JAR format but is unable to recognize a digital signature within. The latter doesn't recognize the CAB format.

Tools
There are utilities for both browsers that allow developers to generate self-signed digital certificates as well as packages, and sign their code. The first five utilities described here are for Internet Explorer only. The last one is for Netscape Communicator only. See the Links section for tool locations. If you have the Microsoft SDK for Java, you may already have the Microsoft utilities.

  • MAKECERT: Generates a test x509 certificate
  • CERT2SPC: Generates a test Software Publishing Certificate from an x509 certificate
  • SIGNCODE: Signs code using a Software Publishing Certificate for IE
  • CABARC: Builds a cabinet file of specified files
  • DUBUILD: Builds a cabinet and OSD and is an all-in-one tool. If you're uncomfortable with XML or don't wish to build your OSDs, this tool is for you. If you're up to it, you can also code the OSD by hand
  • SIGNTOOL: Packages and signs code using an object-signing certificate for Netscape; also used for generating test object-signing certificates
Scripted Install Procedure
The Microsoft virtual machine and its Java Package Manager use an XML-based description language, Open Software Description (OSD), that directs the Java Package Manager on how to handle different aspects of the download (see Listing 1). An OSD is also used to describe any dependencies between various components of the download. Netscape, on the other hand, uses a combination of JavaScript and Java in the package "netscape.softupdate.*" to allow developers to write scripts that control the flow of the installation (see Listing 2). Each of these procedures allows developers to control their installation by querying properties such as:
  • OS version
  • Browser version
  • Software version
  • Ensure proper space exists before install
  • Dependencies between different Java packages and versions
Depending on which procedure you're using, some of these properties may not be available.

Managed Installation
Both browsers have an installation manager available to perform the actual install. Internet Explorer uses the Java Package Manager. Netscape uses the JAR Installation Manager and a feature called SmartUpdate. These installation managers allow the developer to install and update software automatically.

Java Package Manager
The Java Package Manager was introduced in Internet Explorer 4.x and provides the following features:

  • Version Control: Enables you to update older versions of your software and ensure that software isn't downgraded. Note: You can't downgrade your software with the Java Package Manager.
  • Namespaces: Prevents collisions between same-named packages. Before namespace, packages were installed into the CLASSPATH and provided no protection for libraries that may have had identical package names. By providing a namespace for each installed package, you avoid this collision. There's also a global namespace. Packages installed into the global namespace are accessible to all Java Packages. This would be ideal for a generic library that other installed applications could use.
  • Improved Security: Fine-grained security is now possible. The Java Package Manager requires that packages be signed with the Java Permissions to step out of the sandbox. With these permissions you can control access to the UI, the file system and other system resources such as sockets and threads. You can use the default permissions provided by the different levels (high, medium and low) or you can specify a custom permissions file.
You can view already installed packages by opening the "Downloaded Program Files" folder in your Windows Explorer. You can also see this same list using Internet Explorer. Open View...>Internet Options...>Settings...>View Objects. Unlike Netscape, once a package is installed, you can begin using it immediately.

JAR Installation Manager/SmartUpdate
The JAR Installation Manager and SmartUpdate were introduced in Netscape 4.x and provide features similar to those in the Java Package Manager. Some features of SmartUpdate may not be available, depending on the version of Communicator used.

  • Version Control: As with the Java Package Manager, you can update older versions of your software and ensure that it isn't downgraded. However, SmartUpdate also gives you a couple of advantages over the features provided by the Java Package Manager: (1) you can downgrade previously installed packages, and (2) you can force an install despite the version. SmartUpdate maintains this in the Client Version Registry. Unlike the Java Package Manager, when you install a package with SmartUpdate, you must restart Communicator before you can use it. Your install script should indicate this with a dialog.
  • Improved Security: Fine-grained security is now possible. The JAR Installation Manager requires packages to be signed in order to be installed and step out of the sandbox. One noticeable difference between IE and NS is that IE's permissions are encoded with the digital signatures, whereas NS requires the use of the "Capabilities" API to request permissions at runtime.
  • Registry of Installed Applications: Netscape provides a Client Version Registry area that records all installed software registered for use with Communicator.
Sample Application
Now that we have some of the basics behind us, let's start applying it. We're going to install a basic clock applet (see Listing 3), then write an HTML page that demonstrates the installed applet. Please note the package statement in the source. The Java Package Manager requires you to place your classes into a package. Once you've compiled the source, we'll start with the process for Internet Explorer, then Netscape Communicator.

Internet Explorer
1. Generate a test x509 certificate.
The options used for this step are:

  • -sk: Key Name
  • -n: Certificate Subject x500 Name (i.e. CN=My Name)
makecert -sk SampleKey -n "CN=TestCertificate" SampleTestCert.cer

2. Turn an x509 certificate into a Software Publishing Certificate.

cert2spc SampleCert.cer SampleTestCert.spc

3. Create your distribution unit.
The options used for this step are:

  • /D: Distribution unit name or "friendly name"
  • /I: Include files matching this pattern
  • /V: Version number for distribution unit
dubuild sample.cab . /D "Sample Application" /I *.class /V 1,0,0,0

By not using the /N option, we're placing our package into the global namespace. To get an idea what the OSD generated by dubuild looks like, open your CAB and view the generated OSD file. It should look like the one in Listing 1.

4. Sign your code.
During this step you'd normally supply an additional parameter, -t, to indicate a URL to a time-stamping CGI on your Certificate Authority's Web site. However, due to firewall considerations, this may be impossible. For test purposes this isn't a problem. You'll see a message indicating the CAB has been signed but not time-stamped.

The options used for this step are:

  • -j: Indicates the source of the Java permissions
  • -jp: A parameter to pass to javasign.dll. In this case, the security level of medium
  • -spc: The software publishing certificate generated in step 2
  • -k: The key generated from step 1
signcode -j javasign.dll -jp medium -spc SampleTestCert.spc -k SampleKey sample.cab

With our code packaged and signed, we're ready to deploy. We'll use the <APPLET> tag with three parameters:

  • useslibrary: Specifies a name for the distribution unit, which should match the one you specified when you ran dubuild
  • useslibrarycodebase: Specifies the codebase for the distribution unit CAB file
  • useslibraryversion: Specifies the version number, which should match the one you specified when you ran dubuild
<APPLET CODE=com.mysample.application.Sample HEIGHT=20 WIDTH=100>
<PARAM NAME=useslibrary VALUE="Sample Application">
<PARAM NAME=useslibrarycodebase VALUE="sample.cab">
<PARAM NAME=useslibraryversion VALUE="1,0,0,0">
</APPLET>

These parameters will be ignored in Internet Explorer version 3 and Netscape browsers. Once you've saved the page, open it in your browser. If everything went okay, you should see a Security Warning dialog. Click on "Yes" to trust; you should then see the sample applet start.

Verify Installation
Open the "Downloaded Program Files" folder in Windows Explorer ordo aView...>InternetOptions...>Settings...>View Objects and you should see the same display (see Figure 2). Behind the scenes the Java Package Manager is also updating the registry entries for your distribution unit. Run regedit and open "HKEY_LOCAL_MACHINE\Software\Microsoft\Code Store Database\Global Namespace". You should see keys for all packages installed in the global namespace, top-level first. Open the "com" key and you'll see the "mysample" key underneath it.

Figure 2
Figure 2:

Netscape Communicator
We'll now examine the process for Netscape Communicator. Note: Please shut down Communicator before running step 1 or you risk corrupting Communicator's security database. You'll also note that the signing and packaging steps are combined. To create and store an object-signing certificate, you'll also need to have a password set. If you don't, step 1 will fail. To set a password, open the Security Window and select "Passwords." As you'll see shortly, to permanently install Java Packages to run locally, you must place your signed JAR of classes inside another JAR containing an install script (see Figure 3). Wherever you specify the path to the certificate directory, you'll need to replace the path of the certificate database to match the path on your system.

Figure 3
Figure 3:

1. Create test object-signing certificate.
The options used for this step are:

  • G: The nickname of our object-signing certificate
  • -d: The location of the certificate database
signtool -G"SampleNetscapeObjectCert"
-d"e:\progra~1\netscape\users\default"

When you run signtool you'll be prompted for a number of parameters, as it states in the message before it runs. These are optional except for the database password. You can bypass them by pressing "Enter." To verify your certificate has been added, type the following command:

signtool -L -d"e:\progra~1\netscape\users\default"

You should see a list of Certificate Authorities, including yours, with asterisks beside them. The asterisk means that this certificate can be used to sign objects. If you decide not to install directly into Communicator, you can import your certificate by placing a link to it on a Web page, then clicking on it. You'll be guided through a series of dialogs to install it. If you're distributing this test object-signing certificate from a Web site, you'll also need to configure a MIME entry for it on the Web server you're using. You can also start Communicator and look at the Security Info Window. Click on "Signers" under "Certificates." You may have to scroll until you see "SampleNetscapeObjectCert".

2. Create install script (see Listing 2).
The install script's purpose is to direct the actual install.

3. Create and sign Software JAR.
The options used for this step are:

  • b: Specifies the base filename for the .rsa and .sf files
  • d: Specifies the location of the certificate directory
  • k: Specifies the nickname of the test object-signing certificate created in step 1
  • Z: Directs signtool to create a JAR with the specified name
signtool -b "Sample Application"
-d"e:\progra~1\netscape\users\default" -k SampleNetscapeObjectCert
-Z sample.jar .

4. Create and sign Install JAR.
Now we'll create the install JAR that will hold our install script and software JAR. You'll be prompted for the certificate database password. You can also use the "-p" option to specify the password. I'd recommend using this option only during testing as the password is visible.

  • b: Specifies the base filename for the .rsa and .sf files
  • i: Specifies the name of the install script
  • d: Specifies the location of the certificate directory
  • k: Specifies the nickname of the test object-signing certificate created in step 1
  • Z: Directs signtool to create a JAR with the specified name
signtool -b sampleinst -i sample.js
-d"e:\progra~1\netscape\users\default"
-k SampleNetscapeObjectCert -Z sampleinst.jar .

Now that the classes are packaged and signed, we can deploy. We'll be using what's referred to as a trigger script (see Listing 4). Once you've saved the page, open it in your browser. If everything went okay, you should see a Security Warning dialog. Click on "Grant" to trust, then you'll see a dialog indicating Communicator must be restarted before using the new classes.

Verifying Installation
Start Communicator and open Edit...>Preferences...>Advanced...> SmartUpdate. You'll see your package name in the listing of installed software (see Figure 4).

Figure 4
Figure 4:

Using the Installed Software
Let's try out the newly installed package. Put the following code into a page and bring it up in your browser (see Figure 5). Notice there is no CAB base or archive parameter specifying the cabinet or JAR where the classes are to be found. That's because the classes are being loaded locally by the browser.

Figure 5
Figure 5:

<HTML>
<BODY>
<H1> Our Sample Installed Application </H1>
<APPLET CODE=com.mysample.application.Sample HEIGHT=20 WIDTH=200></APPLET>
</BODY>
</HTML>

Updating Your Software
Eventually most software needs to be updated. New hardware, bugs or new versions can create this need. With the Java Package Manager and Netscape with SmartUpdate, you can update the version a user has installed with the same ease. Simply increment the version numbers appropriately and update your HTML page and/or the install script. The next time users visit the page, they'll be prompted to install a new version if the version you specified is newer than the installed version.

Problems
Sometimes things go awry. You may see messages indicating security failures or you may see nothing on the page. There are tools to aid in diagnosing download failures. CODLLGVW is a utility that examines the code download error log created during download. Netscape includes a host of error codes that could arise during SmartUpdate. In Internet Explorer one of the most common is that there may be insufficient disk space to install your component. Another possible area is errors in the OSD. The CDF utility can be used to find possible errors in your OSD, such as missing or misspelled tags. Another problem I've seen is not specifying a package in your OSD that's in your CAB. Also, make sure the name you use in the useslibrary tag matches the friendly name of your distribution unit. And when using IE, make sure the version numbers match on your useslibraryversion tag and the one you specified when you ran DUBUILD.

Summary
As you can see, distributing your code for permanent installation isn't difficult. And I'm sure the users of your applet will appreciate the decreased loadtime. Although the process for each browser is somewhat different, it's similar overall.

The following links should provide any further details you may need. Good luck!

  1. Packaging Components for Internet Distribution:
    http://msdn.microsoft.com/workshop/delivery/download/tutorials/buttons_download.asp
  2. Deploying Java in Internet Explorer and Netscape Communicator:
    http://support.microsoft.com/support/kb/articles/q179/6/52.asp
  3. Downloading Code on the Web:
    http://msdn.microsoft.com/workshop/components/downcode.asp
  4. Object Signing - Establishing Trust for Downloaded Software:
    http://developer.netscape.com:80/docs/manual/signedobj/trust/owp.htm
  5. Object Signing Resources:
    http://developer.netscape.com:80/docs/manuals/signedobj/overview.html
  6. SmartUpdate Developers Guide:
    http://developer.netscape.com:80/docs/manuals/communicator/jarman
Author Bio
Mike Jasnowski, a Sun-certified Java programmer, has 17+ years of programming experience and 3+ years with Java. He works for a software company in Kansas City, Missouri.
Mike can be contacted at: [email protected]

	

Listing 1:

<?XML version="1.0"?>
<!DOCTYPE SOFTPKG SYSTEM "http://www.microsoft.com/standards/osd/osd.dtd">
<?XML::namespace href="http://www.microsoft.com/standards/osd/msicd.dtd" as="MSICD"?>

<SOFTPKG NAME="Sample Application" VERSION="1,0,0,0">
<!-- created by DUBuild version 5.00.3023 -->

    <TITLE>Sample Application</TITLE>

    <MSICD::JAVA>

        <PACKAGE NAME="com.mysample.application" VER-
         SION="1,0,0,0">
            <IMPLEMENTATION/>
        </PACKAGE>

    </MSICD::JAVA>

</SOFTPKG>


Listing 2:

//* Sample JavaScript installation script

// Make sure Java is enabled before doing anything else

if (navigator.javaEnabled()){

    answer = confirm("Do you want to install Sample Application?");

    if (answer){

      // Create a version object and a software update object

      vi = new netscape.softupdate.VersionInfo(1,0,0,0);
      su = new netscape.softupdate.SoftwareUpdate(this,"Sample
Application");

      // Start the install process
      err = su.StartInstall("java/download/Sample
Application",vi,netscape.softupdate.SoftwareUpdate.LIMITED_INS TALL);

      if (err == 0){
          // Find the Java Download directory on users computer
          JavaFolder = su.GetFolder("Java Download");

          // Install the JAR File. Unpack it and list where it goes
          err = su.AddSubcomponent("Sample
Application",vi,"sample.jar",JavaFolder,"",this.force);
      }

      if (err != 0){
           alert(err);
           su.AbortInstall();
           alert("Installation Aborted.");
      }else{
           su.FinalizeInstall();
           alert("Installation complete. You must restart Communica- 
    tor to use the Sample Application");
      }
    }
}


Listing 3:

package com.mysample.application;

import java.applet.Applet;
import java.awt.Graphics;
import java.lang.Runnable;
import java.util.Date;
import java.awt.Color;

/**
*
* Sample.java
*
* @author Mike Jasnowski
* @version 1.0
*/
public class Sample extends Applet implements Runnable{

      private String time_string;
      private Thread runner = null;

      public void init(){
             runner = new Thread(this);
             runner.start();
      }

      public void run(){
          while (true){
                time_string = new Date().toString();
                repaint();
                try {
                        runner.sleep(100);
                } catch(InterruptedException e){}
          }
      }

      public void paint(Graphics g){
          setBackground(Color.white);
          g.drawString(time_string,12,12);
      }

}


Listing 4:

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">

// Ensure Java is enabled

if ( navigator.javaEnabled() ) {  

   // Create a Trigger Object
   
   var trigger = netscape.softupdate.Trigger;    

   // Create a VersionInfo object
  
   version = new netscape.softupdate.VersionInfo(1,0,0,0);

   // Make sure SmartUpdate is available

   if ( trigger.UpdateEnabled() ){

        // Call ConditionalSoftwareUpdate pointing to Install JAR

        trigger.ConditionalSoftwareUpdate ("http://local  
        host/sample/sampleinst.jar","java/download/Sample 
        Application",version,trigger.DEFAULT_MODE); 
   }else 
           alert("Enable SmartUpdate before running this   
            script."); 
}
    else
       alert("Enable Java before running this script.");

</SCRIPT>
</HEAD>
<BODY>
</BODY>
</HTML>




 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.