© scx.hu

Wer in die Webprogrammierung mit Java einsteigen will oder muss, braucht einen Überblick über die Fülle der Standards, Technologien und Anwendungsserver. Dieser Artikel stellt die wichtigsten vor und erläutert, für welche Aufgaben sie sich am besten eignen.

Im Ökosystem der Web-Programmiersprachen steht Java mächtig unter Druck, die jungen Wilden wie Ruby on Rails drängen es an den Rand. Ein Einstiegshemmnis ist die Unübersichtlichkeit des Java-Zoos: Anders als bei PHP, bei dem es zum Apache-Modul in Version 5 kaum Alternativen gibt, verwirrt Java die Neulinge mit Begriffen wie Java Server Pages, Java Server Face, Applikationsserver und Java Enterprise Edition. Dieser Artikel bietet daher einen Überblick über die für Webanwendungen wirklich wichtigen Java-Technologien.

Java war von Anfang an für den Einsatz im Web konzipiert. In der 1996 erschienenen ersten Ausgabe des O\’Reilly-Buchs “Java in a Nutshell” heißt es: “Richtig aufregend an Java ist, dass es für die Programmierung im Internet konzipiert ist.” Zur damaligen Zeit war Java auf dem Stand 1.0 und Internetprogrammierung synonym mit Applet-Entwicklung. Trotz des modernen Designs mit kompaktem Bytecode, Unterstützung des asynchronen Nachladens von Ressourcen (heute unter dem Schlagwort Web 2.0 und Ajax bekannt), sicherer Sandbox und Plattformunabhängigkeit scheiterte das Konzept. Ursachen waren die zu geringe Bandbreite der privaten Internetanschlüsse, nicht weit genug verbreitete Unterstützung für Java im Browser und die unzureichende Rechenleistung der damaligen PCs, um die Java Virtual Machine performant zu betreiben.

Fulminanter Fehlstart

Die Java-Webtechnologie schien also am Ende, noch bevor sie richtig an Fahrt gewinnen konnte. Mitte der 90er Jahre setzte plötzlich ein regelrechter Hype um Java ein, denn damals (das Internet war stark im Kommen) stand Java mit seinem Funktionsumfang konkurrenzlos an der Spitze. Heute noch übertreffen Java-Applets die technischen Möglichkeiten von Ajax, auch wenn sie von der Verbreitung her ein Nischendasein fristen. Wer grafisch aufwändige Applikationen braucht, ist mit ihnen jedoch nach wie vor gut bedient. Das Kartenreservierungs-Applet der Bayerischen Staatsoper ([1], Abbildung 1) ist ein gutes Beispiel für einen nach wie vor zeitgemäßen Einsatz eines Java-Applets.

Abbildung 1: Der Online-Kartenverkauf bei der Bayerischen Staatsoper macht sich die guten grafischen Fähigkeiten der Java-Applets zunutze.

Servlets statt Applets

Bei Applets liefert der Server zwar Code und Daten, die Verarbeitung findet aber auf dem Client statt. Dieses Paradigma überforderte die Leistung der PCs in der Frühzeit von Java und wurde daher meist zugunsten der Server-seitigen Datenverarbeitung aufgegeben.

Prinzipiell ist das nichts Neues: Über die CGI-Schnittstelle lassen sich dynamische Seiten auch mit anderen Sprachen wie zum Beispiel Perl realisieren. Die Java-Architekten entwickelten jedoch eine eigene Architektur, die sich bis heute bewährt. Eine Laufzeitumgebung bietet per Java-Interface definierte Services (das Servlet-API), die jedes standardkonforme Java-Programm für die Erstellung der Webseiten nutzen kann. Eine Java-Webanwendung implementiert quasi Einstiegspunkte, die die Laufzeitumgebung auf Basis der vom User angeforderten URL anspricht. Anders ausgedrückt: Der Entwickler schreibt keine eigenständige Anwendung, sondern eine Bibliothek mit festgelegten Schnittstellen.

Wer in die Webentwicklung mit Java einsteigen will, kommt also um das Studium des Servlet-API nicht herum. Zum Glück ist dieses nicht besonders umfangreich, in den meisten Fällen kommt der Entwickler mit einigen wenigen Methoden aus, die um das Request-Response-Modell von HTTP herum gestrickt sind.

Java Server Pages

