Welche Sprache für CGIs/Scripting ?

Eine wichtige und oftmals unverzichtbare Sache für eine Website sind sogenannte Common Gateway Interface (CGI) Scripte bzw. Programme (i.w. allgemein als Webapplikationen bezeichnet), die erst eine Interaktion zwischen Nutzer/Browser und Webserver/Webapplikation erlauben.

Um auch eine gewisse "Plattform-Unabhängigkeit" zu erreichen, haben sich zur Programmierung von Webapplikationen Interpreter-basierte Sprachen durchgesetzt. D.h. gibt es einen gewissen Interpreter für alle Plattformen, so kann man i.d.R. auch davon ausgehen, daß der Großteil der dafür geschriebenen Programme/Skripte auch auf allen Plattformen bzw. nach relativ geringen Anpassungen ebenfalls funktioniert.

Zu den am häufigsten für Webapplikationen genutzten Sprachen, für die ein Interpreter für nahezu alle gängigen Plattformen verfügbar ist, zählen Perl, PHP,Python, Javascript und Java, auf die im folgenden kurz eingegangen wird.

Perl

Perl ist eine sehr komplexe, besonders (aber nicht nur) für Textverarbeitung geeignete Sprache, die traditionell als ein Konglomerat aus der Programmiersprache C, der Mustererkennungs- und Verarbeitungs-Sprache awk, sowie dem Stream Editor sed und Shell Script Sprache angesehen wird. Mittels Perl lassen sich gewisse Aufgabenstellungen sehr rasch und bequem lösen.

Für Perl gibt es mehr oder weniger geeignete "Entwicklungsumgebungen", wie z.B. Emacs oder Xemacs bzw. ddd als grafischen Oberfläche zum Debuggen.

Perl war in den Anfängen des WWW unter den für Webapplikationen eingesetzten Sprachen die mit Abstand dominierende. Das hat sich aber im Laufe der Zeit geändert, denn mitlerweile gibt es modernere Programmiersprachen, die teilweise oder ganz viele Schwächen Perls bzgl. Nutzung im Zusammenhang mit Webservern wettmachen.

Eine dieser Schwächen ist z.B. die Art und Weise der Modularität von Perl. Zwar kann Perl durch jede Menge Module/Bibliotheken erweitert werden, doch können selbige nicht als separates Paket installiert sondern müssen immer gegen die aktuelle Perlversion kompiliert werden.

D.h., werden Perl-basierte Applikationen verwendet, kann nicht ohne weiteres sichergestellt werden, daß nach einem Upgrade (das z.B. aus sicherheitstechnischen Gründen erforderlich wurde) auch alle Skripte wieder ordnungsgemäß funktionieren, da es nicht üblich bzw. teilweise auch gar nicht möglich ist, Perl-Applikationen mit den von ihnen benötigten Modul/Bibliotheken zu bundeln. Ergo, fehlt ein Modul, kann man froh sein, wenn irgendwo dokumentiert ist, welches benötigt wird.

Installiert man dann das fehlende Modul, ist es nicht selten, daß selbiges von weiteren abhängig ist und diese ebenfalls neu kompiliert und installiert werden müssen. Neuere Perl-Versionen unterstützen zwar auch hier etwas (automatischer Download/Kompilierung/Installation von benötigten Komponenten), wenn man diesen Prozeß allerdings nicht peinlichst genau protokolliert, weiß man am Ende wieder nicht, welche Module wirklich gebraucht werden und man hat u.U. sogar Komponenten installiert, die aufgrund von Versionskonflikten trotzdem nicht funktionieren. Z.B. Modul A funktioniert nur mit einer älteren Version von Modul N, Module X benötigt jedoch eine neuere Version und hat aufgrund des "automatischen" Updates die aktuelle Version von Modul A installiert.

