Diskussionen zu Entwicklungs-Tools verstummen langsam. Nicht zuletzt aus Angst, etwas zu verpassen, ist es den Unternehmen derzeit offenbar wichtiger, möglichst schnell über Webanwendungen zu verfügen. Während von den zur Verfügung stehenden Programmiersprachen Java mit Abstand die meisten Vorteile bietet, dominieren bei den Entwicklungstools solche, mit denen man in kurzer Zeit "Quick-&-dirty"-Anwendungen erstellen kann, wie beispielsweise "Cold Fusion" oder "Silver Stream". Die damit erzielten Ergebnisse sind jedoch vom heute technisch Machbaren weit entfernt. Es gibt nur wenige Web-Tools, die Konzepte wie OOP (objektorientiertes Programmieren) oder diverse Locking-Modelle in Datenbanksystemen unterstützen.
Im Grunde genommen haben Entwickler vieles von dem, was sie in den frühen Neunzigern - den goldenen Jahren der Client/Server-Ära - gelernt haben, wieder über Bord geworfen. Dennoch kommen sie beispielsweise bei der Erstellung von Online-Buchungssystemen nicht umhin, ausgereifte Locking-Techniken einzusetzen. Webapplikationen müssen besonders anspruchsvollen Anforderungen ge-recht werden. Kunden können an jeder beliebigen Stelle einer Transaktion einfach den Browser schließen und so unter Umständen aktive Datenbankprozesse mit Locks zurücklassen.
Sind derartige Anwendungen nicht sauber geplant und realisiert, führt das schnell zu Komplikationen, wenn beispielsweise bei einer Flug-buchung ein freier Sitzplatz als reserviert angezeigt wird. Das ließ sich in der ersten Phase des Web-Computing nicht umgehen, denn damals wollten die Programmierer nur die Möglichkeiten des neuen Mediums ausloten.
Diese Phase ist mittlerweile jedoch abgeschlossen, und die grundlegenden Entwicklungslinien des Web sind klar. Die Anforderungen an heutiges E-Business lassen sich - zumindest in Umrissen - ausmachen. In Zukunft kommen strategische Webanwendungen nicht mehr mit einer optisch ansprechenden Oberfläche aus. Vielmehr müssen sie in die Unternehmensanwendungen integriert werden, transaktionsorientiert sein und stabil laufen. Hier versagen die meisten Web-Tools: Auf Datenbanken greifen sie nur über die Standardschnittstelle ODBC (Open Data-base Connectivity) zu, und mit OOP können sie genauso wenig anfangen wie mit Microsofts DNA-Architekturen.
Rückkehr zu professionellen Methoden
Folglich werden in Zukunft Programmierer von Webanwendungen zu professionellen Werkzeugen zurückkehren. Themen wie Objektorientierung, Skalierbarkeit, Komponentenarchitektur und 4GL (4th Generation Language) werden innerhalb des vom Web vorgegebenen Rahmens wieder stärker in den Vordergrund rücken.
In der Client-Server-Ära waren die Diskussionen um die Möglichkeiten und Grenzen der Programmiersprachen der vierten Generation im Grunde genommen schon beendet - durch den Aufstieg von Java kamen nun ganz andere Gesichtspunkte zum Vorschein. Die 4GLs, die eigentlich längst mehr als reine "Programmiersprachen" - nämlich umfassende Entwicklungssysteme - waren, hatten sich als der produktivere Weg zu fertigen Applikationen bewährt. Lediglich systemnahe Aufgaben wurden noch mit Assemblern angegangen.
Bei den neuen Webanwendungen lief ihnen jedoch die "3rd Generation Language" (3GL) Java den Rang ab. Zu dieser Zeit verfügten die Entwickler noch nicht über webtaugliche Werkzeuge, die vorhandenen Tools waren noch ganz auf klassisches Client-Server-Computing ausgerichtet. Sie lieferten keine Browser-fähige Präsentationsschicht und waren nicht in der Lage, mehrschichtige Architekturen - wie sie für das Web unerlässlich sind - zu unterstützen.
Diese Lücken haben die 4GLs mittlerweile geschlossen, sodass sich die alte Frage neu stellt: 3GL oder 4GL? Suns Java besteht im Grunde nur aus Programmierhandbuch und Compiler. Mit dieser Kombination kann ein fähiger Entwickler alles machen - sofern ihm genügend Mannjahre zur Verfügung stehen, denn auch in der Webwelt bedeutet 3GL-Entwicklung einen hohen Auf-wand, und gerade hier ist Zeit knapp, und Fachleute sind rar.
Mit 4GL-Entwicklungsumgebungen wie Centuras "Team Developer", Compuwares "Uniface", Oracles "De-veloper 2000" oder Sybases "Power Builder" müssen sich Program-grammierer nicht mehr so intensiv mit systemnahen Vorgängen befassen - im Gegensatz zu den 3GLs wie Borlands "Delphi", C/C++ oder Microsofts "Visual Basic". Bei Ersteren sind Entwickler von der Aufgabe entbunden, Speicherplatz für Programme und Daten beim Betriebssystem explizit anzufordern und zu reservieren. Außerdem vereinfacht eine 4GL die Charakterisierung von Datentypen. Doch führt dies in einigen Fällen zu Performance-Einbußen. 4GLs suchen solche Nachteile durch spezielle Compiler wettzumachen. Wer jedoch leistungsfähige Anwendungen benötigt, wird die entsprechenden Routinen an eine 3GL auslagern und anschließend (compiliert) in das Projekt einbinden. Die meisten 4GLs unterstützen ein derartiges Vorgehen.
Anders als bei den Client/Server-4GLs sind diese Integrationsmechanismen heute viel wichtiger als die Nähe zu den Betriebssystem-Diensten. Ohne aufwändige Programmierung können Entwickler mit COM- und DCOM-Technologien auch systemnahe Services in 4GL-Anwendungen einbauen. Hier haben Fortschritte in der Systemarchitektur eines der wesentlichen Argumente für den Einsatz von 3GLs weitgehend obsolet werden lassen. Im Gegenteil: Manche 4GL-Systeme binden COM- und DCOM-Objekte effizienter ein. Auch die Einbindung von DLL-Komponenten oder die Verwendung nativer API-Funktionen des Windows-Systems stellen keine Probleme mehr dar. 4GL-Anwendungen haben in der Praxis längst die Flexibilität der 3GL-Programme übertroffen.
Kommerzielle Anwendungen arbeiten mehrheitlich mit Datenbanken. Daher ist deren Anbindung an Datenbanken unterschiedlicher Her-steller ein weiteres entscheidendes Kriterium - nicht nur für die Wahl des Entwicklungssystems, sondern generell auch der verwendeten Entwicklungs-Philosophie. Professionelle 4GLs verfügen über native Schnittstellen zu allen gängigen Datenbanken und können diese ohne Programmieraufwand integrieren. Das funktioniert tatsächlich einfach per Mausklick. Verbindungsaufbau, Zugriff und Updates lassen sich bei 4GLs fertig in eine Applikation einfügen, den restlichen Code bringen die Komponenten im Hintergrund mit.
Wer viel Zeit hat, kann das ohne Zweifel auch mit Java direkt programmieren. Aber die sich derzeit abzeichnende Krise der Java-Projekte geht nicht zuletzt darauf zurück, dass selbst Routineaufgaben wie der Datenbankzugriff einen enormen Entwicklungsaufwand er-fordern. Viele Probleme sind daraus entstanden, dass man Java - in Ermangelung anderer Werkzeuge für die Entwicklung von Webanwendungen - für Dinge verwendet hat, für die diese Sprache eigentlich gar nicht konzipiert wurde. Davon abgesehen zählt sie natürlich zu den grundlegenden Technologien des Web.
Mit Java, die viele Ähnlichkeiten zu C++ aufweist, wollte Sun eine universelle Programmiersprache für alle Betriebssysteme und Browser entwickeln. Eine große Anzahl von Plattformen baut auf Java auf, wobei die darin integrierten Tools lediglich Klassenbibliotheken darstellen, die das Entwickeln mit Java beschleunigen sollen. Die Vorteile von Java sind die Multiplatt-formstrategie und deren Integration in den Webbrowser.
Das Manko bleibt die Performance, denn Java arbeitet mit einem Laufzeitinterpreter, was nicht nur die Ausführung bremst, sondern auch zu den bekannten langen Ladezeiten führt. Der Einsatz komplexer Businessanwendungen über Java und Webbrowser ist damit heutzutage fast unmöglich. Das ist der Grund, warum der Java-Hype deutlich nachgelassen hat.
Es zeichnet sich immer mehr ab, dass Java mehr eine Backend-Sprache ist, mit der Geschäftsprozesse für leistungsfähige Unix-Systemen modelliert werden können. In diesem Umfeld werden sich langfristig die auf Java basierenden Entwicklungssysteme positionieren. Andere Tools dieser Gruppe sind Prosysts "Enterprise Beans Developer" oder Beas "Weblogic". Da neu-ere 4Gls über DCOM auch Java Komponenten integrieren können, ist der Weg über spezielle Java-Tools allerdings nicht mehr entscheidend - die Anwendung kann sich an anderen Kriterien orientieren.
Komponentenarchitektur unter Windows DNA
Windows-DNA-basierende Anwendungen zeigen gegenüber Java-Lösungen bessere Performance. Im Gegensatz zu Java-Server-Applikationen verwendet Windows DNA für COM-Objekte Maschinencode. Auf gleicher Hardware können so unter Windows 2000 mehr COM-Prozesse als Java-Server-Anwendungen laufen. Unter Windows 2000 ist die Skalierbarkeit weit nach oben gewandert.
Skalierbarkeit und Portabilität sind eng verbunden. In einer mehrschichtigen Architektur müssen Transaktionen oder Datenbankzugriffe unter hoher Last auf andere Plattformen migrieren können, bei-spielsweise auf Unix. Ob unter einer derartig extremen Beanspruchung Java- oder ein Posix-kompatibler C/C++-Code (Portable Ope-rating System Interface for Unix) die geeignetere Lösung darstellt, soll hier offen bleiben. Alternativen sind vorhanden.
Wichtiger als Performance, Ska-lierbarkeit oder Portabilität dürften aber die Größe des Markts für Webanwendungen, die Vertrautheit der Anwender mit Windows-Applikationen und die Vielzahl von Produkten im Umfeld sein. Mehr als alle technischen Argumente machen diese Faktoren DNA für professionelle Entwickler und Systemhäuser interessant.
Martin Teetz ist Business-Development-Manager bei Gupta Technologies in München.