[_HOME_] ... [Übergeordnete Seite] ... [Vorherige Seite] ... [Nächste Seite]
Plattformunabhängigkeit
Da der Server auf Java basiert, kann er auf mehr Plattformen eingesetzt werden, als jeder andere Webserver.
Anmerkungen
Jedoch gibt es zu dieser Aussage auch kritische Anmerkungen. So schreibt bespielsweise Davin Strom (http://www.strom.com/pubwork/javaweb.html), daß dies mitunter auch nicht der Fall sein kann. Er testete im Juli 1997 die Version 1.0 des Java Web Servers: Ohne Probleme läuft der Java Web Server auf Windows NT, Windows 95 und Solaris - mit einigen Anstrengungen auch unter einer Vielzahl von Unix-Varianten. Allerdings wird bei den Unix-Varianten ein hohes Maß an Expertenwissen verlangt, um die erforderlichen Shell-Scripte so anzupassen, daß der Server auch als Root-Server laufen kann.
Servlet API
Servlets sind Protokoll und Plattform unabhängige Komponenten eines Servers, geschrieben in Java. Grundsätzlich sind Servlets gedacht, CGI-Scripte zu ersetzten. Servlets haben gegenüber CGI-Scripten den Vorteil, flexibler und stabiler ablaufen zu können. Zudem ist die Portierung von Servlets auf andere Plattformen ohne Probleme möglich. Durch den Einsatz von Servlets ist es möglich, die Funktionalität des Webserver, dynamisch während der Laufzeit (!) zu erweitern.
Darüberhinaus sind weitere Einsatzgebiete von Servlets: Datenbankanbindung, Netzwerkadministration, Statistische Auswertung über den Besuch von Websites, Filtern von Daten (Proxy-Servlets).
Durch den Einsatz von Servlets kann z.B. eine moderne, 3-schichtige IT-Struktur erreicht werden. Wobei in der ersten Schicht ein Java fähiger Webbrowser, der auf einem schlanken Client (z.B. Netzcomputer) ablaufen kann, über Servlets (2. Schicht), welche die Ablauflogik (Busininess Rules) steuern, auf Datenbankinformationen (3. Schicht) zugreifen kann.
Anmerkungen
Es sei aber angemerkt, daß auch nicht Java basierte Webserver das Servlet-Konzept unterstützen können.
Page Compilation
Durch dieses Merkmal ist es möglich, Source-Code - den der Server ausführen soll - in HTML-Dateien einzubetten. Dadurch können Inhalte der Web-Pages auf einfache Weise durch den Client dynamisch angepasst werden. Eine Compilation des Source-Codes findet automatisch durch den Server statt, sofern es Änderungen im Source Code gegeben hat. Derjenige der Source-Code in seine Seiten mit aufnimmt, braucht sich über das Compilieren keine Gedanken mehr zu machen. Page Compilation verspricht das Schreiben von Servlets einfacher als bisher zu gestalten.
Anmerkungen
Dieses Merkmal ist im weiteren Sinne vergleichbar mit Scriptsprachen wie z.B. Javascript. Jedoch ist hier der Unterschied, das bei der Page Compilation die notwendigen Berechnungen auf dem Server ablaufen und nicht auf dem Client.
Session Tracking
Der Server kann Informationen über den Zustand von Webseitenbesuchen eines Clients speichern und verwalten, um diese Informationen bei einem späteren Besuch für weitere Aktionen weiterverwenden zu können. Durch dieses Merkmal soll die kommerzielle Seite des Internets, z.B. Online-Shopping oder auch User-Profile, vereinfacht und gefördert werden.
Anmerkungen
Im Grunde stellt dies eine neue Form der "Cookies" dar, jedoch werden weitaus mehr Möglichkeiten zur Verfügung gestellt. Das "Session Tracking" ist durch Servlets implementiert und dürfte daher auch von anderen Servern, die das Servlet API unterstützen, verwendet werden können.
Unter einer Session ist eine Serie von Abfragen von jeweils dem selben Client zu verstehen. Für diesen Zweck wird ein sogenanntes Sessionobjekt angelegt, wenn der Client das erste Mal eine Webseite aufruft. Das Sessionobjekt wird dem Client eindeutig zugeordnet. Die Lebensdauer eines Sessionobjektes wird jeweils bei einer neuen Anfrage des Clients verlängert. Finden keine weiteren Anfragen des Clients statt, wird das Sessionobjekt nach einer konfigurierbaren Zeitspanne vernichtet.
Während des Besuches des Clients kann das Sessionobjekt verschiedene, frei definierbare Informationen (Attribute) sammeln, die für eine spätere Auswertung verwendet werden können. Diese Auswertungen können also mehr Informationen geben, als das einfache Zählen von "Seiten-Hits".
Die Identifizierung bzw. Zuordnung eines Users zu einem Sessionobjekt kann auf zwei Arten erfolgen:
Im 2. Fall wird bei jedem Aufruf einer URL, die Session-ID an den Server mit
übermittelt. Besitzt die Webseite z.B. den Verweis
<a href="/store/catalog">
wird dieser Verweis durch den "Session Tracker" umgeschrieben in
<a href="/store/catalog;$sessionid$XYZ123">
Die Sessionobjekte werden i.a. auf der Serverseite im Speicher gehalten. Dies könnte bei einem stark frequentierten Server natürlich zu Speicherplatzproblemen führen. Aus diesem Grunde ist es möglich, die Sessionobjekte zur serialisieren und auf dem Plattenspeicher auszulagern. Dabei wird eine Auslagerungsmethode Last Recently Uses (LRU) benutzt, die vergleichbar mit der virtuellen Speicherverwaltung eines Betriebssystems ist.
Administration über Applets
Durch den Einsatz von Applets wird der Server über ein GUI konfiguriert. Die Administration kann von jedem beliebigen Webbrowser aus gestartet werden. Dadurch wird eine zentrale Verwaltung verschiedener Webserver ermöglicht. Änderungen an der Serverkonfiguration können ohne eine Beendigung mit anschließendem Neustart des Servers durchgeführt werden. Dadurch wird ein hohes Maß an Interoperablität erreicht.
Anmerkungen
Das Starten der Applets dauert mitunter etwas länger. Allerdings konnten die Beobachtungen von David Strom (http: siehe oben) in der Version 1.1 nicht nachvollzogen werden. Er testete die Version 1.0 und schreibt, daß das erste Laden des Administrationsapplets auf der selben Maschine, auf der auch der Webserver lief, mehrere Minuten gedauert hätte.
Presentation Templates
Durch den Einsatz von sogenannten Templates wird eine Trennung von den Inhalten und dem Layout von Webseiten erreicht. Beide Bereiche lassen sich somit separat entwerfen und pflegen.
Anmerkungen
Das Prinzip von Templates findet man auch in der Form von Style-Sheets bzw. in ausgereifteren HTML-Editoren wieder.
Secure Socket Layer (SSL)
Der Webserver implementiert dieses Standard Protokoll für den Aufbau von sicheren Verbindungen.
Anmerkungen
Dieses Merkmal sollte für einen Webserver eigentlich selbstverständlich sein.
Secure Area Sandboxes, Digitale Signaturen
Das "Sandkasten"-Prinzip ist ein allgemeines Sicherheitsmerkmal von Java. Servlets können in isolierten Umgebungen ablaufen, und bestimmte Rechte (z.B. für den Dateizugriff) zugewiesen bekommen, ohne daß sich Servlets gegenseitig beeinflussen oder zerstören. Digitale Signaturen können benutzt werden, um Rechte von Servlets erweitern zu können, wenn man dem Hersteller des Servlets "vertraut". Dadurch ist auch ein Laden von Servlets mit erweitereten Rechten über das Netz möglich.
Anmerkungen:
Dieses "Sandkasten"-Prinzip wird auch für Applets verwendet.
Access Control Lists (ACLs)
Es ist möglich, Rechte für verschiedenen Benutzer- oder Benutzergruppen zu verwalten. Diese Rechte können den Zugriff auf Servlets, Webseiten oder andere Dateien regeln.
Proxy Support
Der Java Web Server kann auch als Proxy Server eingesetzt werden, der auch einen Cache zur Verfügung stellt.
Quelle: http://webcompare.internet.com/compare/javaweb.html
Administration
Der Server kann verschiedene Dokumentverzeichnisse für verschiedene IP-Nummern verwalten. (Virtuelles Hosting)
Logging
Protokollunterstützungen
Sicherheit
Das HTTP Protokoll stellt eine Reihe von Sicherheits-Merkmale zur Verfügung, die so gut wie jeder Webserver auf die eine oder andere Weise unterstützt:
"Basic Authentication". Der Benutzer gibt seinen Login-Namen sowie sein Passwort ein. Dabei wird das Passwort unverschlüsselt über das Netz gesendet. Die Probleme bei dieser Form von Authentifizierung liegen auf der Hand. Das Passwort zusammen mit dem Login-Namen kann von einem Dritten unbemerkt abgehört und benutzt werden.
"Digest Authentication". Das Passwort ist dem Server bekannt. Es wird aber nicht über das Netz gesendet. Der Server schickt an den Client einen willkürlich generierten Schlüssel. Mit diesem Schlüssel werden die Eingaben des Anwenders (Name, Password) lokal beim Anwender verschlüsselt und an den Server zurückgeschickt. Der Server entschlüsselt daraufhin die Antwort und vergleicht das Ergebnis mit den ihm vorliegenden Daten. Stimmen Username und Passwort nach der Entschlüsselung überein, wird der Zugang erteilt. Sicherheitslücke ist hier ein Angriff auf die Daten im Server.
"SSL Server Authentication". SSL authentifiziert den Server für den Anwender des Webbrowsers. Dadurch weiß der Anwender, daß er wirklich mit dem Server eine Verbindung aufgebaut hat (HTTPS URLs), den er auch kontaktieren wollte. Die Überprüfung geschieht mit Hilfe eines Zertifikates, das von einer dritten Institution vergeben wird. Der Anwender des Browser kann wählen, wessen Zertifikate er vertraut.
"SSL Privacy Protection". Erweiterung des HTTPS Protokolls. Alle Daten die zwischen Server und Browser ausgetauscht werden, werden verschlüsselt. Dadurch können Daten für Dritte auf dem Übertragungswege unzugänglich gemacht werden. Die Datenintegrität (Daten sind unverändert, bzw. nicht verfälscht) wird garantiert.
"Realms with Users and Groups". Verwaltung von Benutzern und Benutzergruppen für den Zugriff auf verschiedene Bereiche. Bereiche können sein: verschiedene virtuelle Hosts, Teile einer gesamten Website oder auch Applikationen. Ein und derselbe User kann in verschiedenen Bereichen unterschiedliche Zugriffrechte bekommen (siehe ACL). Die Anlage von Gruppen dient der Vereinfachung der Verwaltung von Zugriffsrechten. Rechte werden für einzelne Gruppen und/oder Benutzer vergeben. Den Gruppen werden Benutzer zugeordnet.
"Access Control Lists (ACLs)". Der Java Web Server stellt ACLs zur Verfügung, um Zugriffe auf individuelle Ressourcen. ACLs können auch Servlets zugeordnet werden. Dabei kann man sich das Konzept wie folgt vorstellen:
Es gibt Benutzerkonten, die jeweils zusammen mit dem Passwort eindeutig sind. Oft haben Benutzerkonten auch ein eigenes Home-Verzeichnis. Diese Benutzer lassen sich auch Benutzergruppen zuordnen. Die ACL ordnet nun den Benutzern und Gruppen verschiedenen Rechte für die Benutzung von Ressourcen zu, wie z.B. GET, POST, etc. ACL's können Rechte auch reduzieren. Der Gültigkeitsbereich von Benutzern, Gruppen und ACLs ist jeweils innerhalb eines Bereiches (Realm). Benutzer mit dem selben Namen, aber in unterschiedlichen Bereichen haben im Allgemeinen keine Beziehung zueinander.
Zusätzlich bietet der Java Web Server weitere Eigenschaften:
"Einfache Verwaltung". Administration und Rechteverwatlung kann mitunter sehr fehleranfällig sein. Daher stellt der Java Web Server ein einfach zu bedienendes grafisches Benutzerinterface für die Bearbeitung dieser Aufgaben zur Verfügung.
"Sichere Administration". Standardmäßig werden die Administrationseiten des Java Web Servers über das "Digest Authentication"-Protokoll geschützt. Zusätzlich kann die Verbindung über SSL verschlüsselt werden. Des weiteren kommunizieren der Server und das Administration Tool über einen internen Port, der beliebig festgelegt werden kann. Während der Port des Administration Tools (i.a. 9090) auch außerhalb bekannt sein kann, braucht das für den internen Port nicht der Fall zu sein. (Default ist: 9091).
"Servlet Sandboxing". Servlets erweitern die Funktionalität des Servers. Diese Servlets können entweder selbst vom Webserveradministrator bzw. den Entwicklern der Website geschrieben sein (denen sollte man in der Regel dann vertrauen können), oder von einem Drittanbieter bezogen werden (Sicherheitslücke). Servlets können in einem als "Sandkasten" bezeichneten Bereich ablaufen, in dem sie keinen Schaden verursachen können. Ein "Security Manager" stellt sicher, das diese Servlets nur dann eventuell gefährliche Operationen ausführen können, wenn folgende Umstände es zulassen:
Folgende Ressourcen des Servers werden durch das "Sandkastenprinzip" geschützt:
Die Trailversion des Java Web Server 1.1 (SUN) wurde auf einem Rechner unter dem Betriebssystem Windows 95 installiert. Als Browser wurde Netscape® Communicator 4.04 benutzt. Der Server wurde nur lokal getestet (keine Verbindung zu einem Netz mit mehreren Clients). Im Problemfall wurde jeweils versucht, in der beiliegenden Dokumentation Möglichkeiten zur Behebung zu finden.
Folgende Probleme sind aufgetreten:
Log-Dateien
Die Einträge im Access-Log File wurden nur sporadisch aufgenommen. Viele Anfragen erschienen nicht im Log-File.
Systemabstürze
Netscape stürzte in verschiedenen Situationen bei der Benutzung des Administrations Tools mehrmals mit einer "allgemeinen Schutzverletzung" ab. Der Server lief jedoch weiter. Dies erforderte jedoch immer einen Neustart des Rechners.
SSL-Verbindungen
Eine gesicherte Verbindung über SSL konnte nicht aufgebaut werden. Bei Versuchen den Server über den Port 7070 (Secure Webservice) zu kontaktieren, meldete Netscape, daß kein gemeinsames Verschlüsselungsprotokoll vorhanden wäre oder aber, daß der Inhalt der gelieferten Seite keine Daten enthält.
[_HOME_] ... [Übergeordnete Seite] ... [Vorherige Seite] ... [Nächste Seite]