Ergo ist ein Perl-Upgrade oftmals ein sehr aufwendiger Prozeß und mit vielen Risiken verbundener Prozeß, der keinesfalls garantiert, daß danach alle Applikationen wie vor dem Upgrade funktionieren.

Ein weiteres Problem, was wahrscheinlich vielen Programmierern den Einstieg bzw. die Akzeptanz von Perl erschwert, ist die Lesbarkeit des Quellcodes. Sicher kann auch hier durch Einhaltung von Konventionen und Selbstdisziplin etwas Abhilfe geschaffen werden, allerdings ändert dies nichts am Fakt, daß Perl unleserliche Konstrukte zuläßt, die oftmals aus (vermeintlichen) Performancegründen bzw. simpler Schreibfaulheit zu konsequent genutzt werden.

Last but not least hat Perl (wie viele andere Programme auch), ein Relokations-Problem. D.h., wurde das Programm z.B. mit dem Installations-Prefix /usr/bin kompiliert und zu einem Paket zusammengeschnürt, ist es relativ kompliziert, das Paket unter einem anderen Pfad (z.B. /opt/test) zum Testen zu installieren, da saemtliche Pfade hart einkompiliert sind und selbst das Setzen von entsprechenden Environment Variablen nicht 100% funktioniert - (es werden noch immer Module und Libaries unter /usr gesucht). Ergp ist ein paralleles Testen einer neuen Perlversion nur möglich, wenn man das gesamte Paket selbst mit entsprechendem Prefix kompiliert und wenn man sich dann entschieden hat, auf die neue Version umzusteigen, selbiges noch einmal mit gleichen Parametern aber anderem Prefix (i.d.R. /usr bzw. /usr/local) wiederholt.

Ergo läßt sich feststellen, daß gerade ein Upgrade von Perl ein wahrer Alptraum und ungeheuer aufwendig ist. Aus diesem Grund sollten man auf den Einsatz von Perl-basierten Server-Applikationen möglichst verzichten! Falls es aber doch einmal notwendig wird (quick and dirty Problem-Lösung), sollte man sich auf die Module/Bibliotheken beschränken, die im Perl-Basis-Paket enthalten sind (Viel Spaß beim Herausfinden, welche das sind ;-)).

PHP (PHP: Hypertext Processor)

PHP war ursprünglich eine Sammlung von Perl Scripten bezeichnet als ‘Personal Home Page Tools’, wurde nach und nach erweitert und schließlich vollkommen in C sowohl als Webserver-Modul als auch standalone Interpreter implementiert. Dabei hat man sich weiterhin stark an den Features von Perl und C orientiert, jedoch versucht, offensichtliche Schwächen von Perl (Lesbarkeit, Struktur, Modularität) von vornherein zu vermeiden.

Im Gegensatz zu Perl wurde auch das Problem der Verschiebbarkeit (Relokierbarkeit) gelöst, indem in der PHP-Konfigurationsdatei (default: /etc/php.ini) angegeben werden kann, wo zusätzliche Module gefunden werden können.

Das Problem ist allerdings, daß die Module i.d.R. stark von der verwendetenen PHP-Version abhängen und PHP selbst stark von der Version des verwendeten Webservers. D.h. wird ein neue Version des Webservers installiert, kann man nicht sicher sein, ob PHP nach der Aktualisierung noch funktioniert (ist wahrscheinlich nicht so gewollt, aber erfahrungsgemäß Tatsache). Da die verschiedenen Software-Vendor nur selten Pakete für sämtliche existierende Webserver-Versionen bereitstellen, bleibt auch hier oftmals nur die Neukompilierung von PHP. Ohne entsprechendes Know-How und Qualitätsmanagement kann auch dies zu einer sehr zeitraubenden Sache werden und garantiert nicht wirklich, daß danach genau die Module wieder zur Verfügung stehen, die für die jeweiligen PHP-Applikationen benötigt werden. Also für Produktionssysteme eine nicht unwesentliche Problematik.