Das Servlet-API ermöglicht für sich genommen keine Trennung von Webdesign und Programmierung. Dass eine Model-View-Controller-Architektur in der Praxis viele Vorteile bietet, erkannten jedoch auch die Software-Architekten von Sun. Sie kreierten daher 1999 eine neue Technik zum Erzeugen dynamischer Webseiten, die Java Server Pages (JSP). Sie kehren das Prinzip des Servlet-API um: Nicht das Servlet erzeugt nun die Webseite, sondern die Webseite erzeugt das Servlet. Eine JSP sieht vereinfacht ausgedrückt aus wie eine HTML-Seite mit eingebettetem Java-Code. Die Laufzeitumgebung erzeugt daraus dynamisch ein Servlet. Webseiten mit wenig Programmlogik lassen sich so einfacher erstellen.

Wie bei anderen Sprachen ergibt sich auch bei Java Server Pages das Problem, dass HTML-Seiten mit einem steigenden Anteil an eingebettetem Programmcode unübersichtlich werden und schwer zu pflegen sind. Um die Trennung von Seitendesign und Programmlogik weiter zu verbessern, erfand Sun die so genannten Taglibs. Dabei handelt es sich um vom Entwickler definierte, den Standard-HTML-Tags ähnliche XML-Elemente, die in den Java Server Pages den Code von häufiger benötigten Funktionen vertreten und die der Parser erst zur Laufzeit in Java-Code umsetzt.

Bei den JSPs gibt es wie auch bei den Servlets mehrere API-Versionen. Mit jeder Fassung wuchs die Funktionalität und dadurch auch die Komplexität. So gibt es inzwischen eine eigene Mini-Skriptsprache innerhalb der JSPs, die so genannte Expression Language. Häufig benötigte Tags für Funktionen wie Flusskontrolle oder Textformatierung stellt die Standard-Taglib (JSTL) zur Verfügung.

Wie immer beschränkt sich Sun auch hier auf die Festlegung der Spezifikation, inzwischen zum größten Teil mit Beteiligung einer offenen Community. Implementierungen sind Sache der Applikationsserver. Für Open-Source-Anhänger erfreulich ist, dass die Apache Foundation die Referenzimplementierungen pflegt.

Java Server Faces

Ein weiteres, relativ neues API sind die Java Server Faces (JSF). Ihr Programmiermodell lehnt sich an Standards aus der Programmierung von lokalen Desktopanwendungen an. Die Oberfläche setzt sich aus verschiedenen GUI-Elementen zusammen, ein Listener-Interface verarbeitet die durch den Benutzer ausgelösten Ereignisse.

Diese schwer überschaubare Vielzahl an APIs hat Java den Ruf eingebracht, schwer beherrschbar zu sei. In der Tat ist es schwierig, den sich sehr schnell weiterentwickelnden Spezifikationen zu folgen. Wer dies als abschreckend empfindet, sollte aber bedenken, dass die Technologien oft das Leben eines Webentwicklers, der sich mit ihnen auskennt, stark erleichtern. Der Entwickler muss außerdem nicht alle APIs gleichzeitig nutzen. Frameworks abstrahieren schließlich sogar komplett von den Java-APIs.

Frameworks

Java als objektorientierte Sprache tendiert dazu, große Sammlungen von Klassen zu bilden. Jede Klasse für sich betrachtet ist verständlich und hat eine klar umrissene Aufgabe. Für sich genommen nützen die einzelnen Klassen jedoch nichts, da sie nur einen kleinen Bereich der nötigen Funktionalität abdecken. Frameworks bündeln daher Klassen, die die oft sehr ähnlichen Anforderungen von Webanwendungen abdecken, und ersparen es, das Rad neu zu erfinden. Für die Webentwicklung bedeutet der Einsatz eines Framework, dass der Entwickler mit den Low-Level-APIs programmieren kann, aber nicht muss.

Wer innerhalb von Firmen entwickelt, hat in Sachen Frameworks meist konkrete Vorgaben. Viele Applikationsserver bringen ihr eigenes Framework mit. Wer aber frei von solchen Voraussetzungen mit Java-Programmierung beginnt, sollte sich zumindest die Frameworks der Apache Foundation näher ansehen.

