Java WebStar, 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

http://docs.oracle.com/javase/tutorial/deployment/webstart/

http://java.sun.com/docs/books/tutorial/deployment/doingMoreWithRIA/index.html

http://java.sun.com/docs/books/tutorial/deployment/doingMoreWithRIA/index.html

http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/contents.html

http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/contents.html

http://www.clarkson.edu/~jets/cs242/fa13/exams/exam2.html

http://www.clarkson.edu/~jets/cs242/fa13/hw/pr2.html

Executable Jar

Web Start RMI app Servlets

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>

<application-desc main-class=“HelloWebStart”/> </jnlp>

codebase is the root

directory of where the

files are located (localhost

in this example)




location of the .jnlp file

relative to the codebase; in

this example it is in the root

directory of the web server




means that the user can run

the app without being

connected to the internet;

however, if offline then

automatic updating won’t work

information tags are used by

the JWS helper app; useful for

displaying info to the user




needs version 1.3 or

greater to run properly




name of the

executable JAR




basically like the

manifest ; this tells you

which class in the JAR

contains main()

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

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html

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 { 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"); } } }

/*Execute a job on the event-dispatching

thread; creating this applet's GUI. */

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

http://docs.oracle.com/javase/tutorial/deployment/applet/index.html

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.

http://java.sun.com/docs/books/tutorial/deployment/applet/deployingApplet.html

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 full-featured 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 1st 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 Jar

Web Start RMI app Servlets

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

http://developer.android.com/index.html

Java WebStar, Applets & RMI

Documents

Transcript of Java WebStar, Applets & RMI