2.3 Programmierung/Entwicklungsumgebung

	Sign In Sign-Up

2.3 Programmierung/Entwicklungsumgebung

Die von den Gateway-Herstellern zur Verfügung gestellten Programmierschnittstellen für die Entwicklung von Web-Datenbank-Anwendungen sind sehr unterschiedlich. Wichtige Kriterien für die Beurteilung der Programmierschnittstellen sind

Flexibilität und Funktionsumfang
Komplexität und Lernaufwand
Benötigte Kenntnisse/Programmiererfahrung des Anwendungsentwicklers (HTML-Autor vs. Systemprogrammierer)
Produktspezifische Sprache oder Ableitung/Portierung existierender Programmiersprachen
Proprietäre Umgebung oder Unterstützung offener Standards
Debugging-Möglichkeiten
Unterstützung für "Rapid Application Development" durch Visuelle Tools, Wizards, Beispielanwendungen, etc.
Entwicklersupport durch Hersteller und/oder Internetgemeinde (Newsgroups, Mailinglisten, Web-Sites)

2.3.1 Hohe Programmiersprachen vs. Scriptsprachen

Die Entwicklung einer Web-Datenbank-Anwendung von Grund auf in einer Programmiersprache wie C/C++, Visual Basic und auch Java halte ich aus folgenden Gründen in den meisten Fällen für nicht sinnvoll:

Lange Entwicklungszeiten
Trotz des Einsatzes eventuell vorhandener (Klassen-) Bibliotheken ist die Programmierung grundlegender Gatewayfunktionalitäten aufwendig und langwierig. Vergleiche hierzu auch Abschnitt 2.1.1, 3. Absatz zur Trennung von Gateway und Anwendung. JDBC beispielsweise stellt eine Java-API für Datenbankoperationen auf niedriger Ebene dar (vgl. JDBC-API-Dokumentation unter [W13], html-0120/packages.html), die hinsichtlich Einfachheit nicht mit typischen Scriptkonstrukten zu vergleichen ist.
Außerdem mangelt es den meisten Programmiersprachen (von Java einmal abgesehen) aufgrund ihrer geschichtlichen Entwicklung an der speziellen Ausrichtung auf die Webumgebung.
Extrem kurze Produktlebenszyklen
Wegen der enormen Dynamik des Internets durch ständig neue technische Entwicklungen, Benutzerbedürfnisse und inhaltliche Angebote verkürzen sich die Lebenszyklen von Webanwendungen nochmals deutlich gegenüber "herkömmlicher" Software, so daß Anpassungen und Erweiterungen noch einfacher und schneller realisierbar sein müssen.
Komplexität der Anwendung
In vielen Anwendungsfällen geht es einfach um das Verfügbarmachen vorhandener Datenbestände über das WWW, ohne das über die Datenabfrage mit SQL hinausgehende komplexe Programmlogik erforderlich ist. Speziell in solchen Fällen steht der Einsatz hoher Programmiersprachen nicht im Verhältnis zur Einfachheit einer Skriptsprache.
Verfügbarkeit und Performance von Gateways
Es sind heute bereits für die meisten Betriebssystemplattformen, Web-Server und Datenbanksysteme Web-Datenbank-Gateways verfügbar, so daß nur in sehr speziellen Hard- und/oder Softwareumgebungen nichtvorhandene Gateways eine Eigenentwicklung von Grund auf nötig machen.
Das Argument, ein Gateway verlangsamt durch eine zusätzliche Softwareschicht die Web-Datenbank-Anwendung, relativiert sich bereits, wenn man bei der Auswahl des Gateways und dessen zugrundeliegender Architektur entsprechende Sorgfalt walten läßt (vgl. Abschnitt 2.1). Außerdem ist die Performance einer Web-Datenbank-Anwendung von so vielen Faktoren abhängig, daß man sich fragen muß, wie gravierend dieser eine Aspekt ist unter Berücksichtigung des zusätzlichen Aufwands durch eine komplette Eigenentwicklung. Und drittens stellt sich für mich die Frage, ob ein Entwickler einer Web-Datenbank-Anwendung neben der Erstellung seiner eigentlichen Anwendung noch ebensoviel Zeit und Knowhow in die Optimierung der grundlegenden Kommunikationsfunktionen investiert bzw. investieren kann, wie ein Spezialist, der ausschließlich mit der Entwicklung und Optimierung von Gateways beschäftigt ist.

Es gibt noch weitere Argumente für den Einsatz von Scriptsprachen für Web-Datenbank-Anwendungen: Gerade für einfache Aufgaben bedarf es nicht der Einarbeitung in eine neue Programmierumgebung, da die Script-Befehle wie normale Tags in die HTML-Seite integrierte werden und somit ein gewöhnlicher Texteditor ausreicht.

Für umfangreiche Web-Projekte ist es denkbar, die HTML-Seiten selbst in einer Datenbank statt im Dateisystem zu verwalten. Auch in diesem Zusammenhang ist die textorientierte Struktur von Skriptsprachen und ihre Integration in die HTML-Seiten ein Vorteil gegenüber compilierten Sprachen.

