Java Rich Internet Applications Guide > Java Rich Internet Applications Development and Deployment
The following topics are covered:
Java technology based solutions are versatile when developed with good design principles. There are three major kinds of solutions depending on their deployment mechanism and execution context:
Applets – These solutions run in the context of a web browser. They utilize the browser capabilities like session cookies, DOM access etc. Applets may be deployed by using Java Network Launch Protocol (JNLP) or by using applet tag attributes.
Applets and Java Web Start applications are now referred to as rich internet applications (RIAs) - Java programs that take advantage of the Internet.
In the past, the decision of whether to deploy a RIA inside the browser as an applet, or outside the browser as a Java Web Start application, could significantly impact the design of the solution. With technology introduced in the Java SE 6 update 10 release, these two deployment options have been substantially unified, so that properly structured programs can be easily deployed either inside or outside the browser.
A key methodology to follow during the design of your app is to use
a component-based architecture. Traditional applications
tend to construct their user interfaces, including the top-level
Frame, in the main method. This programming style
prevents easy re-deployment of the app in the browser, because it
assumes that the app creates its own Frame. When running in the
browser as an applet, the applet is implicitly the container that
should hold the user interface for the app, and no top-level Frame
is needed or desired.
Instead, during the development of your app, try to organize its
functionality into one or more components that can be composed
together. In this context, the term "component" refers to a GUI
element that subclasses from the AWT Component class,
the Swing JComponent class, or another subclass.
Rather than phrasing the app in terms of various methods which
build user interfaces and return or show them, instead phrase the
app in terms of various Component subclasses, each of
which adds their portion of the user interface to themselves. Then
the app, which at that point is just a Component (and perhaps, for
example, a menu bar) can easily be added to any kind of Container.
The container might be a top-level Frame or an Applet. Using this
methodology and architecture makes it easy to redeploy the app
either inside or outside the browser, and allows this deployment
decision to be changed at essentially any time without
significantly impacting the development cycle of the app.
The SwingSet2 demo is an example that shows how to
lay out components in a single cohesive unit. This demo is included in the
JDK 7
Demos and Samples bundle that you can download. The constructor of the
ButtonDemo class instantiates and lays out all required user
interface components into one master panel. The DemoModule class is
only responsible for displaying this master panel as an applet.
This design enables the ButtonDemo to be reused or ported easily to
another applet or application.
To determine whether to develop an applet or a Java Web Start application, see Rich Internet Applications Decision Guide.
Having decided on the type of client app you plan to build, the next step is to build it. For applets, use the Applet Developer's Guide to set up the applet, get the browser and the applet talking to each other, and to communicate with other applets. For Java Web Start applications, use the Java Web Start Developer's Guide.
Debugging is a natural part of development. In addition to using your Java IDE or the Java debugger, you can use the debugging facilities in the Java Console, as well as the JVM's Tracing and Logging capabilities.
The Deployment trail in the Java Tutorials is a comprehensive resource to learn more about the development and deployment of RIAs.
Signing the application JAR files with a valid public key certificate and specifying the runtime permission in the JAR file manifest are critical. Applications that are deployed without these elements might not be allowed to run in some circumstances.
Deployment is a multi-step process. Many of the steps are optional, but they are all intended to improve the end-user's experience. The following is an overview of deployment related steps. See Rich Internet Applications Deployment Advice for more information.
JNLP File: A JNLP file is created for Java Web Start
applications and applets that will be deployed using JNLP. If the RIA requires
access to resources on the user's system, you'll need to include the security
element in the JNLP file. Otherwise, the RIA runs in the security sandbox. See
JNLP File Syntax
for information on the JNLP file.
JAR File Manifest: The JAR file manifest contains security and configuration information about the JAR file and the files it contains. Attributes introduced in the JDK 7u25 and JDK 7u45 releases provide additional security for RIAs. See JAR File Manifest Attributes for Security for more information.
Security Certificate: RIAs request permission from the user to run the first time they are launched, whether they run in the security sandbox or require access to a user's system. Sign and time stamp the JAR file for the RIA with a certificate from a recognized certificate authority. See Security Dialogs and Security for more information.
JAR Indexing: To keep the app from downloading JAR files before they're needed, you'll want to use JAR Indexing. Jar Indexing works both for applets and Java Web Start applications. With Jar Indexing, the main jar contains an index file that tells which packages are in the other jars. When lazy-loading a resource, the underlying classloader uses the index to know what jar file to download. Make sure that you create the index before you sign the JAR file.
Pack200 Compression: See Pack200 and Compression for Network Deployment for information on how to use Pack200 compression to minimize download time for JAR files.
For enterprises that provide a common execution environment and manage the applications that users access, the Deployment Rule Set feature enables the creation of rules that allow some applications to be run without security prompts while automatically blocking other applications. This feature is intended to be used internally in an organization. See Deployment Rule Set for more information.
For users who need to run RIAs that are blocked because they do not meet current security requirements, the Exception Site List feature is provided. RIAs that are started from sites in the list prompt the user for permission to run. See Exception Site List for more information.
To understand how the deployment of RIAs is handled, see Rich Internet Application Deployment Process.
