Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Obsolete Pages
Overview
Java Web Start (JWS) is a one-click deployment solution for Java applications on the desktop. Leveraging the Java Network Launch Protocol (JNLP) API, Java Web Start gives you a way of deploying applications from a web server and automatically downloading the files and runtime environment needed by the application.
How does it work
The application itself is written as any other application is written. The magic happens in the packaging.
The application's JAR file is placed in a WAR file together with a .jnlp file (the launch file). This tells Java Web Start on the client what to download and allows it to check whether it already has the application installed.
In the simplest form all that is required is a normal hyperlink to the jnlp file, this then launches the application if it is present on the client or downloads the necessary files if it is not.
For a developer Java and/or JWS (JWS is part of J2SE from 1.4 onwards) is probably already installed. However, for an end user they may not be. In this case the webapp has to determine what is installed in order to know what link to display. Some JavaScript/VBScript can be used to determine if JWS is installed and from that either display a link to the jnlp file or to a page that downloads the required JRE and then launches the application after (Windows only).
An optional versioning mechanism is used for the JAR files that make up the application, it is this that allows the client to determine whether it has the latest version or not. If possible the servlet used for processing the JWS requests will send just the JAR differences back to the client to save on network resources.
The splash screen can be customised.
Usage
I adapted one of the samples that comes with Java 1.5. It's a basic notepad application allowing local file access and interaction with the webapp that loaded it. This seemed fairly similar to the usage scenario we require.
I got the web application setup and successfully got the application to download and install itself. Successive clicks to launch the application were certainly quicker than the initial download so it definitely does what it says on the tin.
The notepad application is able to browse and open files, save them, print them, use the system clipboard and send the contents of the editor back to the webserver. It also remembers the contents of the editor when the application exits and re-displays it when the application is re-launched.
The application was NOT signed but could still access local resources by utilising the JNLP APIs. There are a set of services i.e. FileOpenService, ClipboardService, that allow access to local system resources without the need to sign the code. However, the user still gets a warning message about the security implications (which they can supress for the session).
What this proves though is that a JWS based application could certainly be used for checkin/checkout type operations but we will probably want to sign the code rather than using the JNLP APIs.
Issues & Comments
- The one-click install only works for IE on Windows. Firefox support is expected in the J2SE 6.0 timeframe (beta at end of the year, release in the middle of next year)
- Only admin users of the client machines can use the app as it has to install the JRE onto the machine and therefore needs administrator privileges
- The main theme of the 6.0 release is ease-of-deployment, which implies that it currently isn't very good!
- When any change is made to the application it takes two launches to run the latest version. The first time the application is launched (after a change) the changes are detected but the current version of the application is run. If you exit the application and launch it again you get the latest version!! The documentation for custom splash screen alludes to this saying that 'Note, however, that the first time the application runs, you would get the default screen, since the JAR file hasn't come across the system yet.'
- Although the JNLP APIs are available we would probably still want to sign the code but this introduces all the certificate issues i.e. they expire and need re-newing
- Even with the code signed it still won't be completely transparent, the first time it is run the user will be asked if they trust the code, they can of course answer 'Always Trust' which should supress the prompt in future
Conclusion
It's definitely better than the old applet stuff as far as installing code on the client goes but it still feels really 'cludgy'.
The code signing and user privileges issues we had working on other content management systems are also going to re-appear.
The ultimate one-click solution only works for IE on Windows, for Firefox you get the standard 'Open With' dialog asking what should be done with a JNLP file. So if we are going this route for transparency reasons I'm not sure it's going to fly, users will be much more accustomed to doing the 'Save Target As' approach.
I'm wondering whether it would be better to have a client piece for those users that want it but it's something that you manually install on each desktop i.e. it's trusted because it was installed.
