Unlike typical applets that reside on either Web servers or WebSphere Application Servers and can only communicate using the HTTP protocol, the WebSphere Applet clients are capable of communicating over the HTTP protocol and the RMI-IIOP protocol. This additional capability gives the Applet direct access to enterprise java beans. As such, Applet clients have the following setup requirements:
-Djava.ext.dirs=<WAS_HOME>/Java/jre/lib;<WAS_HOME>/lib/ext; <WAS_HOME>/properties;<WAS_HOME>/Java/jre/lib/ext
As to the above command--
Standard applets require the HTML <APPLET> tag to identify the applet to the browser. The <APPLET> tag invokes the browser's Java Virtual Machine (JVM). Thus, an applet running on Internet Explorer uses the Microsoft JVM.
For applets to communicate with EJBs in the WebSphere Application Server environment, you must replace the <APPLET> tag with the following two new tags:Additionally, you cannot change the classid and type attributes and must enter them as described in the applet client example.
Finally, you must exclude the codebase attribute on the <OBJECT> tag. Do not confuse the codebase attribute on the <OBJECT> tag with the codebase attribute on the <PARAM> tag. Although both are called codebase, they are separate entities.
The following code snippet illustrates the applet code. In this example, MyApplet.class is the applet code, applet.jar is the file that contains the applet code, and EJB.jar is the file that contains the EJB code:
Note that the value of the type attribute on the <EMBED> tag can also be
<EMBED type="application/x-websphere-client, version=4.0" ...
The code used by an applet to talk to an EJB is the same as that used by a standalone Java program or a servlet, except for one additional property called Context.APPLET. This property informs the InitialContext and the ORB that this client is an applet rather than a standalone Java application or servlet.
When initializing an instance of the InitialContext class, the first two lines in this code snippet illustrate what both a standalone Java program and a servlet issue to specify the computer name, domain, and port. In this example, <yourserver.yourdomain.com> is the computer name and domain where WebSphere Application Server resides, and 900 is the configured port. After the bootstrap values (<yourserver.yourdomain.com>:900) are defined, the client to server communications occur within the underlying infrastructure. In addition to the first two lines, for applets, you must add the highlighted third line to your code. That line identifies this program as an applet and allows for parameters java.naming.provider.url and java.naming.factory.initial to be automatically retrieved from the applet html code:
|
prop.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); prop.put(Context.PROVIDER_URL, "iiop://<yourserver.yourdomain.com>:900"); |
| prop.put(Context.APPLET, this); |
When code is loaded, it is assigned "permissions" based on the security policy in effect. You can initialize this policy, specifying which permissions are available for code from various locations, from an external policy file. For each client, update the java.policy file with the classes that the applet client needs to access, and with the ports on the host machines where it needs different permissions.
Add the lines of code below to existing java.policy files. This code allows access to the required ports so that the applet client can communicate with an EJB.
In the example below, the java.net.SocketPermission "localhost:1024--", "listen" entry grants permission for Applets to open sockets for listening on the localhost for any port from 1024 to 65535. You can specify the port entry as a range of port numbers or a specific port. A port range specification of the form N-, where N is a port number, signifies all ports numbered N and above. A specification of the form -N indicates all ports numbered N and below.
The first SocketPermission statement grants permission to the client to have ports opened for listening. The second grants permission to open a port and make a connection to a host machine, which is your WebSphere Application Server. In this example, yourserver.yourcompany.com is the complete hostname of your WebSphere Application Server.
permission java.util.PropertyPermission "server.root", "read"; |
For more information on security relating to permissions and signed jars, read the official documentation for Java security architecture.
Although applications and applets differ in many ways, you enable security in the same way for both applets and applications. See the InfoCenter article "The Secure Association Service (SAS)" for more information on enabling a secure environment between servers and clients.
To enable security between the Applet client and a server, you must specify additional parameters. The following code snippets assume you are using DB2 as your database.
From the WebSphere Application Server Java Plug-in Control, enter:
-Djava.ext.dirs=<WAS_HOME>/Java/jre/lib;<WAS_HOME>/lib;<WAS_HOME>/lib/ext;<WAS_HOME>/properties;<WAS_HOME>/Java/jre/lib/ext
-classpath <PATH TO>db2java.zip
-Dserver.root=<WAS_HOME>
-Dcom.ibm.CORBA.ConfigURL=file:/<WAS_HOME>/properties/sas.client.props
When initializing an instance of the InitialContext class with security, add the following lines of code to the following code example, which is also used to run applets on a non-secure environment. The two new lines in this code snippet, allow the system to read the security file specified on the command line and identify the location of the application code on the client.
prop.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); |
prop.put("com.ibm.CORBA.ConfigURL",System.getProperty("com.ibm.CORBA.ConfigURL"));
|
To run the Applet client to a secure server, more permissions must be granted. You must add the following permissions to the java.policy file. In this example, the WebSphere runtime environment must have access to specific files and runtime parameters to run successfully with security.
grant codeBase "file:/<WAS_HOME>/lib/*" {
|
In this example, the jar files located on the host must have access to certain files and runtime parameters and logs to run successfully in a secure environment.
Grant codeBase "http://yourserver.yourdomain.com/<path to jar file(s)>/*"{
|
In this example, DB2 is granted permission to open a port and make a connection with the host machine, which is WebSphere Application Server. In the following permission, substitute the complete host name of your WebSphere Application Server for yourserver.yourcompany.com. Depending on the database that you are using, your permission and code base might differ from this example.
Grant codeBase "file:/<WAS_HOME>/WSsamples/Client/Applet/trade/db2java.zip" {
|
In this next example, the java.net.SocketPermission "localhost:1024-", "listen" entry grants Applets permission to open sockets for listening on the localhost for any port from 1024 to 65535. You can specify the port entry as a range of port numbers or as a specific port. A port range specification of the form N-, where N is a port number, signifies all ports numbered N and above. A specification of the form -N indicates all ports numbered N and below.
Grant {
|
For more information on using security with the client, see the security documentation in the InfoCenter article "Securing applications."
Learn more about the WebSphere Applet client by running the Applet samples. You can install the Applet client sample from the WebSphere Application Client CD. This sample is called HelloEJB and is installed in the product_installation/WSsamples/Client subdirectory on the client machine.
An additional sample is also available from WebSphere Developers Domain. Download the Applet client sample from the Samples for WebSphere Application Server Clients page. This sample is called Trade and is installed in the product_installation/WSsamples/Client subdirectory on the client machine. Instructions for configuring and running the sample are included in the download package.