Thema der Woche/

Der schlanke Client auf dem Weg zum fetten Browser

13.09.1996

"Jeder Client wird ein Browser sein", lautet der Schlachtruf von Internet- und Intranet-Anhängern. Das schlanke Front-end beschränkt sich nach dieser Vorstellung auf Funktionen der Benutzerschnittstelle, die Applikationen sollen zurück ins Netz. Am Client gibt es somit nichts mehr zu konfigurieren und zu installieren, Software-Updates erfolgen am Server. Als Zusatznutzen ergibt sich besserer Schutz vor Viren und vor schädlichen Programmen, die herkömmliche Client-PCs beeinträchtigen können. Obendrein ist die HTML-Programmierung ziemlich einfach und für alle Betriebssysteme einheitlich.

Soweit die ursprüngliche Vision. Die Parole vom schlanken Client verliert mittlerweile an Gültigkeit. Web-Browser entwickeln sich rasant von plattformunabhängigen HTML-Interpretern zu eigenen Anwendungsplattformen, die sich dabei in immer tiefere Abhängigkeit vom zugrundeliegenden Betriebssystem verstricken. Mit der Ausführung von Applikationen, die aus dem Netz heruntergeladen werden, steigen nun auch wieder die Sicherheitsrisiken. HTML selbst wandelt sich von einer Auszeichnungssprache für hierarchisch organisierte Texte zu einer "Ressource Definition Language", die Komponenten verschiedener Herkunft zu Desktop-Anwendungen zusammenfaßt.

Mit der Integration von Javas virtueller Maschine in den "Navigator" setzte Netscape den ersten Schritt in Richtung Anwendungsplattform. Die betriebssystemunabhängigen Java-Applets sollen Web-Anwendungen um Funktionen ergänzen, die bloßes HTML nicht anbieten kann. Sie reichen von Netzwerkdiensten über Eingabevalidierung für Datenbanken bis zu Browser-basierten Büroanwendungen. Der bis dato übliche Einsatz von Applets verdammt sie allerdings zum Dasein als Einzelgänger: Auch wenn mehrere von ihnen mit einer HTML-Seite heruntergeladen werden, so laufen sie dann doch unvermittelt nebeneinander ab.

Mit dem Erfolg von Java wachsen nun die Anstrengungen der Hersteller, Applets in ihr Komponentenmodell einzubinden. Ziel ist es, vor allem Intranet-Entwicklern die Möglichkeit zu geben, komplexe Anwendungen aus untereinander kommunizierenden, arbeitsteiligen Java-Applets zusammenzufügen.

Netscape stellte im Rahmen der Strategie "Open Network Environment" (ONE) das Desktop-basierte Komponentenmodell "Live-Connect" vor, das die Integration von Java-Applets, HTML-Formularen und Plug-in-Modulen mit Java Script erlaubt. Die Technologie ist Teil des Navigators 3.0 auf allen unterstützten Plattformen.

Microsofts Java-Implementierung sieht vor, die Programmiersprache zur Erstellung von Active-X-Komponenten heranzuziehen. Entsprechend bewertet man in Redmond Java nicht als Konkurrenz zu Active X, sondern als Ergänzung. Solche Applets laufen zwar auch auf jedem System ab, das über einen Java-Interpreter verfügt, setzen aber zusätzlich Microsofts proprietäres "Component Objects Model" (COM) voraus, auf dem auch OLE aufsetzt. Dieses existiert bis dato nur unter Windows.

Sun begegnete Microsofts Umklammerungsversuchen mit der "Java-Beans"-Initiative, die ein eigenes Komponentenmodell für Java definiert. Die dafür erforderlichen Programmierschnittstellen werden in Java geschrieben und sind daher auf allen Plattformen verfügbar, auf denen Java läuft. Es sieht zudem Brücken zu COM, Opendoc und Netscapes Live-Connect vor, so daß Java-Applets sich wie originäre Objekte dieser Umgebungen verhalten können.

Offenheit adieu

