Neue Technologien wie ADSL oder Kabelmodem sollen vor allem eines bringen: mehr Datenverkehr im Internet. Jedoch sind die schnellen Leitungen dem Otto-Normal-Surfer oft zu teuer und in vielen Städten gar nicht verfügbar. Zudem liegt der Flaschenhals häufig auf der anderen Seite der Leitung. Denn oftmals schaufeln die Webserver die Daten bei hohen Nutzungsraten viel zu langsam zum User und verursachen dadurch lange Wartezeiten. Kurzum, der Ausbau der Bandbreiten hinkt dem Bedarf hinterher. Neben der Hardware spielt aber die Software eine tragende Rolle. Java hat sich im Internet zu einem nicht besonders schnellen Allrounder entwickelt.
Java auf dem Vormarsch
Alle gängigen Webbrowser verfügen über eine Java Virtual Machine (JVM), mit der sie Java-Applets ausführen können. Und da diese Interpreter in fast jedem Betriebssystem eingebettet sind, laufen Java-Applikationen unabhängig von der eingesetzten Hardware. Beispielsweise setzen fast alle Online-Banken Java ein - insbesondere aufgrund der Plattform-Unabhängigkeit und der zahlreichen Gestaltungsmöglichkeiten und um Interaktivität sowie Anwenderkomfort zu steigern. Ebenso favorisiert eine stetig wachsende Zahl von Unternehmen Java für Application-Service-Providing (ASP), für Online-Schulungen im Business-toBusiness- (B2B) und Business-to-Consumer-Bereich (B2C).
Auch Betreiber von Corporate Networks bevorzugen zunehmend Suns universelle Programmiersprache. Überall, wo Software in einem Netzwerk einfach, schnell und aktuell einer Vielzahl von Nutzern zur Verfügung gestellt werden muss, sammelt Java Plus-punkte: Office-Anwendungen lassen sich auf Netzwerkrechnern allen Mitarbeitern zur Verfügung stellen und zentral warten. Der Außendienstler nutzt somit dieselbe Programmversion wie sein Kollege im Innendienst.
Die Zukunft von Java liegt darüber hinaus im Bereich der mobilen Endgeräte. Über kurz oder lang werden Java-fähige Handhelds, Palmtops und Handys den klobigen PC als Surfplattform ablösen.
Alle die genannten Vorteile haben aber ihren Preis: Je mehr Funktionalität in die Anwendungen gepackt wird, umso komplexer fallen sie aus und desto länger werden die Ladezeiten. Doch gerade bei E-Commerce-Anwendungen, etwa bei Internet-Banking, sind die Ansprüche der Kunden hoch: Auch online verlangen sie gleiche Beratung und gleichen Service wie beim persönlichen Besuch. Eine schnelle Bearbeitung respektive Ladezeit wird als selbstverständlich vorausgesetzt.
Genau da liegt der Haken: Wie das amerikanische Marktforschungsinstitut Zona Research in seiner Studie "The Need for Speed" herausgefunden hat, wartet ein durchschnittlicher User nicht länger als acht Sekunden, bis sich eine Website aufbaut. Bleibt der Screen zu lange leer, klickt er zur Konkurrenz. Das Problem heißt also nicht unzufriedene, sondern verlorene Kunden. Das gleiche gilt für eigene Mitarbeiter. Sollen sie auf Applikationen über ein Corporate Network zugreifen, müssen diese schnell bereitstehen - sonst sinkt die Motivation und damit die Produktivität.
Wer Java-Lösungen für Kunden realisiert, steht somit vor einer großen Herausforderung: Bestehende Java-Anwendungen sollten schneller laufen und die Ladezeiten neuer Applikationen entsprechend optimiert und dadurch kürzer ausfallen.
Klassische Kompressionsverfahren
Kompression macht Sinn, wenn Redundanzen im Datenmaterial vorliegen. Bekannte Werkzeuge wie "Jar" oder "MS-Cabarc" komprimieren die Klassendateien eines Java-Applets zu einem Archiv. Allerdings kann der Browser immer nur ein Archiv pro Java-Anwendung laden. Sind weitere Java-Klassen nötig, so lassen sich diese nur unkomprimiert abrufen. Denn ein Nachladen weiterer Archive ist wegen des so genannten "Sandbox"-Prinzips in der Java Virtual Machine nicht möglich.
MS-Cabarc und Jar verwenden das lexikalische Kompressionsverfahren von Lempel-Ziv-Welch (LZW), das Redundanzen, also Wiederholungen, in Zeichenketten eliminiert. Programmiersprachen wie Java enthalten jedoch auch innerhalb ihrer grammatikalischen Struktur Redundanzen, die mit lexikalischen Kompressionsverfahren nicht erfasst werden.
Hier setzt die syntaxorientierte Codierung (SoC) an. Dieser Algorithmus verdichtet Java-Programme zwei- bis dreimal besser als die LZW-Kompression. Damit lassen sich Java-Klassen auf 20 Prozent ihrer ursprünglichen Größe eindampfen (siehe Grafik). Bisher wurde die Basistechnologie SoC in der Client/Server-Lösung "Jaccelerator" implementiert - in einem Java-Beschleuniger.
Im konventionellen Verfahren wird der Java-Quellcode zum Bytecode kompiliert, eventuell mit Jar oder MS-Cabarc komprimiert und anschließend dem HTTP-Server zum Abruf bereitgestellt.
Bei der syntaxorientierten Codierung erzeugt die Server-Software aus Java-Quellcode direkt ein hochkomprimiertes SoC-Archiv. Der Client auf Nutzerseite lädt dieses Archiv komplett herunter, dekomprimiert es und erzeugt mit einem eigenen Byte-Code-Generator Java-Klassen in Echtzeit. Diese führt die Java Virtual Machine dann direkt und ohne Zeitverlust aus.
Java-Anwendungen laden so wesentlich schneller, da das SoC-komprimierte Archiv fünfmal kleiner ausfällt als das unkomprimierte Applet. Spürbar wird dieser Effekt bei unkomprimierten Applets ab einer Größe von 30 KB.
Im Gegensatz zur üblichen Übertragung braucht also der Webserver keinen Bytecode mehr zu erzeugen. Diese Aufgabe übernimmt der Client, wenn er beim ersten Aufruf einer SoC-komprimierten Java-Anwendung ein so genanntes Signed Applet empfängt. Dieses lässt sich mit wenigen Mausklicks im Browser installieren - das Einverständnis des Users natürlich vorausgesetzt. Zur Zeit ist SoC die Ultima Ratio der informationsverlustfreien Kompression syntaktisch strukturierter Daten. Ihren Erfindern hat der Algorithmus sogar den diesjährigen Philip-Morris-Forschungspreis beschert.
Highspeed mit Modularisierung
Weitere Beschleunigung von Java-Anwendungen ist schwer möglich. Allerdings lässt sich die syntaxorientierte Codierung zusätzlich mit einem Modularisierungsverfahren kombinieren. Dieses ermöglicht, große Java-Applets bedarfsgerecht in kleine, SoC-komprimierte Module aufzuteilen. Die Modularisierung macht sich den Umstand zunutze, dass kein User alle Funktionen einer Anwendung gleichzeitig benutzt. Deshalb kann man die Applets in Pakete von Klassen mit unterschiedlicher Priorität gliedern.
Im ersten Paket befinden sich die Klassen, die zum Start des Applets nötig sind, zum Beispiel das Startmenü eines Banking-Applets. Im zweiten Paket liegen die Klassen für die vom Nutzer am häufigsten benötigten Funktionen, im Fall der Banking-Anwendung etwa Umsatzanzeige, Wertpapierdepot und Ähnliches. Danach folgen die selten genutzten Module wie Dauerauftrag oder Lastschrift.
Demnach liegt auf dem Server kein komplettes, komprimiertes Java-Applet mehr, sondern dort gibt es mehrere SoC-Module. Diese lassen sich mit derselben Client-Software abrufen, entpacken und ausführen wie die ausschließlich mit SoC komprimierten Applets. Während also der Nutzer bereits mit dem Startmenü arbeitet, lädt der Java-Beschleuniger im Hintergrund weitere Module nach. Gemeinsam reduzieren SoC und Modularisierung die Wartezeit des Benutzers um bis zu 97 Prozent.
Die syntaxorientierte Codierung zusammen mit der Modularisierung reizen das mathematisch Mögliche fast vollständig aus und legen somit den Grundstein für eine neue Generation interaktiver und komplexer Anwendungen. Dabei ist die Technologie nicht nur auf den Einsatz mit Java beschränkt, sondern auf alle syntaktisch strukturierten Daten übertragbar. Darunter fallen Postscript-Dateien, Mpeg-4-codierte Videodaten, VRML, XML und höhere Kommunikationsprotokolle.
www.syntion.de
*Markus Batscheider ist Unternehmenssprecher der Münchener Syntion AG.
GLOSSAR
Java-Beschleunigung auf einen Blick
LZW: Lempel-Ziv-Welch, von Jacob Ziv and Abraham Lempel entwickelte Kompressionsmethode. LZW ist ein lexikalisches Verfahren, das die Redundanzen, also Wiederholungen, in Zeichenketten eliminiert. Es wurde von Terry Welch verbessert, sein Arbeitgeber Unisys hält ein Patent auf diesen Algorithmus. LZW findet Gebrauch bei Datenübertragungen über Modems sowie bei der Datenkomprimierung zu Gif-, Tif- und Postscript-Formaten.
SoC: syntaxorientierte Codierung; findet die mit LZW nicht erfassbaren Redundanzen. SoC lässt sich überall dort einsetzen, wo Programme oder durch formale Sprachen beschriebene Texte gespeichert und übertragen werden. Dabei bezieht SoC die syntaktischen Regeln ein, nach denen Computerprogramme erstellt werden, um Rendundanzen nahezu vollständig zu eliminieren. Dadurch lässt sich die Datenmenge, die zur Darstellung eines Java-Applets benötigt wird, erheblich reduzieren. SoC wurde 1996 an der Universität der Bundeswehr München von Rolf Matzner entwickelt.
JVM: Java Virtual Machine, ein Java-Interpreter. Eine am Client installierte und meist im Webbrowser integrierte Software, die den plattformunabhängigen Java-Bytecode in den rechnerspezifischen und ausführbaren Binärcode umwandelt.
Parser: ein Programm, das natürliche und formale Sprachen grammatikalisch zerlegen ("parsen") kann.