Applets sind schön. Nun, zumindest theoretisch. Die Realität ist meist ernüchternd: schlecht oder gar nicht dokumentierte SecurityExceptions, Eigenheiten der Browser, umständliche Konfiguration und starke Einschränkungen beim Memory Management. Dennoch sind Applets derzeit extrem populär. Viele Anwendungen gehen weg von Fat-Clients hin zu Portal-Lösungen. Hier werden jedoch auch weiterhin teilweise Applets für diverse Tätigkeiten benötigt. Ein Beispiel hierfür ist der Einsatz der jadice document platform zur Anzeige von Dokumenten. Es gibt jedoch eine Alternative zu Java Webstart und den Java Applets, welche im Folgenden beschrieben werden soll. Das folgende Beispiel ist stark vereinfacht und enthält keine Verarbeitung von Fehlern. Ziel war es, das Prinzip möglichst einfach darzustellen. Auch die benötigte Konfiguration der Registry ist auf ein Minimum reduziert und man sollte auch den Empfehlungen von Microsoft Beachtung schenken (Integrieren der optionalen Angaben, etc.)
Windows bietet die Möglichkeit, eigene URL Handler für Protokolle zu definieren. Dies wird unter http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx sehr gut beschrieben. Benötigt werden zwei Dinge: Ein Eintrag in der Windows Registry und eine Anwendung, die eine entsprechende Anfrage behandeln soll. Möchte man ein JadicePanel für die Anzeige von Dokumenten nutzen, kann beispielsweise das Protokoll „jadvwr" definiert werden. Wird eine URL mit dem Protokoll Prefix jadvwr: angefordert, wird die Anfrage an die dafür registrierte Anwendung weitergereicht. Für die Konfiguration kann ein Registry Eintrag ähnlich dem folgenden verwendet werden:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\jadvwr]
@="URL:Jadice Viewing Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\jadvwr\shell]
[HKEY_CLASSES_ROOT\jadvwr\shell\open]
[HKEY_CLASSES_ROOT\jadvwr\shell\open\command]
@="\"E:\\IEUrlHandler\\view.bat\" \"%1\""
Hierbei wird angenommen, dass das Batch-Script E:\IEUrlHandler\viwer.bat existiert. Dieses könnte in etwa wie folgt aussehen:
set WD=%~dp0
java -cp %WD%jadice-documentplatform-4.1.0.9-all.jar;%WD%bin/ Startup %1
set WD=
Dieses Script leitet den Aufruf lediglich an eine Java Applikation weiter. Hierbei ist die Zielapplikation ein Wrapper um das JadicePanel, welcher die angeforderte URL nimmt und die Daten mittels Java API auf den Client zieht und zur Anzeige bringt:
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
public class Startup {
public static void main(String[] args) throws Throwable {
// url prefix jadvwr: entfernen
String url = args[0].substring(7);
InputStream is = new URL(url).openStream();
File f = File.createTempFile("jad-url-handler", "tmpdoc");
writeToFile(is, f);
String openTarget = "-open=" + f.getAbsolutePath();
JadicePanel.main(new String[]{openTarget});
}
private static void writeToFile(InputStream is, File f)
throws IOException {
FileOutputStream out = new FileOutputStream(f);
byte[] buf = new byte[2048];
int read;
while ((read = is.read(buf)) > -1) {
out.write(buf, 0, read);
}
out.flush();
out.close();
}
}
Der hier gewählte Weg eines Wrappers um die Klasse JadicePanel ist lediglich ein Beispiel, um die Logik möglichst einfach darzustellen. Entscheidend sind bei diesem Vorgehen zwei Dinge: Der erste Parameter, welcher der Anwendung übergeben wird, ist die URL, die angefordert wurde. Diese enthält noch das Protokoll jadvwr:, welches für die weitere Verarbeitung entfernt wird.
Die zweite wichtige Eigenschaft (oder vielmehr Annahme) ist, dass der Rest der URL in einer Art und Weise zur Verfügung steht, die die Java API verarbeiten kann. Es wird über URL.openStream() ein InputStream zum Dokument erfragt und die Daten daraus in eine temporäre Datei geschrieben.
Die temporäre Datei wird dann als Parameter an JadicePanel.main(String[]) weitergereicht.
Mit diesem einfachen Beispiel ist es möglich in Webanwendungen URLs, ähnlich der folgenden, zu integrieren:
jadvwr:http://host.company.com/documentstore/some-document.pdf
Der Vorteil dieser Methode ist, dass der Umgang mit der JavaVM und auch der Umgang mit Browser-Eigenheiten deutlich gemindert wird. Nachteilig ist wiederum die Notwendigkeit eine Anwendung auf alle Arbeitsstationen auszurollen.
