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
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)
<?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>
location of the .jnlp file
relative to the codebase; in
this example it is in the root
directory of the web server
<?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>
means that the user can run
the app without being
connected to the internet;
however, if offline then
automatic updating wont work
information tags are used by
the JWS helper app; useful for
displaying info to the user
<?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>
needs version 1.3 or
greater to run properly
<?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>
name of the
executable JAR
<?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>
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
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 doesnt 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

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 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 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
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