2.3.2 Proprietäres Server Side Scripting

Beim Server Side Scripting (SSS) werden Kommandos für die Datenbankzugriffe mit speziellen, nichtstandardisierten HTML-Tags in die HTML-Seite integriert. Solche erweiterten HTML-Seiten werden nach einer Anfrage zunächst von einem Gateway geparst, welches die Datenbankbefehle interpretiert, ausführt und die Ergebnisdaten an Stelle dieser Tags in die HTML-Seite einsetzt. Die so manipulierte Seite wird an den Server zurückgegeben, der sie an den anfragenden Browser liefert. Dieser erhält somit von spezifischen Tags bereinigten Standard-HTML-Code.

So erweiterte HTML-Seiten werden oft auch als "Templates" bezeichnet, da sie neben normalem HTML-Code Platzhalter beinhalten, die beim Aufruf dieser Seite durch Daten aus der Datenbank ersetzt werden.

Um dafür zu sorgen, daß ein solches Template vor Auslieferung durch den Web-Server von dem Gateway geparst wird, werden zwei unterschiedliche Methoden verwendet:

Template-Dateien erhalten eine spezielle Endung, beispielsweise .htx statt .htm/.html und der Web-Server wird so konfiguriert, daß beim Aufruf solcher Dateien das entsprechende Gatewayprogramm aufgerufen wird.
Templates werden in einem URL nicht direkt adressiert. Stattdessen wird das Gateway aufgerufen und die gewünschte Templatedatei als Parameter übergeben.

SSS ist die am häufigsten verwendete Methode zur Programmierung von Web-Datenbank-Gateways. Der Sprachumfang dieser Skriptsprachen reicht vom reinen Einfügen von SQL-Abfragen, die beim Seitenaufruf durch entsprechende Ergebnistabellen ersetzt werden, bis zu vollwertigen Programmiersprachen mit Funktionen, Variablen und Objektbasierung. Manche Hersteller integrieren außerdem noch Email-Schnittstellen und ähnliche Erweiterungen zur Erstellung "stark interaktiver" Webanwendungen.

Vorteile

einfache, für HTML-Autoren gewohnte Programmierung durch Einfügen der Befehle als spezielle Tags in die HTML-Seiten bzw. -Templates
kein überflüssiger "Know-How-Overhead" für einfache Aufgaben durch komplexe Konzepte wie Objektorientierung

Nachteile

jede proprietäre Skriptsprache hat ihren eigenen Befehlssatz und ihre eigene Syntax, die in jedem Fall neu erlernt werden muß
für komplexere Aufgaben oft Beschränkungen durch mangelnde Programmierlogik und Ablaufsteuerung (Bedingungen, Schleifen, Funktionen)
oft keine Debugging-Möglichkeit

2.3.3 JavaScript

JavaScript ist eine objektbasierte Skriptsprache, deren Sourcecode ebenfalls in HTML-Seiten integriert ist und nach Aufruf dieser Seite entweder auf dem Server oder erst auf dem Client (Web-Browser) von einem Interpreter ausgeführt wird.

2.3.3.1 JavaScript auf Clientseite

JavaScript wurde von Netscape und Sun Microsystems entwickelt und war zunächst "nur" für die einfache Gestaltung dynamischer HTML-Seiten gedacht. Der JavaScript-Interpreter ist im Web-Browser integriert. JavaScript hat vordefinierte Objekte mit Attributen und/oder Methoden u.a. für Strings, mathematische Operationen, alle HTML-Elemente, insbesondere die Formularelemente, sowie für Frames und Windows des Browsers. Diese Objekte können durch zusätzliche Methoden und Attribute erweitert werden und es können neue Objekte definiert werden. Objekte können Attribute anderer Objekte sein ("Has a"-Beziehung). Vererbung ("Is a"-Beziehung) wird allerdings nicht unterstützt, weshalb JavaScript auch nicht objektorientiert, sondern eine objektbasierte Sprache genannt wird ([L5], S. 58).

Klassische Einsatzgebiete von JavaScript auf Clientseite sind Berechnungen mit Benutzereingaben aus Formularen oder die Clientseitige Validierung von Formulareingaben für die Verarbeitung auf dem Server.

Beispiel

Für einen Veranstaltungskalender sollen die Benutzer Terminvorschläge machen können. Ein Formular nimmt die Daten entgegen und ein CGI-Programm erzeugt daraus eine Email, die an den Webmaster geschickt wird.

Ohne JavaScript gibt es bei Einsatz eines fertigen CGI-Programms zum Verschicken von Formulareingaben per Email keine Möglichkeit, Datumseingaben des Benutzers auf Gültigkeit zu Prüfen. Stattdessen muß ein neues CGI-Programm geschrieben werden, welches die Plausibilitätsüberprüfung durchführt und die Email-Funktionalität beinhaltet. Neben dem zusätzlichen Programmieraufwand läßt sich folgendes Problem nicht lösen: Benutzereingaben werden auf jeden Fall zunächst an den Server übertragen. Dort findet die Validierung der Daten statt. Im Falle eines Fehlers muß eine neue HTML-Seite mit einer entsprechenden Fehlermeldung an den Browser zurückgeliefert werden und der Benutzer muß seine Eingaben wiederholen oder korrigieren. Nachdem die Korrekturen gemacht wurden, werden wiederum sämtliche Eingaben an den Server übertragen und hier wieder geprüft.

