Auf dem typischen Arbeitsplatzrechner von heute befindet sich nur mehr eine Hand voll Programme. Dazu zählen normalerweise die gängigen Anwendungen aus den Office-Paketen inklusive eines Mail-Client, gelegentlich kommen noch vertikale und Individuallösungen älteren Datums hinzu. Die große Masse der Software ist indes zum Web-Browser abgewandert. Seien es betriebswirtschaftliche Applikationen oder CRM, Lösungen für Business Intelligence, Content- oder Projekt-Management - praktisch alle namhaften Hersteller bieten ein Web-Frontend für ihre Programme an.
Der Erfolg des Browsers als universeller Client lässt sich einfach begründen: Unternehmen können mit dem Web-Anwendungsmodell die Kosten für die PC-Administration erheblich senken. Verantwortlich dafür ist ein denkbar unkomplizierter Distributionsmechanismus für Software: URL eintippen, und die aktuelle Version einer Anwendung steht sofort auf jedem Arbeitsplatz zur Verfügung. Im Idealfall funktioniert das auch plattformunabhängig, so dass Programme ohne Anpassungs- und Portierungsaufwand unter allen Betriebssystemen genutzt werden können. Die Bequemlichkeit hat jedoch ihren Preis. Browser-Anwendungen bieten weit weniger Benutzerkomfort als traditionelle PC-Software, das Programmiermodell ist inkonsistent und ein Offline-Arbeiten nicht möglich.
Daher gab es immer wieder Versuche, den Verteilungsmechanismus des Web mit den Vorzügen klassischer Desktop-Anwendungen zu kombinieren. Darunter fielen etwa Microsofts Vorstoß mit Active X oder die Anläufe diverser Hersteller mit Office-Programmen in Java. Das Active-X-Modell scheiterte jedoch an Sicherheitsproblemen, die Java-Ansätze an der damals noch unausgereiften Plattform und der geringen PC-Rechenleistung.
Mit IBM und Microsoft versuchen nun erneut zwei Schwergewichte der Softwareindustrie, ein solches Vorhaben umzusetzen. Big Blue propagiert zu diesem Zweck seine "Workplace Client Technology", während Microsoft auf .NET und wesentliche Neuerungen von "Windows Longhorn" baut. Trotz ihres grundsätzlich gleichen Anliegens unterscheiden sich beide Vorhaben in wesentlichen Aspekten.
Rückkehr des Desktop-Java
Eine Differenz besteht darin, dass IBMs neues Client-Konzept auf Java beruht, während Microsoft seiner eigenen Technik treu bleibt. Allerdings geht es Big Blue nicht bloß darum, Java-Anwendungen zu entwickeln, die dann als Applets oder mittels "Java Web Start" auf den Client heruntergeladen werden. Vielmehr erhebt das Unternehmen den Anspruch, mit dem Workplace Client das Konzept der Middleware vom Server auf den Client zu übertragen. Genau genommen trifft diese Charakterisierung auf Java selbst auch schon zu, weil es durchgängig eigene Programmierschnittstellen definiert und eine Ablaufumgebung zwischen Anwendung und Betriebssystem schiebt.
IBMs neue Client-Infrastruktur geht jedoch darüber hinaus. Sie enthält eine relationale Datenbank, einen Replikationsmechanismus, einen lokalen Applikations-Server sowie eigene Funktionen zur Softwareverteilung. Die eigentliche Basis bildet ein Framework, das der Open-Source-Entwicklungsumgebung "Eclipse" entnommen wurde. Beim Datenspeicher handelt es sich um "Cloudscape", der mit Informix an die IBM gelangte, und von der Tochter Tivoli stammen Funktionen für die Zugriffskontrolle. Die Erstinstallation erfolgt durch Aufruf einer Web-Seite, anschließend versorgt sich die Software selbstständig mit den neuesten Updates. Deshalb sprechen Firmenvertreter nicht nur von einem "Rich Client", sondern auch von einem "Managed Client".
Ein wesentliches Charakteristikum der Workplace-Technik besteht darin, dass sie das Portalparadigma auf den Desktop bringt. Entwickler schreiben daher für IBMs Client-Middleware keine allein stehenden Anwendungen, die ein gesamtes Fenster ausfüllen. Vielmehr fügen sie sich als Komponenten zusammen mit anderen Applikationen in eine gemeinsame Oberfläche, wie es von Browser-basierenden Portalen her bekannt ist. Aus diesem Grund bezeichnete die IBM ihren Workplace-Client bei der ersten Ankündigung auf der diesjährigen Lotusphere als Client-seitiges Portal-Framework. Als solches ist es nicht für sich alleine nutzbar, sondern bedarf des "Websphere Portal Server" als Backend. Mittelfristiges Ziel der IBM ist es, über eine zentrale Konfiguration auf dem Server identisch aufgebaute Portaloberflächen für den Browser und den Workplace-Client anzubieten. Anwender sollen zudem mit dem "Workplace Builder" ein Werkzeug bekommen, das beide Frontends aus vorgefertigten
Bausteinen zusammenstellen kann.
Momentan scheitert die parallele Nutzung von zwei Client-Typen schon daran, dass zwar zahlreiche Portlets für Browser-Oberflächen existieren, die neue Client-Plattform hingegen mit bloß zwei Anwendungen freigegeben wird. Dies sind "Lotus Workplace Messaging" und die Dokumenten-Management-Lösung "Lotus Workplace Documents". Bei Ersterem handelt es sich um eine Anwendung für Mail, Kalender, Aufgaben und Instant Messaging, die auf Basis von Websphere und DB2 entwickelt wurde und im Lauf der Zeit Lotus Notes ablösen soll. Die IBM will nach und nach Client-Module für weitere Applikationen aus dem Lotus-Portfolio nachreichen, darunter das "Workplace Web Content Management" und "Workplace Team Collaboration".
Entscheidend für den Erfolg der Client-Infrastruktur wird jedoch sein, ob sich weitere Hersteller finden, die dafür entwickeln wollen. Für das Browser-basierende Portal entsteht relativ rasch ein eigener Markt für Java-Portlets, da mit dem JSR 168 ein herstellerübergreifender Standard existiert. Der Websphere-Server unterstützt ihn seit der Version 5. Die Rich-Client-Plattform hingegen definiert ein eigenes Programmiermodell, bei dem das Plugin-API von Eclipse eine zentrale Rolle spielt. Für die Entwicklung grafischer Oberflächen legte sich die IBM auf das "Standard Widget Toolkit" fest, statt auf den Java-Standard "Swing" zurückzugreifen. Gleich auf Anhieb kündigten Adobe, Peoplesoft und Siebel ihre Unterstützung an, mittlerweile folgten auch Cisco und
PalmOne. Momentan ist der Workplace-Client allerdings noch nicht als Teil eines Software Development Kit (SDK) verfügbar, sondern wird vorerst nur mit den beiden Lotus-Anwendungen ausgeliefert.
Entwertung von Windows
Das Workplace-Framework fungiert als eine Abstraktionsschicht über dem Betriebssystem und erbringt Dienste, die teilweise schon von der darunter liegenden Plattform angeboten werden. So verfügt etwa Windows mit den Server-gestützten Profilen über einen Replikationsmechanismus, der Dateien aus den Benutzerverzeichnissen mit dem Server abgleicht. Der wird vom Workplace-Client aber nicht benötigt, da dessen Datenbank diese Funktion selbst beherrscht. Dank des eigenen Datenspeichers umgeht die neue Middleware auch das lokale Dateisystem. Entsprechendes gilt für die Windows-eigenen Funktionen zur Softwareverteilung, Rechteverwaltung, Verschlüsselung von Dateien und Anwendungskonfiguration.
Dieser Ansatz gewährleistet die Plattformunabhängigkeit des Workplace-Client. Er liegt derzeit in Versionen für Windows und Linux vor und soll später auch auf dem Mac verfügbar sein. Das Middleware-Konzept beschränkt den Einsatz der Client-Technologie allerdings nicht auf Desktop-Systeme, sondern erlaubt auch Anwendungen, die zusätzlich auf mobilen Endgeräten ablaufen. Zur Unterstützung von PDAs oder Smartphones kündigte die IBM eine eigene Ausgabe ihres Client-Frameworks an, das auf den Namen "Workplace Client Technology Micro Edition" hört und bereits die Versionsnummer 5.7 trägt. Es enthält zudem leichtgewichtige Versionen von Server- und Desktop-Produkten, etwa DB2e, MQe oder "Embedded Via Voice".
Besonders unter Windows möchte die IBM dafür sorgen, dass mit der Workplace-Technik kein isolierter Parallel-Desktop entsteht. Das gebietet zum einen schon die Portalphilosophie, weil sich Anwendungen nicht nur unter einer Oberfläche zusammenfinden, sondern auch miteinander kooperieren sollen. Darüber hinaus wäre es angesichts der Marktdominanz von Microsoft Office nicht möglich, die allgegenwärtige Bürosoftware aus der Client-Infrastruktur auszugrenzen. Die IBM bietet daher mehrere Integrationsoptionen für bestehende Anwendungen. Dazu zählt die Implementierung eines WebDAV-Servers auf dem Client, so dass alle Anwendungen, die mit so genannten Web-Ordnern zurechtkommen, direkt in die Workplace-Datenbank schreiben können.
Bei der Einbindung traditioneller PC-Programme kommt den Dokumenten-Management-Komponenten eine zentrale Aufgabe zu. Da sie keine Workplace-Bausteine sind, können sie sich nicht in die portalartige Oberfläche einfügen. Die Integration erfolgt dort auf der Ebene der Daten, die allesamt im lokalen Speicher hinterlegt und dann ins Backend repliziert werden können. Workplace Documents bietet dort die typischen Management-Funktionen, von der Versionierung über Workflow und Zugriffskontrolle bis zur Bestimmung von Aufbewahrungsfristen mit Hilfe des separat zu kaufenden "Records Manager". Die Komponente für das Dokumenten-Management verschafft Anwendern zudem eine schlanke Alternative zu Office-Applikationen. Sie können nicht nur die Dateiformate der Microsoft-Boliden lesen und schreiben, sondern verstehen auch die XML-basierenden Speicherstrukturen von Open Office. Zu den integrierten
Autorenwerkzeugen gehören eine Textverarbeitung, eine Tabellenkalkulation und ein Programm für Präsentationen.
|
Die Grenzen des Browsers Die Verfechter von Rich Clients bringen folgende Kritikpunkte gegen Web-Frontends vor: Die Möglichkeiten von HTML und Javascript beim Aufbau ansprechender Benutzeroberflächen sind dürftig. Auch geringfügige Eingaben des Benutzers erfordern in der Regel die Kommunikation mit dem Server und den Neuaufbau der ganzen Seite. Ein Arbeiten ohne Netzverbindung ist im Allgemeinen nicht möglich. Im Vergleich zu den objektorientierten Programmiermodellen in Java und .NET sind Anwendungen für den Browser schlecht strukturiert und schwer zu warten. Aufgrund abweichender Implementierungen von Standards durch die Browser-Hersteller hapert es oft mit der versprochenen Plattformunabhängigkeit. |
Microsofts "Smart Client"
Der Windows-Hersteller wehrte sich stets gegen Anwendungsmodelle, die am Client eine Middleware-Schicht über das Betriebssystem legen. Die Marktmacht eines Plattformanbieters hängt schließlich davon ab, dass möglichst viele Applikationen seine APIs direkt nutzen. Eine solche Abstraktionsschicht stellt auch der Web-Browser dar, der ein eigenes und systemübergreifendes Programmiermodell etablierte. Microsofts massives Auftreten gegen Netscape entsprang daher der Befürchtung, dass Windows durch das HTML-Frontend obsolet würde. Ähnlich motiviert war der Kampf gegen Java.
Mittlerweile verfolgt Microsoft mit dem .NET-Framework selbst ein Java-ähnliches Anwendungskonzept. Ein wesentlicher Antrieb dafür waren die kaum lösbaren Sicherheitsprobleme bei nativen Windows-Anwendungen sowie generelle Beschränkungen des Desktop-Modells in einer vernetzten Welt. Seit der Verfügbarkeit von .NET propagiert Microsoft unter dem Begriff des "Smart Client" einen Ansatz, der ebenfalls die Vorteile der Web-Architektur mit jenen einer traditionellen Windows-Anwendung verbinden soll.
Zu diesem Zweck verfügt das .NET-Framework über einen Mechanismus, der mit Java Web Start vergleichbar ist und dafür sorgt, dass Updates von Programmkomponenten automatisch vom Server nachgeladen werden. Vereinfacht wird dieses Verfahren dadurch, dass das .NET-Format für ausführbaren Code ("Assemblies") keine Installation nach altem Muster erfordert. Nicht mehr erforderlich sind etwa Einträge in die Registrierdatenbank, zudem entschärft ein eigenes Versionierungssystem die unter Windows bekannten Probleme der "DLL Hell". Die Version 2.0 des .NET-Frameworks, das Anfang nächsten Jahres verfügbar sein soll, verfeinert den Update-Mechanismus. Er firmiert zukünftig unter der Bezeichnung "Click Once" und bietet unter anderem eine bessere Desktop-Integration sowie die Möglichkeit des Roll Back auf ältere Versionen.
Für die "reichere Benutzererfahrung", die solche Smart Clients von einer Browser-Anwendung unterscheiden sollen, sind die "Windows Forms" zuständig. Sie versammeln eine große Auswahl an Bildschirmelementen, wie sie von klassischen Windows-Programmen her bekannt sind. Die Windows Forms repräsentieren das Gegenstück zu IBMs "Standard Widget Toolkit" (SWT) und werden in der nächsten Ausführung des .NET-Frameworks weiter ausgebaut. So soll etwa die Unterstützung für Windows Themes hinzukommen. Nachdem die neue Client-Generation im Gegensatz zum Browser auch das Arbeiten im Offline-Modus erlauben soll, muss sie Daten zumindest lokal zwischenspeichern können. Dafür steht unter .NET zwar keine Datenbank wie IBMs Cloudscape zur Verfügung, aber ADO.NET ist mittlerweile viel mehr als eine einheitliche Technik für den Datenbankzugriff. Sie kann Datensätze in einem Cache vorhalten und sie bei der Rückkehr ins Netzwerk mit einem Datenbank-Server
abgleichen.
Microsofts Konzept des smarten Client soll mit Windows Longhorn einen weiteren wichtigen Schritt vorankommen. Grafische Oberflächen können dann deklarativ mit XAML programmiert werden, in einer von Microsoft definierten und auf XML beruhenden Markup-Sprache für Benutzerschnittstellen. Sie repräsentiert auf diese Weise eine Alternative zu HTML und wird von der neuen Grafik-Engine "Avalon" ausgeführt. Die Kombination aus einer Auszeichnungssprache, die auch Web-Designer einsetzen können, einer sicheren Ausführungsumgebung wie .NET und Microsofts Marktmacht hat in der Open-Source-Welt bereits für Beunruhigung gesorgt. So warnte der Ximian-Begründer Miguel de Icaza davor, dass Redmond damit die Zukunft von Linux am Desktop verbauen könne.
In Bezug auf die lokale Datenhaltung sollte Longhorn mit dem neuen Dateisystem "WinFS" ebenfalls große Fortschritte machen. Aber gerade dort kündigte Microsoft in letzter Zeit Abstriche an, die besonders eine unternehmensweite Verteilung von Informationen behindern werden.
Fazit
Auch wenn die beiden IT-Riesen IBM und Microsoft die Vorzüge des Web und des Desktops kombinieren wollen, so unterscheiden sich ihre Konzepte doch erheblich. Das beginnt damit, dass Big Blue auf Java setzt, während Bill Gates seinem Windows/.NET treu bleibt. Wichtiger ist jedoch, dass die IBM eine Client-seitige Infrastruktur schafft, die dem Portalparadigma folgt. Dieses bestimmt zunehmend den Unternehmens-Desktop. Lotus-Chef Ambuj Goyal machte auf der Launch-Veranstaltung in München unmissverständlich klar, dass der IBM Workplace tatsächlich nur für den Arbeitsplatz und nicht für Privatanwender gedacht ist. Eine derartige Aussage schien ihm wohl nötig, nachdem reißerische Schlagzeilen von einem Angriff der IBM auf das Windows-Monopol gekündet hatten.
Microsofts Smart Client repräsentiert hingegen ein allgemeineres Anwendungsmodell für Windows/.NET, das sich nicht nur auf die firmeninterne Nutzung beschränken soll. Dabei ist die Verlagerung von mehr Anwendungslogik auf den Client durchaus vorgesehen. Nur so lässt sich erklären, dass Web-Services als Mechanismus propagiert werden, um mit Server-Anwendungen zu kommunizieren. Technisch ist dazu auch der Workplace-Client in der Lage, allerdings spielt sich die Anwendungsintegration in der IBM-Welt mehr auf dem Server ab.
Bei allen Differenzen ist beiden Herstellern jedoch eines gemeinsam: Sie stehen mit der Umsetzung ihrer Rich-Client-Konzepte noch ganz am Anfang. Bis zu einer erfolgreichen Verbreitung dieser Modelle dürften noch Jahre ins Land gehen.