Vom Web auf den Desktop

Java Software wird „desktopfreundlich“, dank Webstart.

Während Java sich schon seit geraumer Zeit im Bereich der dynamischen Webseitenerstellung in Form von Servlets und JSPs einer stets wachsenden Beliebtheit erfreut, so ist die Präsenz von Java auf dem Client bisher meist auf die Virtual Machine im Browser beschränkt.

Ein Grund dafür ist sicherlich die Frage, die seit den Anfängen von Java häufig gestellt wird: „Kann ich Java-Programme auch als eigenständige Applikation an den unerfahrenen Benutzer verteilen?“ Die Antwort war bisher immer ein deutliches „Jein“.

Zwar könnte man ein Skript starten, das den für die Ausführung einer Java-Applikation benötigten Aufruf der Java Virtual Machine beinhaltet, doch dies ist für die meisten Benutzer bereits zu kompliziert. Und auch die Compiler, die anstatt Bytecode nativen Code erzeugen, sind nicht der Schlüssel zur Lösung aller Probleme, denn sie vernichten eines der Hauptargumente für Java - die Plattformunabhängigkeit.

Abb. 1: Dialog während einer automatischen Aktualisierung.

Da diese durch das Zusammenspiel eines nativen, betriebssystemspezifischen Interpreters und der eigentlichen Applikation in Form von neutralem Bytecode erreicht wird, kann es in logischer Konsequenz auch kein komplett eigenständiges Java Programm geben.

Dies bedeutet auch, dass es bisher keine Möglichkeit zur komfortablen Installation von Java Applikationen gab, da keine Installationshilfen existieren, wie sie z. B. unter Windows sonst üblich sind. SUN hat sich nun diesem Problem der Benutzerfreundlichkeit im Bezug auf die Installation der Applikationen angenommen, und präsentiert als Ergebnis ein Produkt namens Webstart.

Einzelne Klicks und mehr ...

Während Applets schon seit geraumer Zeit durch die in fast jedem Webbrowser vorhandene Virtual Machine sehr komfortabel ausgeführt werden können, stellt der Start von Standalone-Applikatio-nen für unerfahrene Benutzer eine (meist zu hohe) Hürde dar. Webstart stellt für Standalone-Applikationen nun einen ähnlich komfortablen Mechanismus zur Verfügung, wie es bereits bei Applets üblich ist. Es bietet durch den Download der Programmdateien zusätzlich die Möglichkeit, onlinebasierte Applikationen gegebenenfalls auch offline zu betreiben.

Der sogenannte „Single-Klick-Start“ von Java Applikationen durch Verknüpfungen auf HTML Seiten beziehungsweise auf dem lokalen Desktop sorgt für Benutzerfreundlichkeit. Die automatische Prüfung auf Updates beim Start lässt auch Administratoren erleichtert aufatmen. Die Systemlast im Vergleich zu Applets ist ebenfalls geringer, da kein Webbrowser benötigt wird, um die Applikation zu betreiben. Momentan muss Webstart noch als separater Download bezogen und nachträglich auf dem System installiert werden. Ab der Version 1.4 des Java2 Runtime Environment (JRE) wird neben vielen anderen Neuerungen (siehe Artikel auf S. 5) auch Webstart zum Standard Lieferumfang gehören.

“easy living” ...

Zum ersten Starten beziehungsweise Herunterladen der Applikation muss der Benutzer lediglich einen Link auf einer entsprechenden Webseite anklicken und dadurch implizit Webstart anstoßen. Dieses präsentiert daraufhin einen Startbildschirm, der neben diversen Konfigurationsmöglichkeiten eine Liste der heruntergeladenen Applikationen zur Auswahl bietet.

Beim ersten Start der Applikation fragt Webstart automatisch nach, ob Verknüpfungen auf dem Desktop sowie im Startmenü (nur Windows) erstellt werden sollen. Sollten entsprechende Verknüpfungen angelegt worden sein, so lässt sich die Applikation von nun an, alternativ zum Aufrufen einer Webseite, direkt über diese Verknüpfung starten. Sie präsentiert sich dem Benutzer - das entsprechende Look-and-Feel vorausgesetzt - im „gewohnten Outfit“ wie jede andere native Applikation.

