Die Web-Architektur bietet ein Modell für dreistufige Anwendungen ("three-tier") an, bei der ein Browser stets als Front-end dient, der Web-Server inklusive Erweiterungsprogrammen die Applikationslogik repräsentiert und schließlich ein Datenbank-Server als Back-end fungiert. Dieses Modell verlagert die Anwendungs- und Datenlast weg von den Clients und hin zu den Servern (entsprechend der Parole "thin clients, fat servers"). Als Hauptvorteil dieser Ausrichtung versprechen Befürworter eine erhebliche Reduktion der hohen Unterhaltskosten für PCs.
Diese Drei-Schichten-Architektur, bei der Web-Browser via HTTP-Protokoll Daten mit Web-Servern austauschen und wo Web-Server ihrerseits über das Common Gateway Interface (CGI) oder proprietäre Schnittstellen wie ISAPI und Netscapes Server-Plug-in-API mit Applikationen kommunizieren, wird allerdings schon obsolet, bevor sie sich richtig etablieren konnte. Zwar erscheinen nach und nach komfortable Entwicklungswerkzeuge für diese Konstellation, wie beispielsweise Borlands "Intrabuilder" und "Web Objects" von Next. Für interne Applikationen, etwa auf Abteilungsebene, bieten sie schon heute klare Vorteile gegenüber der traditionellen Windows-Programmierung. Die Nachteile von HTTP als zustandloses Protokoll, das nach jeder Datenübertragung die Verbindung trennt, (siehe CW Nr. 35 vom 30. August 1996, Seite 21) und die Beschränkungen des CGI veranlassen jedoch Hersteller, alternative Lösungen zu suchen.
Einen wesentlichen Schritt weg von dem anfänglichen Modell tun die Anbieter von Web-Browsern, indem sie die Web-Front-ends von bloßen HTML-Interpretern zu Plattformen für Client-seitig ausgeführte Applets transformieren. Neben Browser-eigenen Scripting-Möglichkeiten helfen diese Anwendungen, die Defizite von HTML bei der Entwicklung von Benutzer-Schnittstellen zu beseitigen. Zusätzlich sind diese im Browser ablaufenden Programme in der Lage, unter Umgehung von HTTP direkte, leistungsfähige Verbindungen mit Applikations-Servern aufzunehmen. Ein Vorteil dieses Verfahrens besteht darin, daß solche Applets Daten innerhalb einer Web-Page aktualisieren können, ohne gleich die ganze Seite neu laden zu müssen - wie dies heute bei HTML-Formularen üblich ist.
Für Client-seitig ausgeführten Code hat sich Java zweifellos bereits einen festen Platz gesichert. Microsoft versucht, auch dafür seine OLE-Technologie (mit Hilfe der Marketing-Initiative Active X) zu etablieren. Es besteht damit allerdings die Gefahr, daß durch die enge Bindung von Active X an Windows ein Vorteil des Web, nämlich die Plattformunabhängigkeit, verlorengeht.
Für Programme, die am Client ablaufen, wollen die Mächtigen der IT-Industrie in nächster Zeit Komponentenmodelle durchsetzen. Es geht dabei um eine Infrastruktur, die es erlaubt, heruntergeladene Minianwendungen zu Applikationen zu kombinieren. Gleichzeitig soll sie die Kommunikation von lokal ausgeführtem Code mit Objekten erlauben, die potentiell weltweit verteilt sind.
Im Prinzip setzt sich bei der Etablierung von Komponentenmodellen für das Internet die alte Rivalität zwischen der Common Object Request Broker Architecture (Corba) und Microsofts Component Object Model (COM) fort. Suns "Javabeans" nimmt dabei zumindest für Java eine Vermittlerposition ein, da es Applets in andere Architekturen wie "Opendoc", Netscapes "Live-Connect" oder eben COM einbinden kann.
Letzteres ist auf die Kommunikation von Desktop-Anwendungen beschränkt. Entsprechend funktioniert es nur für Anwendungen, die gemeinsam auf dem gleichen Client-PC ablaufen. Für verteilte Objekte sieht Microsoft Distributed COM (DCOM) vor, das der Softwarehersteller in einer ersten Implementierung mit Windows NT 4.0 ausliefert.
Weiter fortgeschritten ist die Entwicklung auf seiten des offenen Corba-Standards, wo mehrere Hersteller schon Produkte vorzuweisen haben. Einige von ihnen können mit Object Request Brokern (ORB) aufwarten, die in Java geschrieben wurden und damit innerhalb von Browsern ablaufen können. Sie sind in der Lage, beispielsweise Java-Applets mit Corba-kompatiblen Objekten zu verbinden.
Sun bietet ein solches Produkt unter der Bezeichnung "JOE" (Java Objects Everywhere) an, das die Kommunikation mit Applikationen ermöglicht, die auf Grundlage der hauseigenen Corba-Implementierung "Network Enterprise Objects" (NEO) entwickelt wurden. Konkurrenz erhält der Workstation-Hersteller von Visigenic, das mit "Black Widow" ebenso einen vollständig in Java programmierten ORB vorweisen kann wie Iona mit "Orbix Web". Letzteres ist in der Version 2.0 zudem in der Lage, jedes Endgerät mit Server-Funktionen zu versehen. Client-Daten können so von einer zentralen Applikation aus abgerufen werden.
Für die schnelle, bidirektionale Verbindung von Corba-kompatiblen Objekten erhob die Object Management Group (OMG) das Internet Inter-ORB Protocol (IIOP) zum Standard. Netscape wird dieses voraussichtlich schon in der nächsten Version des Browsers (namens "Communicator") und in den Server-Produkten des Suitespot-Pakets unterstützen. Zusätzlich will die Internet-Company den ORB von Visigenic in ihre nächste Produktgeneration einbauen, die Anfang 1997 auf den Markt kommen soll. Sie bietet damit anderen Herstellern objektbasierte Schnittstellen an. Hewlett-Packard will diese nutzen und Netscapes Server über IIOP an das System-Management-Produkt "Openview" anbinden.
Web-Server verlieren an Bedeutung
Unerläßlich für verteilte, unternehmenskritische Anwendungen ist, daß sie robuste Technologien für Transaktionen nutzen können. Zur direkten Verbindung von Corba-Objekten mit OLTP-Systemen definierte die Object Management Group einen neuen Dienst namens "Object Transaction Service" (OTS). Auch bei dessen Umsetzung will Netscape eine Vorreiterrolle spielen und ihn in der zweiten Hälfte 1997 in die Version 4.0 von Suitespot integrieren.
Die Perspektive verteilter Objekte impliziert den Wandel des Internet/Intranet von einer dokumenten- zu einer applikationszentrierten Umgebung. Entsprechend prophezeit eine Studie von Input, daß Suchmaschinen künftig in der Lage sein werden, nicht bloß Texte, sondern auch Softwarekomponenten auszuforschen.
Die Veränderung der Anwendungsplattform Intranet hat natürlich auch Konsequenzen für Web-Server. Ihre Funktionen werden zunehmend in Betriebssysteme, aber auch in Applikations-Server integriert. Freilich wird sich ihre Bedeutung erheblich vermindern, da sich ihr Einsatz hauptsächlich auf den Publishing-Bereich und das Herunterladen von Scripts reduziert. Während beim derzeitigen Applikationsmodell, das auf HTTP und CGI beruht, alle Daten aus HTML-Eingabeformularen den Weg über den Web-Server zu den dahinterliegenden Anwendungen nehmen müssen, bleibt dieser bei einer direkten Kommunikation verteilter Objekte außen vor. Es liegt auf der Hand, daß der Bedarf für CGI und proprietäre Web-Server-APIs abnehmen wird.