|
Java Applets lassen sich grob nach dem Informationsfluß strukturieren. Untersucht man die Informationsflüße diverser Applets, lassen sich drei Typen bilden.
Abbildung : Lokale Präsentation ohne Interaktion
beschreibt den einfachsten Applettyp. Dabei findet ein Informationsfluß vom Server zum Client statt, sowie vom Client zum Benutzer. Ein Beispiel für diese Art von Applet ist das Trembling-Duke Applet sowie alle anderen "Daumenkino"-Applets. Der Bytecode wird lokal ausgeführt, der Benutzer interagiert aber nicht mit dem Applet und es findet kein Infomationsfluß zwischen Client-Browser und Server statt.
Abbildung : Lokale Präsentation und Benutzer-Client Interaktion
Bei dem in dargestellten Applettyp findet nicht nur ein Informationsfluß vom Server zum Client und zum Benutzer statt; der Benutzer hat hier die Möglichkeit mit dem Applet auf dem Client zu Interagieren. Beispielhaft für diesen Typ von Applet ist irgendein Spreadsheet-Applet mit integrierter Fachlogik: Irgendeine Bank bietet ein Spreadsheet in Form eines Applets zur Ratentilgung an. Der Benutzer kann seine persönlichen Daten eingeben und diverse Berechnungen durchführen. Es findet also eine Interaktion zwischen dem Applet und dem Benutzer statt, nicht aber zwischen den Client Browser und dem WWW-Server.
Abbildung : Lokale Präsentation und Server-Client-Benutzer-Interaktion
zeigt einen Applettyp, bei dem Interaktion zwischen allen beteiligten Parteien stattfindet. Beispiel: Eine Versicherung erstellt ein Applet mit dem eine KFZ-Versicherung abgeschlossen werden kann. Das Applet wird bei Anforderung der WWW-Seite auf den Client geladen. Der Benutzer interagiert mit dem Applet indem er seine persönlichen Daten eingibt. Nach einer Plausibilitätsprüfung auf dem Client werden die Benutzerinformationen zum Server geschickt.
Animation mit Applets
Die wohl einfachste Form von Applets sind Animationen. Hier findet keine Interaktion mit dem Benutzer statt. Vielmehr dienen diese Animationen entweder der grafischen Auflockerung von Web-Seiten oder zum Abspielen von Informationssequenzen (z.B. Scrollines, Börsenticker, Filme, Sounds). Ein evidenter Vorteil von Applets hier: bis dato mussten Viewer/Player für Dateien mit Informationssequenzen getrennt vom Browser auf dem Client-System mitgeführt werden (JPEG-Viewer für JPG's, WAV-Player für WAV's). Jetzt können mit Hilfe von Applets Informationssequenzen vom Benutzer genutzt werden, ohne sich über das Format der Dateien Sorgen machen zu müssen, da der Java-Bytecode einen Viewer/Player enthalten kann.
Hier zunächst ein Beispiel für ein einfaches Animationsapplet:
Hallo... Testwebseite
wie gehts ??
In diesem Beispiel werden die in gezeigten GIF-Dateien übereinanderkopiert. Durch die Trägheit den menschlichen Auges sehen wir ein bewegtes Bild.
Animierte Applets müssen aber nicht zwangsweise übereinanderkopierte Bitmaps sein; der Bytecode kann ja auch direkt auf die angezeigte Bitmap wirken und diese so animieren. Ein Beispiel hierfür ist das Feuerwerk-Applet oder das Clock-Applet (https://java.sun.com).
Interessant ist das LED Sign Applet (https://java.sun.com).. Neben bloßer Parameter bietet es eine Makrosprache zur Anzeige einer Laufschrift an.
Wichtig für den Business-Bereich könnten die Börsenticker werden: Ein Applet ist für die grafische Darstellung von Charts (z.B. Aktienkurse) auf dem Client-Browser zuständig. Diesem Chart-Applet müssen dann nur reine Nutzdaten aus dem Netz übergeben werden, die vom Chart-Applet auf dem Client angezeigt werden.
Interaktion mit Java-Applets
Mit Hilfe der CGI-Programmierung kann der Web-Entwickler in eine Anwendung ein gewisses Maß an Interaktivität einbauen und somit dem Benutzer eine Möglichkeit an die Hand geben, auf Anfrage exakt auf seine Bedürfnisse zugeschnittene Informationen zu erhalten. CGI-Programme können einem Benutzer auch gestatten, eine Informationsstruktur zu ändern oder ihr etwas hinzuzufügen. Wegen seines ausführbaren Inhaltes ist mit Java ein noch höherer Grad an Interaktivität möglich.
Bei der CGI-Programmierung werden die Ressourcen des Client-Rechners nicht genutzt. An jedem Interaktionspunkt findet ein Zugriff auf den Server statt, da bei CGI keine Fachlogik mit der HTML-Seite heruntergeladen wird. So wird das Netz und der WWW-Server oft unnötig belastet und die Antwortzeit sinnlos in die Höhe getrieben. Verwendet man Java-Applets, kann ein Teil der Fachlogik auf den Client gelegt werden, so daß nur in notwendigen Fällen ein Server-Zugriff stattfindet.
Bei Applets mit reiner Benutzer-Client Interaktion können Serverzugriffe vollkommen verhindert werden. Beispielhaft soll dies anhand des Spreadsheet-Applets ( und ) verdeutlicht werden.
Abbildung : Client-Ressourcen werden genutzt, unnötiger Serverzugriff verhindert
Stock Positions
My Portfolio
Abbildung : HTML-Code zu Spreadsheet-Beispiel
Beim Spreadsheetbeispiel wurde die gesamte Fachlogik in das Applet verlagert. Manchmal ist eine Interaktion zwischen Server und Client-Browser (wie im KFZ-Versicherungsbeispiel aus Kapitel 5.4) notwendig um Nutzdaten zu übertragen oder Transaktionen durchzuführen. An dieser Stelle kann das Börsentickerbeispiel weitergesponnen werden: Einem Aktienanalysten werden nicht nur die aktuellsten Kursdaten übertragen, man könnte Ihm ein zusätzliches Feature bieten, das Ihm Transaktionen, z.B. den Kauf und Verkauf von Aktien, ermöglicht.
Außerdem können durch Java-Applets nicht nur weltumspannende Multiusergames realisiert werden. Die gesamte Groupware eines Unternehmens kann basierend auf Java einheitlich umgesetzt werden.
In Anbetracht der von Oracle, Sun und anderen Firmen geplanten diskless Settopboxen kann angenommen werden, daß in naher Zukunft sogar Applikationen "gemietet" werden. Wieso soll man sich eine teure Textverarbeitung mit Tausenden ungenutzten Features kaufen, wenn man sich im Internet diese mit "Rent-an-Application" auf Zeit mieten kann.
|
