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.
LoadableAppletInterface
ApplicationAn 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>
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 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."
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
:
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.
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.
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>");
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.
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';
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.
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.
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 ]