Der Streit zwischen den Internet-Kontrahenten Netscape und Microsoft geht nach den anfänglichen HTML-Querelen nun um den Typ von Applikationen, die innerhalb eines Browsers ablaufen sollen. Offene Standards sind dabei nicht nur durch Microsofts Ambitionen bedroht, proprietäre Windows-Technologie um jeden Preis ins Internet zu bringen. Der Zwang, Browser als Anwendungsplattform attraktiv zu machen, veranlaßt auch die Befürworter offener Standards, sich auf die Möglichkeiten des Hostbetriebssystems einzulassen. Der Grund dafür liegt in den Beschränkungen, die plattformunabhängige Technologien wie HTML und Java im Vergleich zu etablierten GUIs zur Zeit noch aufweisen.

Im Fall von Java bemängeln Entwickler vor allem die Beschränkungen des "Abstract Windowing Toolkit", dessen Methoden Java-Applets zur Bildschirmdarstellung nutzen. Es kennt nur wenige Schriftarten, die Steuerelemente beispielsweise für Benutzerdialoge sind begrenzt. Weitere Einschränkungen für Java-Applets entspringen deren Sicherheitskonzept. Der Browser stellt für sie eine isolierte Umgebung dar, die ihnen den Zugriff auf das Dateisystem des Hostrechners verwehrt. Beispielsweise ist das lokale Speichern und Drukken von Dateien in diesem Sandbox-Modell nicht vorgesehen.

Sun verspricht bereits in der Version 1.1 des Java Developer Kits einen deutlichen Fortschritt bei der grafischen Darstellung. Das Update soll gegen Ende des Jahres verfügbar sein. Net- scape bietet derweil mit seinen "Internet Foundation Classes" eine Sammlung von Java-Klassen an, die unter anderem die GUI-Möglichkeiten verbessern sollen (Unterstützung für Drag and drop, komplexe Steuerelemente wie Auswahlboxen für Farben und Schriften, Darstellung von Texten, die mehrere Schriftarten und Grafiken beinhalten). Weitere Hersteller wie Silicon Graphics, Macromedia und Adobe arbeiten ebenfalls an Java-Klassen zur Darstellung von 2D- und 3D-Objekten sowie von Animationen.

Als zusätzliche Möglichkeit lassen aber beide Hersteller zu, daß auf der Clientseite Programmcode der jeweiligen Betriebssysteme ins Spiel kommt. So sieht Java die Einbindung von "native methods" vor: Es handelt sich dabei um Programmteile, die mit anderen Programmiersprachen für ein bestimmtes Betriebssystem entwickelt wurden. Es liegt auf der Hand, daß eine solche Java-Anwendung dann nicht mehr auf anderen Systemen ablaufen kann.

Noch größere Konzessionen an die Client-Plattform macht Net- scape mit seinem Plug-in-API für Erweiterungsmodule. Bei den Plug-ins handelt es sich beispielsweise um Windows-Programme, die sich nahtlos in den Navigator einfügen und diesen um zusätzliche Funktionen bereichern. Net- scape bezeichnete die Plug-in-Architektur in der Vergangenheit stets als Zugeständnis an Legacy-Anwendungen. Beispielsweise gibt es eine Reihe von Modulen zur Darstellung proprietärer Dateiformate wie Adobes PDF oder für jene von Microsofts Office-Anwendungen. Andererseits wirbt Netscape auf seiner Web-Seite damit, daß mittlerweile mehr als 130 Hersteller Plug-in-Komponenten für den Navigator anbieten. Der überwiegende Teil dieser Programme läuft ausschließlich unter Windows. Web-Angebote, die diese Zusatzfunktionen voraussetzen, bleiben Anwendern anderer Betriebssysteme unzugänglich. Die großzügige Verwendung solcher Zusatzmodule droht zudem einen Vorteil von Intranets zunichte zu machen, indem sie den Wartungsaufwand auf der Clientseite in die Höhe treiben. Systemverwalter dürfen sich dann wieder darum kümmern, daß diese PC-Programme überall installiert, ob sie in der richtigen Version und auch für den Macintosh verfügbar sind.

Proprietäre Falle "Captive X"?

Da Netscape aber auf offene Standards baut, bieten Plug-ins nur eine Option zur Verwendung von plattformabhängigen Codes - die Anwender bei der Einrichtung von Intranets ausschlagen sollten.

Demgegenüber kommt Microsoft als dominierender Anbieter von PC-Betriebssystemen, bedingt durch seine Interessenlage, erst gar nicht in die Verlegenheit, sich um Plattformunabhängigkeit von Web-basierten Anwendungen kümmern zu müssen. Als Internet-Spätzünder ist die Gates-Company vielmehr entschlossen, den Wintel-Rechner als unverzichtbaren Bestandteil des Internets durchzuboxen.