Den Vorteil für den Benutzer sieht SUN aber in erster Linie im Vergleich zu webbasierten Applikationen. Da diese zur Oberflächengestaltung lediglich HTML verwenden können, sind sie in diesem Bereich den lokalen Installationen bzw. Applets weit unterlegen. Gerade die Reaktionszeiten der webbasierten Applikationen bei Benutzereingaben bzw. -auswahlen stellen einen enormen Nachteil dar. Mit Webstart ist es z. B. möglich, eine typische Webmail-Oberfläche als lokale Applikation zu realisieren, so dass diese dann sowohl im Online- als auch im Offline-Betrieb gestartet werden kann.

... und was dahinter steckt

Was für den Benutzer viel Komfort bedeutet, bedarf natürlich auch einiger Arbeit im Hintergrund. Die Basis bildet das Java Network Launching Protocol (JNLP), welches auch als neuer MIME-Typ registriert und bei der Installation von Webstart in das System eingebunden wird. Ein Programm, das Webstart nutzen soll, kann eine beliebige Standalone-Applikation sein. Lediglich ein spezifisches XML-Dokument mit der Endung .jnlp wird benötigt.

Diese Datei dient zum Starten und Konfigurieren der Applikation. Sie wird wie jedes andere browserfähige Dokument verlinkt. Der Webbrowser assoziiert die Dateiendung .jnlp mit einem bestimmten MIME-Typ, der wiederum dafür sorgt, dass zur Interpretation der Datei Webstart verwendet wird. Hier ein Ausschnitt aus dem Inhalt einer jnlp-Datei inklusive Anmerkungen zu den wichtigsten Einträgen. Eine komplette, und detaillierte Liste aller Einträge ist im Internet auf den Java-Seiten der Firma SUN zu finden (http://java.sun.com/products/javawebstart/docs/developersguide.html).

[...]
<jnlp
	spec=“1.0+“
	codebase=“http://intranet.ordix.de/webapps/webstart-demo“
	href=“demo.jnlp“>
	<information>
		<title>ORDIX Demo Application</title>
		<homepage href=“docs/demo.html“/>
		<description>ORDIX Demo Application</description>
		<offline-allowed/>
	</information>
	<security>
		<all-permissions/>
	</security>
	<resources>
		<j2se version=“1.3"/>
		<jar href=“lib/demo.jar“/>
	</resources>
	<application-desc main-class=“startUp“>
		<argument>ArgumentOne</argument>
	</application-desc>
</jnlp>

• codebase: Analog zu Applets stellt dieser Pfad die Basis für alle weiteren relativen Pfade dar.
• href: Pfad relativ zur Codebase, der auf diese Datei zeigt.
• <offline-allowed>-Tag: definiert, ob die Applikation auch Offline gestartet werden kann, und kontrolliert auch das Verhalten der Updateprüfung.
• <all-permissions>-Tag: defaultmäßig werden alle Webstart Programme in einer eingeschränkten Umgebung gestartet. Über diesen Tag wird definiert, dass die Software uneingeschränkten Zugriff auf die Systemressourcen erlangen soll. Dies erfordert aber, dass alle JAR-Archive signiert sind.
• <ressources>-Block: Hier werden u. a. die Archive definiert, in denen sich die Ressourcen der Applikation (Bilder, Sound, etc.) befinden.
• <application-desc>-Tag: Hier können die Main-Klasse sowie gegebenenfalls benötigte Übergabeparameter definiert werden.

Abb. 3: Die Anwendungsauswahl von "Webstart".

Zwischen Strand und Sandkiste

Applikationen, die über Webstart gestartet werden, unterliegen ähnlichen Restriktionen wie Applets. Sie starten in einer „Sandbox“-ähnlichen Umgebung, allerdings ermöglicht die JNLP-API dem Entwickler den Zugriff auf lokale Ressourcen wie z. B. die Zwischenablage, installierte Drucker und das Dateisystem. Letzteres allerdings nur über Filerequester, die vom Benutzer bedient werden.

Zusätzlich zur JNLP-API bietet Webstart auch in der spezifischen jnlp-Datei die Möglichkeit, zusätzliche Rechte für die Applikation zu beantragen. Dies erfordert allerdings, dass alle JAR-Archive der Applikation entsprechend digital signiert wurden.

Wichtig ist - aus Entwicklersicht - noch eine bedeutende Einschränkung bezüglich des Zugriffs der Applikation auf benötigte Ressourcen. Diese müssen sich komplett in einem der JAR-Archive befinden, die in der jnlp-Datei als Ressourcen definiert wurden.

Grund hierfür ist, dass Webstart lediglich den Transfer der JAR-Archive vom Server zum Client organisiert. Der Client entscheidet weiter, wo die Dateien gespeichert werden. Deshalb, und nicht zuletzt auch aus Sicherheitsgründen, kann und darf eine Webstart Applikation nicht mit Referenzen relativ zum lokalen Dateisystem arbeiten.

Wo Licht ist

... ist bekanntlich auch Schatten, und so hat auch Webstart im Vergleich mit webbasierten Applikationen gewisse Nachteile, die das Konzept mit sich bringt. Da wäre z. B. die Tatsache, dass die gesamte Applikation beim ersten Start auf den Arbeitsplatz heruntergeladen werden muss, was gerade bei langsamen Wählverbindungen nicht immer von Vorteil ist.

Auch der automatische Updatemechanismus, der sich nur implizit über das <offline>-Tag in der jnlp-Datei beeinflussen lässt, kann dann unter Umständen zu ärgerlichen Wartezeiten und Vollauslastung der spärlichen Bandbreite führen. Hier spürt der Anwender den Unterschied zu einem vergleichbaren Servlet ganz erheblich.

Schöne neue Welt?

Insgesamt präsentiert SUN mit Webstart eine große Erleichterung was die Installation und Verteilung von Client Applikationen unter Java betrifft. Gerade das sonst übliche Konzept eines Applet-Webbrowser-Gespanns, um dem Benutzer einen möglichst einfachen Start einer lokalen Applikation zu ermöglichen, dürfte mit steigender Verbreitung von Webstart immer mehr der Vergangenheit angehören. Dafür spricht sicherlich die recht gute und aus Entwicklersicht - dank JNLP-API - einfach zu realisierende Integration in das Betriebssystem.

Ob Provider von webbasierten Diensten jetzt allerdings, wie von SUN angestrebt, ihre gewohnten Oberflächen austauschen und durch Webstart Applikationen ersetzen werden, bleibt doch mehr als fraglich. Die Tatsache, dass diese Oberflächen zur Interaktion mit dem Benutzer HTML-Code anstatt grafischer Elemente verwenden, macht diesen Schritt unwahrscheinlich. Auch sind viele dieser Applikationen nicht in Java geschrieben, sondern meist in einer Skriptsprache wie Perl, Python oder PHP. Die Migration solcher Programme wäre natürlich sehr aufwendig.

Fazit

Webstart stellt eine tolle Möglichkeit dar, um bereits vorhandene Applikationen ohne viel Aufwand im Netzwerk zu verteilen und mit geringen Benutzerkenntnissen zu installieren. Die Ablösung von Applets durch Webstart-Programme ist sehr wahrscheinlich, wenn diese lediglich als solche realisiert wurden, um eine einfache Startmöglichkeit für den Benutzer zur Verfügung zu stellen. Eine Ablösung der webbasierten Dienste ist jedoch auf Grund des Aufwands, den eine Portierung bedeutet, nicht zu erwarten.

Positiv dürfte sich Webstart aber auch in der Anzahl der für den Desktop zur Verfügung gestellten Java Software bemerkbar machen. Während Java Applikationen auf Grund ihres komplizierten Starts bisher als Client bzw. Frontend eher eine Seltenheit darstellen, wird Java dank Webstart in dieser Disziplin sicherlich Boden gut machen.

Und bevor nun jemand die Frage nach der Performance von Java stellt - 2 GHz Prozessoren, die sich in Desktop Clients schnell langweilen, haben sicherlich auch nichts dagegen, mal von einer Java VM gefordert zu werden, oder?

Michael Hess (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen