April 23, 2011, 4:24 a.m.
posted by franni
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:
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:
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.