Java WebStart, Applets & RMI

Java WebStart, Applets & RMI 11-13-2013

Java WebStart & Applets RMI Read: Java Web Start Tutorial Doing More with Rich Internet Applications Java Web Start guide Exam#2 is scheduled for Tues., Nov. 19, 7:00 pm, Snell 213 PR#2 due: Wednesday, 12/04/13 No lecture on Friday, 11/15 work on your project

Executable Web Start RMI app Servlets Jar 100% Local 100% Remote Executable JAR Web Start RMI Java Server Faces, JSP & Servlets Note: thin (web) clients run mostly on the server; rich clients run mainly on the client machine

The client runs a web browser. The client also needs Java and the Java Web Start helper app. client can easily download JWS client can easily download Java or update the version The server has a web page with a link to a file which can launch the executable JAR (more on this later) When the client clicks on that link, JWS downloads and launches the app on the client machine by invoking the main() method

Once downloaded, the app runs on the client machine, as a stand-alone application Since the app has been downloaded to the client, it can run from the JWS helper app independently of the browser. If the code is changed on the server side, JWS automatically downloads and integrates the updated code Is this a good idea? Do you trust the app?

A.jnlp file is an xml file which contains information about the executable jar codebase is the root of where the web start files are located on the server information must include: title, vendor, homepage, description, icon and offline-allowed tags resources states what version of Java is needed resources also has the name of the jar file application-desc states the main() method class

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> codebase is the root directory of where the files are located (localhost in this example) <application-desc main-class= HelloWebStart /> </jnlp>

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> location of the.jnlp file <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> relative to the codebase; in this example it is in the root directory of the web server <application-desc main-class= HelloWebStart /> </jnlp>

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> information tags are used by the JWS helper app; useful for displaying info to the user means that the user can run the app without being connected to the internet; however, if offline then automatic updating won t work <application-desc main-class= HelloWebStart /> </jnlp>

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> needs version 1.3 or greater to run properly <application-desc main-class= HelloWebStart /> </jnlp>

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> name of the executable JAR <application-desc main-class= HelloWebStart /> </jnlp>

<?xml version= 1.0 encoding= utf-8?> <jnlp spec= 0.2 1.0 codebase= http://127.0.0.1/~jets/cs242 href= MyApp.jnlp > <information> <title>cs242 app</title> <vendor>clarkson</vendor> <homepage href= index.html /> <description>cs242 webstart demo</description> <icon href= cs242.gif /> <offline-allowed/> </information> <resources> <j2se version= 1.3+ /> <jar href= MyApp.jar /> </resources> basically like the manifest ; this tells you which class in the JAR contains main() <application-desc main-class= HelloWebStart /> </jnlp>

1. Make an executable JAR 2. Write the.jnlp file 3. Place the JAR and.jnlp files on your web server 4. Add a new mime type to your web server application/x-java-jnlp-file 5. Create a web page with a link to your.jnlp file <html> <body> <a href= MyApp.jnlp >Launch my app</a> </body> </html>

The client clicks on a web page link to your Java Network Launch Protocol file (.jnlp) The web server (HTTP) gets the request and sends back the.jnlp file (not the JAR) Java Web Start, a small helper app on the client, is started by the browser. It reads the.jnlp file and asks the browser for the MyApp.jar file

The web server serves up the requested.jar file Java Web Start gets the JAR and starts the application just like any executable JAR The next time the user wants to run this app, can just open the Java Web Start application and launch the app (no need to be online) Also see the Java tutorial on setting the security level of the client

An applet is a special kind of Java program that a browser enabled with Java technology can download from the internet and run. An applet is typically embedded inside a web page and runs in the context of a browser. An applet must be a subclass of java.applet.applet or javax.swing.japplet javax.swing.japplet is a class which is used for all applets that use Swing components to construct their graphical user interfaces (GUIs).

/* Copyright (c) 1995-2009 Sun Microsystems, Inc. */ import javax.swing.japplet; import javax.swing.swingutilities; import javax.swing.jlabel; public class HelloWorld extends JApplet... // see next slide for the code Note: an applet that doesn t use Swing can extend the Applet class

