IBM Books

Host Access Beans for Java


Appendix B. Using the Loadable Applet Interface

Introduction

The Host On-Demand (HOD) server provides optional support for storing HOD-specific libraries in the cache of the client browser. Netscape Navigator and Microsoft Internet Explorer browsers are specifically supported.   This mechanism operates for applications implementing the loadable applet interface, com.ibm.eNetwork.HOD.common.cached.LoadableAppletInterface.

You can develop custom applications of this type using the Host Access Class Library (HACL) and Host Access Beans for Java (HABJ). When served from the HOD server, the libraries for HACL and HABJ can be cached to the client browser. In this discussion, the term "application" indicates Java code that does work.

This facility will not cache or manage your non-HOD custom libraries (Java archive (JAR) and cabinet(CAB) files).

Your custom application class files and libraries should reside in the HOD published directory. Do not combine them into any of the HOD libraries, because that is not permitted by your license agreement. Reconstituted Host On-Demand libraries will be rejected by the caching mechanism.

The Essentials of a LoadableAppletInterface Application

An HTML page created with Deployment Wizard can launch an application implementing the LoadableAppletInterface interface. First, the browser loads and launches a HOD-proprietary class, CachedAppletLoader. That class in turn loads and launches your custom LoadableAppletInterface application.

This is accomplished dynamically by HOD JavaScript functions that write a new HTML page using document.write(...) statements. See a JavaScript manual for more information on how to write dynamically written HTML pages that are auto-launched in a browser environment.

The Deployment Wizard-based HTML page generates a final HTML page with the following line:

   <APPLET
    ...
    CODE="com.ibm.eNetwork.HOD.cached.appletloader.CachedAppletLoader"
    ...
   >

That class takes a parameter named: hod_AppName, which is available through the HTML line:

   var hod_AppName='';

It is customized by filling in the name of your custom appliation that implements the LoadableAppletInterface interface:

    var hod_AppName='my_custom_app_name';
   <APPLET
    ...
    ARCHIVE=CachedAppletSupporter.jar,someCustomLib.jar MAYSCRIPT NAME=\"HODApplet\"
    ...
   >

The custom supporting CAB library is specified as:

   <APPLET ...>
    ...
    <PARAM NAME=Cabinets VALUE=CachedAppletSupporter.cab,someCustomLib.cab">;
    ...
   </APPLET>

What the Browser Does and Doesn't Know

The browser Java virtual machine (JVM) loads and launches CachedAppletLoader. The browser is unaware that CachedAppletLoader has loaded and launched your custom class.

For this discussion, the CachedAppletLoader instance is referred to as theRealApplet. It is the "real applet" because the browser loaded and launched it. The browser is only aware of theRealApplet.

Your custom application is a child of theRealApplet. The relationship is supported by four interface methods:

    public void setApplet(Applet theRealApplet);
    public void init();
    public void start();
    public void stop();

Three of these methods, init(), start() and stop() have the same meaning as the analogous methods in java.awt.Applet.

setApplet(Applet theRealApplet) Is Called First

When CachedAppletLoader loads and launches your custom application, the first method called is setApplet(Applet a). CachedAppletLoader passes in a reference to itself. The following is an example of custom application code:

    ...
    protected Applet theRealApplet = null;
    ...
    public void setApplet(Applet a) {
          this.theRealApplet = a; //remember who my parent, an applet, is
    }

The following is an example of code for calling the start() method of your application by using CachedAppletLoader:

    public void start() {
          ... //do some preparation and then...
          if(this.theRealApplet != null ) {
             displayThis(<a GUI component that does the real work>);
          }
    }

    // show the work component in the browser page to the user
    public void displayThis(Component component) {
       this.theRealApplet.removeAll(); // just to be safe
       this.theRealApplet.add(component,null); // insert the new GUI component
   
       //ask my parent for the top level non-Window Component
       Component topComponent = getTopComponent(this.theRealApplet);
       //visualize me reliably in the browser page
       topComponent.setVisible(true);
       topComponent.validate();
       topComponent.repaint();
    }

    // climb the heirarchy as needed
    public Component getTopComponent( Component containingThisComponent ) {
       Component topComponent = containingThisComponent;
       Component nextComponent = topComponent.getParent();
       while( (nextComponent != null) && !(nextComponent instanceof Window) ) {
             topComponent = nextComponent;
             nextComponent = topComponent.getParent();
       }
       return topComponent;
    }
   

The RealApplet Is the Displayer

The repaint code above is needed to display your custom GUI component. Without it, your custom GUI component may not be visible in the browser page! Notice that there is no requirement that your LoadableAppletInterface application be the visible GUI component. For example, your custom application may be a server that marshals successive GUI components for display in the browser page, only to be removed and replaced by others. Remember to trigger the display of each GUI component after its insertion into "the real applet."

Using the Deployment Wizard

The HOD Deployment Wizard is an integral part of this process. The terse instructions that follow assume that you have familiarized yourself with the Deployment Wizard. Please first read the documentation and practice using Deployment Wizard to configure customized client HTML pages.