Mit Struts [2] steht ein über die Jahre gut gepflegtes Framework für die Webentwicklung zur Verfügung, das in vielen Projekten erfolgreich zum Einsatz kommt. Struts verwendet das klassische MVC-Design (Model View Controller). Besonders hervorzuheben ist die gute Dokumentation. Neben Wikis und Online-Ressourcen gibt es auch viele Bücher. Cocoon [3] ist eine Alternative, die bereits mächtige Features für den Publishing-Bereich enthält.

Nicht von der Apache Foundation stammt das Projekt Spring [4]. Es eignet sich für viele unterschiedliche Anwendungsbereiche, ist sehr mächtig und dient inzwischen auch anderen Projekten als Basis. Cocoon zum Beispiel setzt in der neuesten Version auf Spring.

Mehr als Webentwicklung

Alle bisher vorgestellten Technologien dienen dazu, den HTML-Code einer Webseite zu erzeugen und an den Benutzer auszuliefern. Das ist aber nur ein Aspekt der Webentwicklung. Nur kleine “Hello World”-Anwendungen kommen ohne Datenbank aus. Wichtig ist auch die Zugriffskontrolle, die gewährleistet, dass nur identifizierte Nutzer Aktionen auslösen oder Daten einsehen dürfen. Hier zeigt sich der große Unterschied zwischen Java-Webanwendungen und jenen in anderen Sprachen: Der Java-Ansatz verlagert die Verantwortung aus der Webanwendung in die Laufzeitumgebung, den Applikationsserver.

Die Spezifikation Java 2 Enterprise Edition (J2EE) hat in bester Java-Tradition Services für die Ablaufumgebung von Webanwendungen in Form von Interfaces definiert. Damit war und ist es recht einfach, Anwendungen, die diesem Standard entsprechen, in beliebige Applikationsserver-Umgebungen zu installieren. Wie bei den anderen APIs gab es jedoch mehrere Fassungen der J2EE-Spezifikation. Die ersten Versionen versuchten Datenbankzugriffe, Rollen- und Rechteverwaltung und vieles andere zu kapseln und vor der Webanwendung zu verbergen. Dieser Ansatz scheiterte.

Der Deployment-Deskriptor, der den Installationsprozess in einen Anwendungsserver in XML-Form beschreibt, verdeutlicht beispielhaft das Problem, es war ähnlich gelagert wie bei den Applets: Die Theorie abstrahierte in den frühen J2EE-Standards zu sehr von den realen Bedingungen. Als Folge entwickelten die einzelnen Applikationsserver proprietäre Erweiterungen des Deployment-Deskriptors, was die Anwendungen an einen bestimmten Server band. Die aktuelle J2EE-Spezifikation hat sich daher vom deklarativen XML abgewandt und setzt wieder verstärkt auf handgeschriebenen Programmcode.

Applikationsserver

Die Stichworte Applikationsserver und Laufzeitumgebung sind schon mehrfach gefallen. Dabei handelt es sich um umfangreiche Java-Programme, die die Anfragen von Browsern über das Netz entgegennehmen, an die Webanwendungen weiterleiten und deren Antworten wieder an den Browser zurückliefern. In produktiven Umgebungen stehen diese Server typischerweise in zweiter Reihe hinter einem oder mehreren Apache-Webservern, die unter anderem für die Lastverteilung, die Auslieferung von statischem Code oder für die Ver- und Entschlüsselung der Kommunikation zuständig sind.

Wer eine Java-Webanwendung entwickelt, kennt seine Zielumgebung entweder sehr genau (zum Beispiel bei Inhouse-Entwicklungen) oder gar nicht. Im diesem Fall bleiben dann alle Erweiterungen bestimmter Anwendungsserver außen vor. Nicht in allen Umgebungen ist dies möglich: Wer für SAP-Systeme programmiert, kommt um die Spezifika nicht herum.

Anwendungen, die für reine Webcontainer entwickelt sind, lassen sich am einfachsten in verschiedene Laufzeitumgebungen installieren. Webcontainer bieten nicht alle Services der umfangreicheren J2EE-konformen Server. Sie genügen jedoch für Anwendungen, die sich selbst um Datenbankzugriffe oder die Benutzerauthentifikation kümmern.

Entgegen dem Java-Prinzip “Compile once – run everywhere” spielt manchmal leider auch die Implementierung des Applikationsserver für ein bestimmtes Betriebssystem eine Rolle. Der Autor dieses Artikels weiß aus eigener leidvoller Erfahrung: Bei einer Anwendung, die in Tomcat oder Websphere unter Windows lief, kam es bei Websphere unter Linux zu Problemen.