Ein weiteres Problem ist der Support für verschiedene Webserver-Versionen. Beispielsweise wird die aktuelle Version (2.x) des am weitesten verbreiteten/ eingesetzten Webservers, dem Apache httpd nach gut einem Jahr des ersten Releases (2002) noch immer nicht offiziell unterstützt, obwohl eine Implementation existiert und i.d.R. auch zu funktionieren scheint. Frage ist hier wieder, soll sich der Anwender deshalb auf eine alte Version des http-Servers einschränken, die evtl. nicht mehr dem Stand der Zeit entspricht bzw. den jeweiligen Ansprüchen entspricht, oder ... ?

Ebenso ist ein nicht unwesentlicher Fakt ist, daß PHP Multithreaded Server nicht oder nur begrenzt unterstützt. Selbst wenn PHP mit entsprechenden Servern zu laufen scheint, ein Debugging (egal mit welchem [kommerziellen] Werzeug), funktioniert ganz einfach nicht. Sicherlich gibt es Werkzeuge (wie z.B. Zend-PHP-Debugger), mit denen das Debuggen in einem eigens mitgelieferten lokalen single-threaded http-Server (zumindest unter Linux) gelegentlich sogar funktioniert, aber was nützt einem das Testen/Debuggen auf einem Server, der nur sehr entfernt und limitiert die Produktions-Umgebung widergibt? Ergo bleibt dem Entwickler wieder nur die stark limitierende Möglichkeit, mittels printf Funktionen sich zumindest halbwegs einen Überblick über den aktuellen Zustand der Applikation zu verschaffen.

Last but not least hat PHP zumindest mit dem Apache http-Server ein großes Problem bzgl. virtuellem Webhosting. Es gibt faktisch nur eine Konfiguration für den gesamten Webserver und die gilt für alle virtuellen Hosts. Zwar gibt es Ansätze, per Direktiven (und nicht nur via php.ini) einige wenige Parameter zu konfigurieren, aber dies funktioniert halt nicht oder nur fehlerhaft. D.h., außer der PHPINIDir im globalen Context (d.h. für alle virtuellen hosts geltende Einstellungen) sollte man tunlichst die Nutzung entsprechender Direktiven meiden, um zumindest ein halbwegs deterministisches Verhalten des Servers zu erreichen.

Zusammenfassend muß also gesagt werden, daß der Einsatz von PHP sicherlich dem von Perl vorzuziehen ist, allerdings bringt auch PHP an sich eine Menge Tücken mit sich, die hinsichtlich stabiler Produktionssysteme durchaus sehr bedenklich sind. Deshalb scheint es ratsam, den Einsatz von PHP zumindest auf Produktions- Systemen so stark wie möglich einzugrenzen.

Python

Würdest du mit einem Fallschirm springen, dessen Basis-Funktionalitäten nicht mal getestet wurden? Sorry, aber eine Sprache/Interpreter zu benutzen, dem Fehler erst auffallen, wenn die fehlerhafte Stelle im Code durchlaufen wird, ist wohl mehr als nur reiner Frevel. Geiches gilt für die stark fehlerträchtige Syntax: Nicht Klammern sondern Einrückungen mittels Tabulator werden zur Kennzeichnung von Code-Blöcken genutzt. Also viel Spaß beim Suchen, wenn mal ein Leerzeichen/Tab zuviel oder an der falschen Stelle steht. Wer hier keinen entsprechenden Editor zwecks Tab/Whitespace-Hervorhebung zur Hand hat, dürfte aufgrund der Sysiphus-Arbeit schnell verzweifeln.

Wer Python einsetzt, hat also entweder zuviel Zeit und Programmierkapzitäten (um Tests zu schreiben, die zumindest ein Durchlaufen aller Code-Blöcke der jeweiligen Applikation garantieren) oder handelt schlichtweg verantwortungslos.

.net