The Deployment Wizard is used to create a custom HTML page in the HOD published folder. The following sections show how to modify that HTML file to specify your custom application that implements the LoadableAppletInterface:

Deploying in a Java 1 Environment

In a Java 1 environment, the custom application is built using JDK1.1 and is intended to run in a JDK 1.1 browser environment without a Java 2 Plug-in.

First, use the Deployment Wizard to create a custom HTML file. Specify "Client Java Type: Java 1". Since you will be providing your own Terminal (or Session), you do not need to worry about selecting a configuration model. You can skip over most panels except for those that specify the Client Java Type, the Preload Options, and the final panel that allows you to specify the name of the output HTML file. Under Preload Options, uncheck all options that are not needed to support your custom application. This minimizes the total size of the downloaded and cached libraries. Finally, name this customization CustomJdk11Caching.html. Create it and exit Deployment Wizard.

This example assumes that the JDK1.1-based application that implements the LoadableAppletInterface interface is named: lai0.JDK118App, where lai0 is the package name.

In CustomJdk11Caching.html look for this:
       var hod_AppName='';
and change it to :
       var hod_AppName='lai0.JDK118App.class';
or this:
    var hod_AppName='lai0.JDK118App';
Either way is acceptable in the Java 1 environment, but the ".class" style is preferred.

Using loose classes in a Java 1 Environment

If you are planning to use loose classes (that is, no JAR or CAB files), copy the lai0 folder and its contents to \hostOn-Demand\HOD. No further modification of CustomJdk11Caching.html is needed.

Using a signed JAR or CAB library in a Java 1 Environment

Let's assume that your digitally signed custom library has the base name: myLib_J1. You need to further modify CustomJdk11Caching.html as follows:

To support Netscape Navigator, look for this line:
       document.write("<APPLET ARCHIVE=CachedAppletSupporter.jar MAYSCRIPT NAME=\"HODApplet\"
and change it to:
       document.write("<APPLET ARCHIVE=CachedAppletSupporter.jar,myLib_J1.jar MAYSCRIPT NAME=\"HODApplet\"

To support Internet Explorer, look for this line:
       document.write("<PARAM NAME=Cabinets VALUE=CachedAppletSupporter.ca>");
and change it to:
       document.write("<PARAM NAME=Cabinets VALUE=CachedAppletSupporter.cab,myLib_J1.cab>");

Running the custom application with caching in a Java 1 Environment

The first time a local browser accesses CustomJdk11Caching.html on the HOD server, the caching mechanism will detect that this is "the first time." Therefore the caching operator will download all of the HOD-specific libraries enumerated in the Deployment Wizard step. Then a restart of the browser will launch the custom application. Thereafter any latency is due to the first download of the non-HOD libraries. These will be stored in the browser temporary chache and will be available without further downloading until the browser is closed.

Deploying in a Java 2 Environment

In a Java 2 environment, the custom application is built using SDK 1.3 (or higher) and is intended to run in a browser that does have a Java 2 Plug-in installed.    In this environment, only JAR libraries are meaningful. Internet Explorer with a Java 2 Plug-in is equivalent in its operation to Netscape with a Java 2 Plug-in. The Java 2 Plug-in is the dominant, controlling factor.

First, use the Deployment Wizard to create a custom HTML file. Specify "Client Java Type: Java 2." Since you will be providing your own Terminal (or Session), you do not need to worry about selecting a configuration model. You can skip over most panels except for those that specify the Client Java Type, the Preload Options, and the final panel that allows you to specify the name of the output HTML file. Under Preload Options, uncheck all options that are not needed to support your custom application.  This minimizes the total size of the downloaded and cached libraries. Finally, name this customization CustomJava2Caching.html. Create it and exit the Deployment Wizard.

This example assumes that you have written a Java 2-based application that implements the LoadableAppletInterface interface and that application is named: lai0.Java2App, where lai0 is the package name.

In CustomJava 2Caching.html look for this line:
    var hod_AppName ='';
and change it to :
    var hod_AppName ='lai0.Java2App';

Note: In the Java 2 case the following does not work:
    var hod_AppName ='lai0.Java2App.class';

Using loose classes in a Java 2 Environment

The Java 2 version of this mechanism operates only with loose classes. Therefore, you need to copy the lai0 folder and its contents to \hostondemand\HOD. No further modification is needed.

Running the custom applet with caching in a Java 2 Environment

The first time a local browser accesses CustomJava2Caching.html on the HOD server, the caching mechanism will detect that this is "the first time." Therefore the caching operator will download all of the HOD-specific libraries enumerated in the Deployment Wizard step. When the download of cached libraries has completed, the custom application will start immediately (browser restart is purely optional). Thereafter any latency is due to the first download of the non-HOD libraries.

Compatibility of the Java 1 and Java 2 Versions

Remember that JDK 1.1-based custom classes run compatibly in a Java 2 environment. Likewise, JDK 1.1-based HOD classes will run compatibly in a Java 2 environment. However, the reverse is not true: Java 2-based HOD classes will fail when run in a JDK 1.1 browser environment.


[ Top of Page | Previous Page | Next Page | Table of Contents ]