InfoCenter Home > 4.7.1: Applet client programming modelThe Java Applet client provides a browser-based Java runtime that is capable of interacting with EJBs directly instead of indirectly through a servlet. This client is designed to support those users who want a browser-based Java client application
programming environment that provides a richer and more robust environment than the one offered by the
The programming model for this client is a cross between the Java application thin client and a servlet client. When accessing EJBs from this client, the EJB object references can be considered CORBA object references by the applet. There is no tooling support for this client for developing, assembling or deploying the applet. You are responsible for developing the applet, generating the necessary client bindings for the EJBs and CORBA objects, and bundling these pieces together to be installed on or downloaded to the client machine. The Java applet client provides the necessary runtime to support communication between the client and the server. Client side bindings are generated during the deployment phase of J2EE development using the Application Assembly Tool. An applet can utilize these bindings, or you can generate client side bindings using the rmic command that is part of the IBM JDK installed with the WebSphere Application Server. See article Packaging and distributing Java clients for more information. The Applet client makes use of the RMI-IIOP protocol. The use of this protocol enables the applet to access EJB references and CORBA object references, but it is restricted in the usage of some supported CORBA services. If you combine the EJB and CORBA environments in one applet, you must understand the differences between the two programming models, and you must use and manage each appropriately. The Applet client provides the runtime to support the J2EE Applet client. The J2EE Applet client does not have any tooling support for developing, assembling or deploying the Applet. The applet client runtime is provided through the use of the Java applet browser plug-in that is installed on the client machine using the WebSphere Application Server Client CD. Because the Applet client does not provide for a deployment descriptor, the Applet code cannot make use of the JNDI java:/comp lookup. The Applet must know the fully qualified location of the EJB in the JNDI namespace. For example, the JNDI:java:/comp allows lookup of enterprise java beans using a short name or a nickname such as: java.lang.Object ejbHome = initialContext.lookup("java:/comp/env/ejb/MyEJBHome"); MyEJBHome = (MyEJBHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, MyEJBHome.class);But the code in an applet client must be more explicit: java.lang.Object ejbHome = initialContext.lookup("the/fully/qualified/path/to/actual/home/in/namespace/MyEJBHome"); MyEJBHome = (MyEJBHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, MyEJBHome.class);The Applet environment restricts accessing external resources from the browser runtime environment. Some of these resources can be made available to the Applet by setting the correct security policy settings in the JRE java.policy file. If given the correct set of permissions, the Applet client must explicitly create the connection to the resource using the appropriate API (JDBC, JMS, and others). This client does not perform any initialization of any of the services that the client applet may need. For instance, the client application is responsible for the initialization of the naming service, either through CosNaming or JNDI. The following table describes the advantages and disadvantages of the Applet client:
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|