public class HelloWorld extends JApplet { //init is called when this applet is loaded into the browser. } } public void init() { try { /*Execute a job on the event-dispatching thread; creating this applet's GUI. */ SwingUtilities.invokeAndWait(new Runnable() { public void run() { JLabel lbl = new JLabel("Hello World"); add(lbl); } }); } catch (Exception e) { System.err.println("createGUI didn't complete successfully"); }

An applet can react to major events in the following ways: It can initialize itself. It can start running. It can stop running. It can perform a final cleanup, in preparation for being unloaded. Unlike Java applications, applets do not need to implement a main method.

The Java Plug-in creates a worker thread for every applet. It launches an applet in an instance of the Java Runtime Environment (JRE). Normally, all applets run in the same instance of the JRE, but they can run on other JREs

To deploy your applet, first compile the source code and package it as a JAR file. Applets can be launched in two ways. You can launch an applet by specifying the applet's launch properties directly in the applet tag. This old way of deploying applets imposes severe security restrictions on the applet. Alternatively, you can launch your applet by using Java Network Launch Protocol (JNLP). Applets launched by using JNLP have access to powerful JNLP APIs and extensions. for details, see the Java tutorial on applets

With recent improvements to the Java Plug-in software, unsigned applets launched using Java Network Launch Protocol (JNLP) can safely access the client with the user's permission. It is recommended that you launch your applet using JNLP to leverage expanded capabilities and improve user experience. See Deploying an Applet for step by step instructions on applet deployment.

Key difference: the user experience. There are other differences, but this is the fundamental one. Applets are always run within a web browser, typically with a Java plug-in. If the Java application/applet needs to interact with a web page and be tightly bound to a web browser, then use applets. On the other hand, if browser independence is important, then Java Web Start is the deployment platform of choice. The application does not depend on an open browser to function. The browser can be shut down or you can go to a different web page and the application will continue running.

Java Web Start enables users to download fullfeatured applications with any browser. Ease of writing: Must design an Applet from the start You can turn any java app into JWS by adding a.jnlp file and possibly an installer class Start-up time Applet must be downloaded each time it is run After the 1 st time, JWS app is only downloaded when it changes on the server Run-time Applet is sharing resources with the browser JWS runs directly on java.exe hotspot

Applications launched with Java Web Start are, by default, run in a restricted environment, known as a sandbox. In this sandbox, Java Web Start: Protects users against malicious code that could affect local files Protects enterprises against code that could attempt to access or destroy data on networks Unsigned JAR files launched by Java Web Start remain in this sandbox, meaning they cannot access local files or the network.

Java Web Start supports signed JAR files so that your application can work outside of the sandbox described above, so that the application can access local files and the network. Java Web Start verifies that the contents of the JAR file have not changed since it was signed. If verification of a digital signature fails, Java Web Start does not run the application. The security issues have not yet been fully resolved at this time.

When the user first runs an application as a signed JAR file, Java Web Start opens a dialog box displaying the application's origin based on the signer's certificate. The user can then make an informed decision regarding running the application. For a signed JAR file to have access to the local file system and network, you must specify security settings in the JNLP file. For example, the following provides the application with complete access to the client system if all its JAR files are signed: <security> <all-permissions/> </security>

Executable Web Start RMI app Servlets Jar 100% Local 100% Remote Executable JAR Web Start RMI Java Server Faces, JSP & Servlets Note: thin (web) clients run mostly on the server; rich clients run mainly on the client machine

Dumb terminals supplanted by smart PCs Many systems now servers, responding to requests generated by clients Compute-server provides an interface to client to request services (i.e. database) File-server provides interface for clients to store and retrieve files

RMI allows a Java program on one machine to invoke a method on a remote object This is particularly useful when the remote machine is a powerful server and the client machine is a Java-enabled handheld

Key idea: make it possible for the client to invoke some method on an object that is stored on the server, as though it were calling a method on a local object e.g. Client wants to run: val = server.somemethod(a, B); You need four things: client, client helper (stub), server, server helper (skeleton)

Stub proxy for the remote machine Skeleton invokes the desired method & returns the result

Step one: make a Remote Interface e.g. MyRemote.java Step two: make a Remote Implementation e.g. MyRemoteImpl.java Step three: generate the stubs and skeletons using the rmic tool (in JDK) Step four: start the RMI registry In one terminal: % rmiregistry Step five: start the remote service In another terminal: % java MyRemoteImpl

import java.rmi.*; public interface MyRemote extends Remote { public String sayhello() throws RemoteException; }

import java.rmi.*; import java.rmi.server.*; public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { public String sayhello() { return Server says: Hello, World! ; } // continued on next slide

public MyRemoteImpl() throws RemoteException { } public static void main (String[ ] args) { try { /* make the remote object and bind it to the rmiregistry */ MyRemote service = new MyRemoteImpl(); Naming.rebind( Remote Hello, service); } catch(exception e) { ex.printstacktrace(): } } } // end MyRemoteImpl

Getting Started: Get the Android SDK http://developer.android.com/index.html Recommend: Eclipse + ADT plugin Install the SDK and Eclipse IDE Tutorial: Building your first app