Diese Inkompatibilitäten haben dem angeblich von der Plattform abstrahierenden Java insgesamt viel Kritik eingebracht. Wer jedoch schon einmal eine komplexe Anwendung auf andere Plattformen portiert hat, weiß, dass es sich dabei um eine schwierige Aufgabe handelt. Die Probleme zu kurieren, die mit Java-Webanwendungen auf nicht getesteten Plattformen auftreten, erweist sich im Vergleich als relativ einfach.

Tomcat, JBoss, Bea, Websphere & Co.

Typische Vertreter von Open-Source-Applikationsservern sind Tomcat ([5], Abbildung 2) und Jetty [6], beides reine Webcontainer, die auch in vielen kompletten Servern den Part des Webcontainers übernehmen. JBoss [7] ist ein kompletter, offen entwickelter J2EE-konformer Applikationsserver. Red Hat hat die dahinterstehende Firma inzwischen aufgekauft. Ebenso erging es Bea [8]. Lange Zeit Markt- und Technologieführer, ist Bea inzwischen Teil von Oracle. Wie die Zukunft des Bea-Servers in Konkurrenz zum Oracle-eigenen Applikationsserver aussieht, gilt als ungewiss.

Abbildung 2: Nach der erfreulich unkomplizierten Installation zeigt Tomcat, so heißt die Referenzimplementierung des Java-Webservers der Apache-Foundation, einen Begrüßungsbildschirm mit Links zur Dokumentation und zu Beispielanwendungen.

IBM kam mit seinem Applikationsserver Websphere ziemlich spät auf den Markt. Am Anfang nicht wirklich produktiv einsetzbar, läuft er jetzt auf allen IBM-Plattformen und hat einen hohen Marktanteil. Von Websphere gibt es auch eine Community-Edition [9]. Sie enthält aber eine völlig andere, modernere Technologie als die kommerziellen Fassungen: Sie nutzt den Apache-Applikationsserver Geronimo [10], dessen Code zum überwiegenden Teil von IBM stammt. Abbildung 3 zeigt die Web-Administrationskonsole von Geronimo. Sun selbst schickt seinen Server unter dem Namen Glassfish [11] ins Rennen – ebenfalls unter Open-Source-Lizenz.

Abbildung 3: Geronimos Web-Adminkonsole bietet Zugriff auf grundlegende Administrationsfunktionen und zusätzlich einen Überblick über den Systemstatus.

Einen Versuch wert

Alle Server sind, wenn nicht Open Source, zumindest als Trialversion per Download erhältlich. Normalerweise ist die Installation einer lauffähigen Umgebung kein Problem. Für die optimale Konfiguration einer produktive Umgebungen im Firmenumfeld ist aber umfangreiches Expertenwissen nötig.

Entwicklung in der Praxis

Für die Entwicklung von Java-Webanwendungen stehen mit Eclipse (Abbildung 4) und Netbeans zwei leistungsfähige IDEs zur Verfügung, die ein Linux-Magazin-Artikel vergleicht [12]. Viele kommerzielle Produkte (Websphere, Bea, SAP) setzen auf das den Markt dominierende Eclipse auf.

Abbildung 4: Authoring-Tool: Die leistungsfähige IDE Eclipse erleichtert das Schreiben und Pflegen von Java-Code. Die Nummer zwei nach Marktanteil – Netbeans – ist ähnlich gut.

Einfache Webanwendungen lassen sich in anderen Sprachen leichter schreiben als in Java. Java bedient jedoch fortgeschrittene Erwartungen flexibel über viele Bibliotheken, Schnittstellen und Tools. Diese Leistungsfähigkeit hat aber ihren Preis: Einzelne Entwickler können wegen des großen Umfangs unmöglich alle Java-Technologien gleich gut beherrschen.

Flexibel

Doch Java wäre nicht Java, wenn es nicht auf die neuen Stars der Webentwicklung wie Ruby eine Antwort parat hätte. Mit Groovy [13] gibt es eine schwach typisierte Skriptsprache, die sich in Java-Bytecode übersetzten lässt und die einen Zugriff auf alle Java-Bibliotheken ermöglicht. Das zugehörige Webframework Grails [14] borgt von dem erfolgreichen Ruby on Rails mehr als nur einen Namensbestandteil. Wer sich mit Ruby auskennt, kann alternativ außerdem Jruby benutzen. (pkr)