Eine besondere Bedeutung bei diesen Bestrebungen kommt Active X zu. Bei Programmen, die sich nach Microsofts Konzept vom Netz herunterladen und innerhalb des Browsers ausführen lassen, handelt es sich neben Java-Applets um sogenannte Active-X-Controls. Technisch gesehen "kann sich im Grunde jedes OLE-Control auch ein Active-X-Control nennen" (Microsoft-Broschüre "Jetzt kommt Schwung ins Internet!").

Dies ist sicher eine erfreuliche Nachricht für Windows-Entwickler, die ihre bestehenden Komponenten ohne großen Aufwand ins Internet bringen wollen.

Für das Herunterladen, Installieren und Ausführen von Active-X-Controls bemüht der Active-X-fähige Browser eine ganze Reihe von Windows-Systemfunktionen. Beispielsweise prüft die API-Funktion "CoGetClassObjectFromURL" vor dem Download einer Anwendung in der Windows-Registrierdatenbank anhand der Klassen-ID (CLSID), ob die betreffende Komponente auf dem Rechner schon installiert ist und ob sie in der richtigen Version vorliegt.

Der Installationsvorgang über das Netz gleicht dann jenem von anderen Medien. Der Programmcode kommt entweder in Form einer Windows-EXE- oder -CAB-Datei. Letztere ist ein komprimiertes Archiv, das auch das Installationsprogramm von Windows 95 nutzt. Die Anleitung für das Installationsprogramm muß, wie schon unter Windows 3.0, in einer Klartextdatei mit der Endung INF erfolgen. (Siehe dazu "Microsoft Systems Journal", Juli 1996, S. 65 ff.)

Da Active-X-Controls vollwertige Windows-Programme sind, teilen sie deren Vor- und Nachteile: Als OLE-fähige Anwendungen können sie über Visual-Basic-Skripts gesteuert und zu komplexeren Applikationen zusammengefaßt werden. Außerdem steht ihnen der volle Funktionsumfang des Betriebssystems zur Verfügung. Andererseits perpetuieren sie den von Windows her gewohnten Betreuungsaufwand. Fehlende oder beschädigte Komponenten, lädierte Registrierdatenbanken oder Versionskonflikte werden ihre Ausführung wohl häufig scheitern lassen. Benutzerdialoge wie "Eine neuere Version der Komponente xy in englischer Sprache ist bereits installiert. Soll sie durch eine ältere in deutscher Sprache überschrieben werden?" begleiten den Anwender auch in Zukunft.

Derzeit gibt es Active X nur unter 32-Bit-Windows Microsoft kündigte dazu Versionen für den Macintosh und Unix an. Unklar ist noch das Schicksal der Windows-3.1-Anwender. Microsoft stellt eine Active-X-System für die 16-Bit-Plattform in Aussicht, hat sich aber bisher noch nicht offiziell festgelegt. Da es sich bei Active-X-Komponenten (OCXe) um 32-Bit-Code handelt, wäre die Unterstützung für das 16-Bit-Windows mit erheblichem Aufwand verbunden. Neben einer Überarbeitung des COM-Subsystems müssen die Microsoft-Programmierer auch eine Active-X-fähige virtuelle Java-Maschine implementieren. Einen "gewöhnlichen" Java-Interpreter wird es allerdings schon vorher geben: Die IBM wird einen solchen für die 16-Bit-Version des Microsoft-Systems in Kürze fertigstellen.

Sollte die Active-X-Unterstützung für mehrere Plattformen Realität werden, so stellt sie einen Web-Anbieter vor zusätzliche Aufgaben. Da jedes Modul Binärcode für die jeweilige Zielplattform ist, muß er für jedes Betriebssystem ein eigenes Active-X-Control auf Lager halten. Bewahren könnten ihn davor nur Entwickler, die keine geeigneten OLE-Werkzeuge für Unix finden können.

Die enge Verzahnung des Browsers mit dem darunterliegenden Betriebssystem droht zwei wesentliche Vorteile des Intranets zu eliminieren: Plattformunabhängigkeit und nahezu wartungsfreie Clients. Gegenüber den bloßen HTML-Darstellern bringen die neuen Anwendungsplattformen vor allem aber neue Sicherheitsrisiken mit sich.

Während Java-Applets innerhalb des Browsers rigiden Sicherheitsmaßnahmen unterworfen sind, haben Plug-ins und Active-X-Controls freie Fahrt beim Beschädigen und Ausspionieren fremder Daten.

Microsoft will solchen Problemen vorbeugen, indem es die elektronische Distribution von Software nach dem Muster des herkömmlichen Vertriebs organisieren will. Während bisher das Hersteller-Logo auf der Verpakkung den Käufer davon überzeugte, daß das Produkt aus einer seriösen Quelle stammt, kommt diese Rolle zukünftig elektronischen Signaturen zu. Die Verschlüsselung der Signatur garantiert, daß am Produkt nicht manipuliert werden kann. Ein weltumspannendes Netz von autorisierten Stellen soll Entwicklern individuelle Zertifikate ausstellen.

Nach dem Herunterladen eines Active-X-Controls überprüft der Internet-Explorer unter Verwendung der WinVerifyTrust-API, ob am Code manipuliert wurde, und stellt fest, woher er stammt. Wurde die Quelle der Software vom Anwender schon vorher als vertrauenswürdig eingestuft, so ist dies in einer Datenbank des Windows-Rechners vermerkt. Das Programm wird dann ausgeführt. Ist der Hersteller noch nicht als vertrauenswürdig registriert, überläßt der Browser dem Anwender die Wahl. Der darf dann entscheiden, ob er die Software von Joe Smith aus Salt Lake City starten will.

Bei entsprechender Verbreitung von Active-X-Controls ist zu befürchten, daß viele Anwender die Warnfunktion des Browser abschalten, damit sie nicht laufend von Nag-Screens behelligt werden. Ein unfreundliches, wenn auch harmloses Active-X-Control namens "Exploder" kann unter http://www.halcyon.com/mclain/ ActiveX schon begutachtet werden. Seine Funktion besteht darin, den Windows-95-Rechner herunterzufahren.

Ausblicke

Es ist nur konsequent, wenn Microsoft unter dem Codenamen "Nashville" die Web-Browser-Funktionen direkt in die Windows-Oberfläche integriert. Der Internet-Explorer spielt bei Active-X schon jetzt nur mehr eine Mittlerrolle für das Herunterladen und Installieren von Windows-Programmen. Diese selbst laufen direkt unter der Kontrolle des Betriebssystems ab. Aus der Sicht der Benutzerführung ist dabei ein Stand-alone-Browser eher hinderlich. Wenn Microsoft am Ziel ist, dann endet die Reise in die Internet-Zukunft in der Gegenwart des Windows-PCs. Und der Weg zu kostengünstigen, wartungsfreien Alternativen wie dem Network-Computer ist verbaut, sobald ein Intranet massiv von Active-X-Controls Gebrauch macht.

Netscape auf der anderen Seite verfolgt mehrere Strategien. Vorerst will die Internet-Company an der Stand-alone-Version des Navigators festhalten. Als 17. der unterstützten Plattformen kommt nach einer Übereinkunft mit IBM OS/2 hinzu.

Gleichzeitig beabsichtigt die Mannschaft um Andreessen und Clark, Microsofts Browser-Integration in das Betriebssystem Paroli zu bieten. Nach Netscapes Plänen soll dem Navigator eine Zukunft als eigenständiges Betriebssystem für Netzwerk-Computer und andere Internet-Endgeräte bevorstehen. Daneben soll es inoffiziellen Angaben zufolge die nächste Version des Browsers zusätzlich in einer modularisierten Form geben. Der in Teilkomponenten zerschlagene Navigator könnte sich dann als Sammlung von OLE-Controls oder Opendoc-Parts ebenfalls nahtlos in die Benutzerschnittstelle des Hostbetriebssystem einfügen.

Angeklickt

Java, Plug-in-Module und Active-X-Komponenten erweitern die modernen Browser um neue Funktionalität. Gleichzeitig bedeuten sie eine Einschränkung für die Systemunabhängigkeit und bringen neue Sicherheitsrisiken. Microsoft befindet sich auf dem Weg zur proprietären Windows-Erweiterung Netscape ist wohl eher dabei, sein eigenes Betriebssystem zu etablieren.