Weg von der Platform-Unabhängigkeit und hin zu einem Konglomerat aus verschiedensten Programmiersprachen? Sich wieder sämtliche Probleme reinholen, die durch die Nutzung anderer Sprachen impliziert werden (siehe oben)? Wer will denn sowas?

Java

Java kennt inzwischen wahrscheinlich jeder. Java Interpreter/Compiler sind inzwischen für jede gängige Plattform verfügbar. Ebenso kann die Sprache auf eine riesige Nutzer- und Entwicklergemeinschaft aka Community verweisen. Im Gegensatz zu den oben genannten Sprachen gibt es eine Vielzahl ausgezeichneter freier als auch kommerzielle Tutorials und Dokumentationen, die nicht nur dem Neuling den Einstieg in diese Programmiersprache versüßen, sondern auch dem Profi eine große Hilfe bei der Lösung auch von relativ kniffligen Problemen sein können.

Auch die Java-Schnittstellen-Dokumentationen sind vorbildlich und denen anderer wie z.B. Perl als auch PHP um Lichtjahre voraus. Das hängt sicherlich auch damit zusammen, daß Java bereits sprachliche Mittel zur Verfügung stellt, die eine strukturierte Dokumentation in Form von Kommentaren innerhalb der Quelltexte (Sourcen) erlauben und bietet auch entsprechende Werkzeuge (javadoc) an, die diese in ein entsprechendes Format (z.B. HTML oder MIF) mit zugehörigen Navigationsmöglichkeiten zu extrahieren.

Ein weiteres Plus ist (ähnlich wie bei Perl oder PhP) die Vielfalt an sehr nützlichen Bibliotheken und Anwendungen, wobei der Mainstream größten teils Open Source und damit jedem zugänglich ist. Im Gegensatz zu anderen zuvor genannten Sprachen wird deren Einbindung in eigene/andere Applikationen allerdings max. durch die zu verwendende Java Virtual Machine (JVM) eingeschränkt. Wenn man sich hier generell an der JVM von Sun orientiert, kann i.d.R. immer die neuste Version verwendete werden, da Sun sehr viel Aufwand in die sogenannte Rückwärtskompatibilität investiert und sich selbiges auch mehrfach bewährt hat. Ergo muß man hier nicht zwecks Einbindung neuer Features sämtlichen Müll teilweise oder gar komplett neu kompilieren und auf Kompatibilität mit aktuell laufender Applikationen testen. Man nimmt die jeweilige Bibliothek (*.jar file) einfach in den Klassenpfad für die Applikation auf und fertig.