Mit JavaScript kann die Validierung der Daten auf Clientseite erfolgen, so daß der Benutzer ggf. direkt eine Fehlermeldung in Form einer Alertbox erhält und seine Korrekturen machen kann, bevor die Daten an den Server übertragen werden. Dies hat mehrere Vorteile:

Reduzierte Netzbelastung und schnellere Bearbeitung
Benutzereingaben werden in jedem Fall nur einmal vom Browser zum Server übertragen. Es müssen keine zusätzlichen HTML-Seiten für Fehlermeldungen übertragen werden.
Geringerer Programmieraufwand
Beim Server kommen bereits überprüfte Daten an, so daß in obigem Beispiel ein Standard-Email-CGI-Programm verwendet werden kann.
Mehr Benutzerfreundlichkeit
Neben der wesentlich schnelleren Bearbeitung (prompte Fehlermeldungen statt warten auf eine neue HTML-Seite) ist mit JavaScript durch Interaktionen zwischen einzelnen Formularelementen sowie mit Browserfunktionen und den Möglichkeiten einer kompletten Programmiersprache die Erstellung sehr benutzerfreundlicher und interaktiver GUIs möglich.

JavaScript wurde speziell für das Internet entwickelt und ist - ähnlich wie Java - ein offener Standard, der von mehreren Herstellern unterstützt wird. So hat Microsoft beispielsweise JavaScript unter dem Namen JScript in den Internet Explorer ab Version 3.0 integriert. Dadurch hebt sich JavaScript grundsätzlich von allen proprietären Skriptsprachen ab, ist aber dennoch wesentlich einfacher zu lernen als Java oder andere hohe Programmiersprachen.

2.3.3.2 JavaScript auf Serverseite

Die Entwicklung, JavaScript auch auf Serverseite einzusetzen, ist relativ neu. Ziel ist es, mit einfachen, aber zugleich mächtigen Mitteln Datenbankbasierte interaktive Webanwendungen schreiben zu können. JavaScript für Serverseitige Ausführung wird ebenfalls in HTML-Seiten integriert und durch Einschluß in die HTML-Tags <SERVER> ... </SERVER> entsprechend markiert. Es gibt zusätzliche Objekte für den Server und für Datenbankzugriffe.

Vorteile

Einfachheit durch Konzept des Server Side Scripting
Verwendung einer bekannten, offenen Scriptsprache
Eine Programmiersprache für Server- und Clientseitige Programmierung
Flexibilität durch Programmlogik einer objektbasierten Programmiersprache

Nachteile

JavaScript auf Clientseite ist (noch) nicht in jedem Web-Browser integriert, manche Implementierungen weisen geringe Inkompatibilitäten bei speziellen Funktionen auf
JavaScript auf Serverseite ist noch nicht standardisiert

Zur Zeit gibt es zwei nichtkompatible Produkte zur Ausführung von JavaScript-Programmen auf Serverseite:

Netscape hat einen JavaScript-Interpreter als NSAPI-Modul in seine aktuellen Web-Server Enterprise Server und Fast Track Server ab Version 2.0 integriert.
IntraBuilder von Borland ist ein eigener Server, der parallel zum Web-Server läuft und via NSAPI, ISAPI oder CGI mit fast jedem Web-Server zusammenarbeitet.

Die Netscape-Lösung wird ausführlich in Abschnitt 3.3 behandelt. Borland hat JavaScript für den Serverseitigen Einsatz mit IntraBuilder um Objekte zur Datenbankentwicklung sowie um objektorientierte Konzepte wie formaler Klassendefinition und Vererbung erweitert, mit der Syntax von Java. Abbildung 11 zeigt die Multi-Tier-Architektur des IntraBuilder-Servers.

Abbildung 11: Architektur des IntraBuilder-Servers

IntraBuilder enthält ein umfangreiches RAD-Tool zur Erstellung und Pflege von Datenbankbasierten HTML-Formularen und -Reports sowie Borlands bereits aus Delphi, C++, Paradox und dBase her bekannte "Borland Database Engine" (BDE) zur Anbindung einer Vielzahl von Datenbank (ODBC sowie nativ IBM DB2, Oracle, Sybase, Informix, MS SQL Server u.a.).

Der große Nachteil von IntraBuilder ist, daß er im Gegensatz zum Netscape-Server nur auf Windowsplattformen (95/NT) verfügbar ist.

Ich halte JavaScript als Programmiersprache für die Entwicklung von Web-Datenbank-Anwendungen für einen gelungenen Kompromiß zwischen Einfachheit und Flexibilität. Trotz gewisser Kinderkrankheiten liefert JavaScript aufgrund seiner ausschließlichen Weborientierung und der Möglichkeit, in einer Programmiersprache auf Client- und Serverseite zu entwickeln, interessante Ansätze.