Applet Clients in WebSphere

Applet Clients in WebSphere

Few parts of Java emerged with as much hype, or disappeared with as little fanfare, as the Java applet. Once considered to be a crucial part of Java technology, movement in the Java technology space has lately delegated it to the status of an "also-ran" among Java programming models. While initially heralded for its ability to provide easily accessible client code that was "write once run anywhere" and for innovative features like the built-in security sandbox, in fact, the Java applet has become a seldom-used part of the J2EE developer's tool box.

There are a few basic reasons for this, most of which derive from the difference between the perceived needs of the Web community and the actual needs of corporate developers. In short, they are:

  • Applets were initially envisioned as being a way to provide rich client interfaces that HTML alone could not provide. However, in the intervening years since the release of Java 1.0, it has become clear to most developers that very rich user interfaces can be developed using HTML and JavaScript. As a result, often the same results can be achieved with less overhead (and at a lower cost) using these technologies than can be achieved using Java applets.

  • The promise of "write once, run anywhere" was torpedoed by Microsoft's abandonment of Java on the browser and its subsequent refusal to upgrade its JVM beyond the antiquated 1.1.3 level. While the Java language has continued to evolve and improve its standard class libraries, the reality of having to work with a back-level environment has made it difficult for developers to conceive of writing applets that will run on Internet Explorer, by far the most popular Web browser. While this can be mitigated through the use of the Java Plug-in,[1] which provides an improved JVM to the browser, the perceived benefits of applet code downloading become faint when compared to the real worry of having to periodically upgrade the Java Plug-in across thousands of client desktops.

    [1] The Java Plug-in is an installation option for most JREs and JDKs, including the IBM JRE that comes as part of WebSphere.

  • The very abilities that business customers most want from their rich-client desktop applications, such as the ability to print to local printers, to save temporary data files to a disk, or to connect to more than one back-end machine for obtaining corporate data, are the very abilities that are most difficult to provide in an applet environment. While you can relax the security sandbox restrictions through signed applets, this remains an annoyance that many developers don't want to deal with.

As a result of these drawbacks, most corporate users have abandoned applets in favor of application clients. However, if you believe you can live within the limitations of an applet, and you are convinced that it is your best client programming option, how can you connect to back-end EJB resources in WebSphere from an applet? WebSphere supports applets that connect to EJBs only through a special version of the Java Plug-in, referred to as the WebSphere applet client. The WebSphere applet client provides the special environment necessary to allow applet clients to communicate to WebSphere servers via RMI-IIOP. No other Java Plug-in version can provide the necessary environment. The WebSphere plug-in must be installed on a client browser either from the WebSphere installation CD or from a remote network location. Once you have installed the WebSphere applet client, there are some further restrictions that you must live within:

  • The WebSphere applet client only works on some levels of browsers (Internet Explorer 5.0 and above, and Netscape Navigator 4.7 and above), and only in Windows NT and Windows 2000.[2]

    [2] As of the time of this writing, the applet client was not yet certified to run on Windows XP.

  • The WebSphere applet client is limited in that it does not support Secure Sockets Layer, which means that authentication information must pass in clear text.

  • There are a number of runtime parameters that may need to be set up in the WebSphere applet client control panel before you can use the applet (see the InfoCenter for more details).

  • As with all other applets developed using the Java Plug-in, you have to use the Object embed tag to load your applet (instead of the standard <applet> tag) and set up the properties file correctly.

In the end, this turns out to be a lot of work for the developer and probably not worthwhile unless you're primarily developing intranet applications where you completely control the client desktop. Since application clients don't solve the client update problem, and since applets are so limited in what they can do, what is a developer of Internet or extranet applications supposed to do?

Here is an option that may work. Instead of using RMI-IIOP to connect from your applet or application to your EJBs, consider communicating over HTTP using SOAP. In many respects this is probably an easier choice, since there are fewer restrictions, and it will work with nearly any JDK/browser combination. We will cover this option in more depth in Chapters 30 and 31.

If you do choose to write an application client that uses SOAP over HTTP, you can solve the download and update problem in a simple way by using one of a number of new technologies, like Sun's Java WebStart, that implement the Java Network Launch Protocol (JNLP) standard. Java WebStart provides you with the ability to dynamically download and update a standard application client program that does not suffer from the restrictions of an applet. Java WebStart is a feature of Sun's JDK 1.4; since WAS 5.0 is currently based on Java 1.3.1 it's not supported yet by IBM as an official WebSphere client technology. However, there is nothing to prevent you from using Sun's JDK 1.4 to develop your client applications (even inside WebSphere Studio, which allows you to configure the JDK for each Java project) and then simply package the applications with the necessary SOAP jar files.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows