Abb.1: Servlet- und EJB-Entwicklung mit JBuilder 4

Diesen Monat werfen wir einen Blick auf aktuelle Web-Entwicklungen und hoffen den Freaks und Geeks ein paar interessante Anregungen liefern zu können.

Viele Wege führen zu HTML. Das wussten bereits die alten WWW-Gladiatoren, die sich noch nicht mit Cascading Stylesheets, Javascript, XML, XSL, Servlets, PHP, Applikations-Servern oder EJB-Containern rumschlagen mussten, um nur ein paar aktuelle Technologien zu nennen. Während früher jeder Programmierer seinen eigenen Editor schrieb, gehört es heute für die “Top Web Guns” schon fast zum guten Ton, einen Applikations-Server auf der Referenzliste zu haben. Fast wöchentlich wagt sich ein Neuer in die hart umkämpfte Web-Arena, doch längerfristig werden davon nur sehr wenige überleben. Dies ist auch nicht weiter tragisch, Hauptsache, das allgemeine technologische Wissen bleibt erhalten und fließt in die nächste Software-Generation ein. Grundlage dafür sind allerdings Open Source und vernünftige Patentregelungen, die dies nicht verhindern.

Doch was ist denn nun eigentlich “State of the Art” bei der Web-Entwicklung? Ich möchte auf diese Frage hier etwas ausführlicher eingehen, weil ich oft gefragt werde, wie bei der Linux-Community [1] dieses oder jenes realisiert wurde, und ich bei der Beantwortung merke, dass mir die Vermittlung des Gesamtbildes wichtiger ist, als nur ein paar wenige technische Details zu erörtern, die dort zufälligerweise realisiert sind. Also ab ins README damit, welches in der Online-Version Diskussionsgrundlage für all die nicht erwähnten und vergessenen Themen sein soll. Die Roadmap sieht dabei wie folgt aus: Datenbanken, Programmiersprachen, Web-Server und Applikations-Server. Der Fokus liegt hauptsächlich auf Open Source Software, wobei ein Blick über den berühmten Zaun nie schaden kann.

Wohin mit den Daten?

Bei der Programmierung von komplexen Web-Applikationen wird man in der Regel auf relationale Datenbanken zurückgreifen, weil diese gut erforscht sind und von vielen Leuten seit Jahrzehnten eingesetzt werden. Im Open-Source-Umfeld stehen hier unter anderem MySQL [2], PostgreSQL [3], Interbase ([4], [5], [6], [7], [8]) und SAP DB [9] zur Verfügung. Für welche dieser Datenbanken man sich entscheidet, hängt sehr stark von den Anforderungen und persönlichen Vorlieben ab. Bei PostgreSQL kann man zum Beispiel Stored Procedures in TCL oder Perl schreiben, Interbase wird sehr gut von Borlands Entwicklungswerkzeugen (Delphi, C/J-Builder und in Zukunft Kylix) unterstützt, SAP DB integriert sich nahtlos in ein StarOffice-basiertes Framework und MySQL wird von einer sehr großen Anhängerschaft in vielen bekannten LAMP-Projekten eingesetzt.

All diese Datenbanken sind sehr gut dokumentiert, und diverse Firmen, die an der Weiterentwicklung beteiligt sind, liefern zusätzlich kommerziellen Support. Interessant ist in diesem Zusammenhang übrigens der derzeitige Code-Split bei Interbase. Neben dem offiziellen CVS-Tree [6] bei Sourceforge existiert als Alternative das Firebird-Projekt [7], welches aus Verärgerung über einige Aussagen von Borland entstanden ist. So wie es scheint, haben sich die Wogen jedoch wieder geglättet, und nächstes Jahr wird sich zeigen, wie die abwechslungsreiche Interbase-Saga, die in einer sehr gelungenen Zusammenfassung bei Upside Today [10] nachzulesen ist, weitergehen wird. Die von “Mama Interbase” Ann Harrison und ihrem Gatten Jim Starkey gegründete Firma IBPhoenix [8] wird dabei sicher eine wichtige Rolle spielen.

Auf der Suche nach dem verlorenen Java-Objekt

Bisher sind wir in relativ klassischen und verhältnismäßig ungefährlichen Gewässern herumgeschwommen. Wer sein Glück bei der Suche nach kostbaren Web-Perlen lieber im Haifischbecken versucht und mehr auf plattformunabhängige All-In-Java-Lösungen steht, der wird sicher seine Freude an reinen Java-Datenbanken wie InstantDB [11] von Lutris Technologies, die auch für den Web-Applikationsserver Enhydra verantwortlich sind, und Hypersonic SQL [12] haben. So kann InstantDB beispielsweise mit Features wie Transaktionen, Triggern und Sub-Selects aufwarten, und auch Hypersonic wird bereits in vielen Java-Projekten als Datenbank-Backend eingesetzt.

Von hier ist es dann nicht mehr weit zu objektorientierten und XML-Datenbanken, die in letzter Zeit immer mehr an Bedeutung gewinnen, weil man Java-Objekte und XML-Bäume effizient serialisieren möchte (eine interessante Übersicht findet man etwa unter [13] oder [14]). Hier haben kommerzielle Datenbanken ganz klar die Nase vorne, und wenn man sieht, wie etwa Oracle die Programmiersprache Java in ihr System integriert hat (Java Stored Procedures, transparentes Abspeichern von XML-Dateien und Zugriff per Java DOM, Enterprise Java Beans (EJB) direkt in Oracle), dann könnte man schon etwas neidisch werden. Doch auch kleinere Projekte wie XDB:XML [15], dbXML [16], XDBM [17], OpenXML [18] und Castor [19] haben ihren Reiz.

Ein potenzieller neuer Shooting Star könnte die in Java implementierte, objektorientierte Datenbank Ozon [20] werden, die mit einer W3C-konformen DOM-Implementierung, Apache Xerces-J und Xalan-J Integration ([21], [22]) sowie einem ODMG 3.0-Interface [23] aufwarten kann. Man plant, diese Software dem Apache-XML-Projekt beizusteuern, doch durch den Rückzug von Stefano Mazzocchi, einem der Hauptakteure bei Apache-XML, ist diese Integration etwas ins Stocken geraten. Ich werde Ozon auf jeden Fall im Auge behalten, und vielleicht hat Falko Bräutigam vom Softwarebüro ja mal selber Zeit und Lust, über sein neues Baby zu berichten. ;-)

Am Rande des Apache-Universums

Damit haben wir erst einen der vielen Bausteine einer Web-Applikation beschrieben, und ich merke, dass ich mir diesmal ganz schön was vorgenommen habe. Wenden wir uns also als nächstes den Web-Servern zu. Für fast 60% der Web-Sites lautet hier die Antwort schlicht und ergreifend Apache [24]. Dies hat seinen guten Grund: Apache ist stabil, für die meisten Web-Sites schnell genug, vielfältig konfigurierbar, mit allen möglichen Web-Technologien kombinierbar (Perl, TCL, Python, PHP, JSP, Servlets,…) und sehr gut dokumentiert. Dennoch haben auch Projekte wie Roxen [25], AOLServer [26], thttpd [27], Boa [28], Hawkeye [29] und sogar der Linux-Kernel-basierte TUX [30] ihre Berechtigung ([31]).

So glänzt Roxen beispielsweise mit einer sehr mächtigen Makrosprache sowie Perl-, JSP- und XSLT-Integration. Httpd, Boa, TUX und AOLServer hingegen sind auf Performance getrimmt, und last but not least bietet Hawkeye eine integrierte Umgebung mit eingebautem HTTP-, SMTP/POP3-, NNTP- und FTP-Server. Das kann sich durchaus sehen lassen. So ganz nebenbei habe ich am LinuxPark 2000 von Ralph Engelschall (unter anderem bekannt für sein mod_ssl-Modul und die GNU Portable Threads, welche bei Apache 2.0 zum Einsatz kommen) erfahren, dass er seit Jahren an einer ähnlichen neuen Server-Architektur (Open Structured Server Platform [32]) arbeitet, bei der sich viele klassische Dienste ähnlich wie bei Apache konfigurieren lassen. Rewrite-Regeln sind ja bei einem FTP-Server genauso sinnvoll wie bei einem Web-Server. Warum also nicht gleich ein Cross-Server-Framework dafür entwickeln?

Im High-End-Bereich kämpft man heute auch mit Problemen, die in der Vergangenheit kaum beachtet wurden. Wie kann beispielsweise ein Web-Server 10000 Clients gleichzeitig bedienen? Solche und ähnliche Fragen sind im E-Commerce-Bereich plötzlich von strategischer Bedeutung und können nicht einfach ignoriert werden. Hierzu kann ich den Klassiker zum C10K-Problem [33] von Dan Kegel nur wärmstens empfehlen. Wie man leicht erkennt, ist hier noch viel zu tun, und auch Apache 2.0 wird nicht das Ende der Fahnenstange sein, zumal dieser Web-Server von seiner Architektur her langsam in die Jahre kommt.

Generell ist die Tendenz zu beobachten, Datenbank-, HTTP- und Applikations-Server aus einem Guss zu bauen, um so maximale Performance herauszukitzeln. Dies ist zwar löblich, kann aber zu Problemen führen, wenn dann doch ein Feature fehlt (SSL-Unterstützung, virtuelle Hosts und Rewrite-Rules sind beliebte Beispiele) oder man einen Teil ersetzen möchte, für den es technologisch bessere Lösungen gibt. Zumindest auf Web-Ebene gibt es beim Apache immer die Möglichkeit, entsprechende ProxyPass[Reverse]-Regeln wie

ProxyPass         /orion          http://meinserver.de:7080/
ProxyPassReverse  /orion          http://meinserver.de:7080/

zu verwenden, um so alle Möglichkeiten mit erträglichen Performance-Verlusten auszuschöpfen. Ich mache dies etwa bei Zope-basierten Web-Sites. Andere Teile einer All-In-One Lösung lassen sich oft nur mit erheblichem Mehraufwand ersetzen, und dies auch nur, wenn eine saubere Plug-In-Architektur verwendet wurde oder der Quellcode des Systems vorliegt. Soviel zum Einsatz der verschiedenen Web-Server aus 30000 Meter Höhe. Wenden wir uns nun den verschiedenen Programmiersprachen beim Entwickeln von Web-Applikationen zu.

Sehr beliebt sind klassische Skriptsprachen wie Perl, Python, Tcl und PHP sowie die Programmiersprachen C/C++ und Java. Natürlich kann jeder mit seiner Lieblingssprache einfache CGI-Programme schreiben, doch wir bewegen uns hier in Richtung Applikations-Server und da sind nun mal die oben erwähnten Sprachen dominierend. Für Apache gibt es die entsprechenden Module mod_[perl|python| snake|tcl|php|java|jserv|jk] ([34-41]), wobei mod_snake eine Art mod_python für Apache 2.0 ist und ich bei den Java-Modulen mod_jk empfehlen würde, da man damit über Tomcat JavaServer Pages 1.1 und Java Servlets 2.2 in den Apache-Web-Server integrieren kann.

Abb.1: Servlet- und EJB-Entwicklung mit JBuilder 4

Yet Another Programming Language (YAPL)

Wie schon oben erwähnt, kann Perl auch in Roxen verwendet werden, und um das Bild etwas abzurunden, wenden wir uns nochmals dem AOLServer zu. Hier ist defaultmäßig Tcl eingebaut, und die über 300000 Zeilen umfassende Killer-Applikation ACS (Arsdigita Community System [42]), welche Anfang November 2000 in der Version 4.0 erschienen ist, zeigt auf beeindruckende Art und Weise, was sich damit realisieren lässt. Leider ist ACS sehr stark auf Oracle fixiert, so dass die ACS-Portierungsprojekte auf PostgreSQL (OpenACS [43]) und Interbase ([44]) noch nicht nachziehen konnten.

Das ist aber nicht alles! Sowohl PHP als auch Python (PyWX [45]) sind in den AOLServer integrierbar, und in Kürze wird auch ein entsprechendes Tomcat Servlet-Modul freigegeben, welches die Möglichkeit eröffnet, damit die Java-Portierung [46] von ACS 4.0 zu betreiben. Arsdigita entfernt sich also langsam von seinen Wurzeln und zieht mit der Hauptkarawane in Richtung Java, weil man Kunden heutzutage kaum mehr Tcl als der Weisheit letzten Schluss verkaufen kann. Dass Java so boomt, hängt sicher mit der Vielzahl an standardisierten Schnittstellen zusammen, die zwar nicht immer beim ersten Wurf gelingen, aber längerfristig für alle anderen Projekte die Messlatte höher legen. Zudem existieren für die unterschiedlichen APIs oft eine Vielzahl an konkurrierenden Implementierungen. Dies sieht man sehr schön bei der J2EE-Spezifikation mit mehreren Dutzend Enterprise JavaBean (EJB) Applikations-Servern, die sich in diesem hart umkämpften Markt nichts schenken. Sehr erfreulich ist auch die neue JBoss-Version 2.0 [47], die zeigt, dass Open Source Software in diesem Bereich durchaus mit den kommerziellen Konkurrenten mithalten kann. Der Gruppe um Marc Fleury und Rickard Öberg gebührt ein großes Dankeschön!

Ein weiterer Grund für die hohe Akzeptanz von Java sind die vielen Entwicklungsumgebungen, wie etwa Suns Forte/NetBeans [48] und Borlands JBuilder 4 [49]. Mit letzterem Produkt (siehe Abb. 1) kann man in der Enterprise-Variante, ohne ein einziges Mal die IDE zu verlassen, bequem Applets, JSP/Servlets, JavaBeans, Enterprise JavaBeans und verteilte J2EE-Applikationen für die Java2-Plattform entwickeln. Da schlägt das Herz jedes Projekt-Managers höher. Natürlich hat Borland auch gleich einen eigenen EJB-Applikations-Server im Programm, um die Integration noch schmerzloser zu gestalten, denn in der jetzigen Situation sind die Applikations-Server alles andere als kompatibel zueinander. Die Spezifikation stellt nämlich nur ein grobes Gerüst dar, und jeder Anbieter baut wie immer Zusatz-Features ein, um die Kunden an sich zu binden. Diese Situation wird sich aber in Zukunft sicher verbessern, weil sonst das ganze Konzept versagt, und das kann nicht im Sinne von Sun und den vielen Anbietern von EJB-Komponenten sein.

Cut!

Leider muss ich an dieser Stelle meine Ausführungen aus Platzgründen beenden. Ich werde aber im nächsten Readme (5 Jahre Tom\’s Readme!) mit den XML-, EJB- und sonstigen Applikations-Servern fortfahren und auch eine Signal/Slot-Implementierung in Python vorstellen, welche auf den Community-Seiten bei der Realisierung eines dynamischen Caching-Servers eingesetzt werden soll. In diesem Sinne Happy GNU/Year!

Copyright © 2002 Linux New Media AG