|
5.3.1 Java und das WWW
Java animiert WEB Seiten und ermöglicht interaktive und spezialisierte Anwendungen. Hypertext als Basis für die Informationsorganisation bietet ein Vehikel für die Auswahl der Information. Das Common Gateway Interface (CGI) stellt eine Schnittstelle zwischen Web-Seiten im Client-Browser und dem WWW-Server dar. Java hingegen gibt erstmals die Möglichkeit Animation sowie komplexe Benutzerinteraktion in Echtzeit auf WWW-Seiten darzustellen. Durch Java wird die klassische W3-Hypertext-Seite nicht nur dynamischer als mit Hilfe des CGI; Benutzer, die im WWW auf Java-Programme stoßen, können an vielfältiger Interaktion und Animation teilnehmen, die ausschließlich durch die Phantasie des Java-Entwicklers begrenzt wird.
Ausführbare Elemente in W3-Seiten
Lokale Echtzeitinteraktion und -animation im Client-Browser wird durch ausführbare Inhalte ermöglicht, mit denen der WWW-Designer seine Seiten anreichert. Diese ausführbaren Elemente werden mit HTML-Tags in die Web-Seiten eingewoben. Allerdings kann nicht jeder beliebige Browser diese ausführbaren Inhalte anzeigen. Der Browser Hot Java von Sun Microsystems war der erste Browser, der die Java-Features nutzen konnte. Heute ist auch in Netscape 2.0 die virtuelle Java-Engine integriert. Dabei spielt es keine Rolle, auf welcher Plattform der Java-kompatible Browser läuft.
5.3.2 Java-Applets in WWW-Seiten
Die ausführbaren Elemente in WWW-Seiten werden Applets genannt und mit dem -Tag in die Hypertext Markup Language eingebunden. Ist der Client-Browser Java-kompatibel wird das Applet auf dem Client-Browser problemlos dargestellt.
Applets können auch ohne Kenntnisse der Programmiersprache Java in eigene Dokumente eingebunden werden. Applets verfügen über eine wohldefinierte Schnittstelle, die über den -Tag in HTML angesprochen werden kann. Der -Tag hat den in beschriebenen Grundaufbau. Um ein Applet in eigene HTML-Seiten einbinden zu können, müssen also
. Standort (HTML-Adresse und Verzeichnis z.B. https://www.xyz.de/java/class)
. Name (Name des Applets in ByteCode, also mit Suffix "class")
. Parametereigenschaften
des gewünschten Applets bekannt sein.
1.
2.
10.
11.
12.
13. .
14. .
15. .
16.
17. Sie benötigen einen Javakompatiblen Browser!
18.
Abbildung : Grundaufbau des -Tags. Notwendige Attribute sind unterstrichen.
Auf den SRC-Parameter kann vollständig verzichtet werden, wenn sich das Applet im aktuellen Verzeichnis befindet. Dieser Parameter ermöglicht auch das benutzen von Applets, die sich auf irgendeinem WWW-Server befinden (siehe ). In diesem Fall muß dort die jeweilige HTTP-Adresse inclusive Pfad eingegeben werden. Der code-Parameter bestimmt den Namen des Applets. Zeile 9 enthält einen alternativen Inhalt, der nur von Browsern angezeigt wird, die Java-Applets nicht unterstützen.
Abbildung : Applets in HTML-Seiten
WWW-Seiten mit Java-Applets entstehen in folgenden Schritten:
. Entwickler erstellen Java-Sourcecode auf ihren Rechnern
. Der Quellcode wird mit dem Java-Compiler kompiliert
. Als Ergebnis erhält man das plattformunabhänige Applet in ByteCode
. Erstellen einer HTML-Seite mit Tag und einem Mindestmaß an Parametern
. Ausführen der Seite mit Java-kompatiblem Browser oder mit dem im JDK enthaltenen appletviewer
5.3.3 Operationen beim Abruf einer WWW-Seite mit Applets
Im folgenden wird der Ablauf von der Anforderung bis zur Darstellung einer HTML-Seite mit Applet beschrieben.
Abbildung : Ablauf von Anforderung bis Darstellung von HTML-Seiten mit Applet
1. Der Benutzer sendet eine Anfrage für ein HTML-Dokument an den Server
2. Das HTML-Dokument wird an den Browser des Benutzers geschickt. Durch die -Tags wird ein Applet identifiziert.
3. Der Bytecode des Applets wird an den Client übertragen.
4. Der Java-kompatible Client-Browser interpretiert die Bytecodes und zeigt die HTML-Seite mit Applets an
5. Der Benutzer kann unabhängig vom Web-Server mit dem Applet interagieren. Der Bytecode enthält alle dafür notwendigen Informationen. Dabei werden nur Ressourcen des Client-Rechners beansprucht, es sei denn, eine Interaktion mit dem Web-Server würde stattfinden.
5.3.4 Gartner-Group Modell
Teilhaber-Betrieb Distributed Presentation Remote Presentation Distributed Processing Remote Database Distributed Database File Server
SERVER SERVER SERVER SERVER SERVER SERVER SERVER
Data Mgmt. Data Mgmt. Data Mgmt. Data Mgmt. Data Mgmt. Data Mgmt.
Fachlogik Fachlogik Fachlogik Fachlogik
Dialog & Presentation Dialog & Presentation
Internet Internet Internet Internet Internet Internet Internet
Data Mgmt. Data Mgmt.
Fachlogik Fachlogik Fachlogik Fachlogik
Presentation (phys.) Dialog & Presentation Dialog & Presentation Dialog & Presentation Dialog & Presentation Dialog & Presentation
CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT
Java Applets X X X X X
CGI X
RPC X
X11 X
Abbildung : Applets und CGI (sowie RPC und X11) im Modell der Gartner Group
Java-Applets haben im Vergleich zu CGI-Skripts folgende Vorteile:
. nur notwendige Fachlogik auf Server -> geringer Serverbelastung
. Daten werden da gelagert, wo sie wirklich gebraucht werden
. Nutzung von Client-Ressourcen
. weniger Netzwerkbelastung
5.3.5 Animation und Interaktion mit Java-Applets
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.
5.3.6 Sicherheitsaspekte
Dadurch, daß fremder Code (in Form von Applets) über das Internet auf den lokalen Rechner geladen und ausgeführt wird, wurde der Ruf nach Sicherheitsmaßnahmen laut. Wer möchte schon, daß ein Applet die Daten der lokalen Festplatte unbemerkt einem unbekannten Dritten zuspielt, oder daß ein Applet gar die Festplatte formatiert?
Für diesen Zweck wurden daher Maßnahmen getroffen, die die unbemerkte Informationsübermittlung und die Schädigung des lokalen Computers unmöglich machen sollen.
Diese Sicherheit wird dadurch erreicht, daß Java-Quellcodes zuerst in Byte-Code-Anweisungen kompiliert werden, die in dieser Form verifiziert werden können. Die Java-Anweisungen im Byte-Code ähneln anderen Befehlssätzen von Computerchips, jedoch sind sie nicht für ein bestimmtes Computersystem spezifisch und können somit auf eventuelle Schutzverletzungen geprüft werden (siehe Abbildung 14).
Abbildung : Der Verifizierungsprozeß für den Byte-Code bei Java.
Anders als bei herkömmlichen Programmiersprachen erfolgt der Zugriff auf Methoden und Variablen stets über ihren Namen. So läßt sich leicht verifizieren, welche Methoden tatsächlich benutzt werden. Dies ist auch notwendig, damit ein unbefugtes Herumbasteln an den Byte-Codes ausgeschlossen werden kann.
Nachdem die Applets verifiziert wurden, können sie in einer beschränkten Umgebung ablaufen. In dieser Umgebung können bestimmte gefährliche Funktionen von Applets nur ausgeführt werden, wenn ihnen das ausdrücklich gestattet wird. Aufgrund der Verifizierung ist ein Ausbrechen aus dieser Umgebung nicht möglich.
Weiterhin gilt für verifizierte Applets:
. es ist kein Operandenstack-Overflow möglich
. alle Operationen werden auf Operanden mit korrektem Typ angewendet
. es existieren keine unzulässigen Typkonvertierungen
. die Zugriffsrechte auf Felder (public, private, protected) werden eingehalten
Die Gestaltung der Zugriffsmöglichkeiten für externe Applets lassen sich in den Java-fähigen Web-Browsern einstellen. Dabei kann es folgende Möglichkeiten geben (dies variiert zwischen den Browsern):
. None: Die Applets haben keinen Zugriff auf das Netzwerk. Dies ist der beste Schutz, jedoch sind in diesem Modus nicht alle Applets ablauffähig.
. Applet Host: Hier haben die Applets nur Zugriff auf den Host, von dem sie stammen. Diese Applets können daher nicht auf die Informationen auf ihren Computern zugreifen. Dies ist auch die Standardeinstellung in der die meisten Applets ablauffähig sind.
. Firewall: Applets außerhalb der Firewall können nur auf Hosts, die ebenfalls außerhalb der Firewall sind, zugreifen. Dieser Modus ist natürlich nur möglich, wenn auch eine Firewall eingerichtet wurde.
. Unrestricted: Hier können Applets zu allen Hosts im Internet Verbindungen herstellen. Dieser Modus sollte allerdings nur benutzt werden, wenn keine Sicherheitsbedenken bezüglich des Applets vorhanden sind.
Lokal gestartete Applets (dies sind Applets im CLASSPATH!!) können natürlich auf den lokalen Rechner zugreifen. Für externe Applets kann zusätzlich der Zugriff auf die lokale Klassenbibliothek eingeschränkt werden. Dadurch wird ein Überschreiben dieser als sicher akzeptierten Klassen unterbunden.
Anzumerken bleibt, daß die Sicherheit von Java und speziell von Java-Applets durch Einsatz kryptografischer Verfahren (Public-Key-System) bei der Übertragung von Klassen und durch die eindeutige Identifizierung des Herstellers noch erhöht werden könnte.
|