Ebenso ist die Benutzung unterschiedlicher Versionen eine (oder mehrerer) Bibliotheken im Gegensatz zu anderen Sprachen kein Problem, denn es reicht, die jeweiligen Bibiliotheken anhand ihres Namens (z.B. sitemap-1.0.jar und sitemap-2.1.jar) oder ihres Pfades (z.B. /lib/1.0/sitemap.jar oder /local/2.1/sitemap.jar unterscheiden zu können - den Rest erledigt die JVM selbst durch Berücksichtigung des entsprechend angepassten Klassenpfades. Das ist Flexibiltät vom Feinsten, die nicht nur Administratoren außerordentlich zu schätzen wissen.

Ein weitere sehr wichtige Sache: es gibt eine Vielzahl von sogenannten ‘Integrierten Entwicklungsumgebungen’ aka IDEs, mit denen man sehr effektiv programmieren und auch debuggen kann, egal ob single- oder multithreaded Programme, egal ob lokal oder remote. Mit Eclipse steht hier z.B. ein sehr vielsprechendes freies Entwicklungwerkzeug zur Verfügung, zu den führenden kommerziellen zählen wohl Borland's JBuilder, IDEA's IDEA bzw. Sun Microsystem's NetBeans.

Last but not least: die Performance. Oftmals wird Java nachgesagt, es sei viel zu langsam. Das war vielleicht zu Beginn der Entwicklung dieser Sprache der Fall (0.x und 1.x Versionen), inzwischen hat sich aber auch hier eine Menge geändert. Gut geschriebene Programme profitieren hier nicht nur von verbesserten Intepretern sondern u.a. auch von der während der Laufzeit Code optimierenden HotSpot^TM Technologie. So kann es durchaus sein, daß Java-Programme sogar ein besseres oder nur geringfügig schlechteres Laufzeitverhalten als in C geschriebene Programme zeigen (z.B. zeigte ein Vergleich eines von CA in C als auch Java geschriebenen Applikations-Servers, das der Java-Server unter starker Last sogar bedeutend besser als sein C-Kompanion abschnitt). Das einzige Problem scheint das schlechte Startup-Verhalten einer JVM zu sein (d.h. Zeit, die vergeht, bis der Java-Interpreter gestartet, die Applikation geladen hat und beginnt, selbige abzuarbeiten) sowie die je nach Platform mehr oder weniger gute Performance bzgl. Grafik (zwecks platform-Kompatibilität nutzt Java das Framework des jeweiligen Systems - also X11 oder MFC - nicht direkt, sondern macht alles selbst). Bzgl. Webserver- Applikationen/Scripte ist letzteres, egal wie groß der Unterschied zu nativen Applikationen auch ist, keine Rolle, da dort i.d.R. nicht mit grafischen Oberflächen gearbeitet wird (unter *x basierten Systemen oftmals nicht mal ein X-Server installiert ist). Das Startup-Problem umgeht man, in dem man halt nicht jedesmal für eine Anfrage eine neue JVM startet, sondern einen Java-Applikation-Server wie z.B. J2EE oder Tomcat benutzt. Vorteil dieser Server ist zu dem u.a., daß man Serverapplikationen (Scripte im ursprünglichem Sinne, könnte man hier als Mini-Applikationen betrachten) zur Laufzeit (bei Freigabe sogar entfernt aka remote) starten/stopen/neu installieren oder auch löschen kann, ohne den Server jedes mal neue starten zu müssen, geladenen Applikationen persistent (in kompilierter Form inkl. Zustand ausgelagert) und bei Bedarf sofort wieder geladen und abgearbeitet werden können. Anders als bei PhP oder Perl, muß hier nicht das ganze erneut interpretiert/kompiliert werden, was in einem deutlich besseren Laufzeitverhalten (besonders unter Last) bemerkbar macht. Ergo kann man sicher sagen, daß die Performance von Java-Applikationen unter einem entsprechenden Server sicher nicht viel schlechter als Applikationen in anderen Sprachen, u.U. aber sogar bedeutend besser ist. Aber wie bei jeder Programmiersprache gilt auch hier: Wenn ein Programm schlecht geschrieben ist, ist egal, welche Sprache benutz wird - die Performance wird dann immer nicht sonderlich berauschend sein.

Zusammenfassung

Welche Sprache soll man nun wählen?

Wie immer, liegt der Teufel im Detail. Zu Erledigung temporärer Aufgaben (Hotfix) ist ein Perl, PhP, oder Shell-Skript sicherlich etwas schneller gehackt, als eine entsprechende Java-Applikation und ist sicher auch kein Problem, solange es nicht dauerhaft eingesetzt werden soll und nur Standard-Bibliotheken/Module der jeweiligen Sprache benutzt.

Anderenfalls, d.h. zur Lösung relativ komplexer bzw. sehr häufig anfallenden Aufgaben (z.B. Session-Management, Accounting, nicht-triviale Datenverarbeitung, Datenbank-Nutzung, etc.) sollte man definitiv Java den Vorzug geben, zumal - wenn clever geschrieben - Komponenten nicht nur in Webserver-Applikationen sondern auch in Client- und/oder Standalone-Applikationen weitergenutzt werden können.