Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.05.1997 - 

Groupware versus Intranet/Die Zukunft von Lotus Domino

Gemischte Lösungen mit beliebigen Clients sind künftig das A und O

Ein kurzer Rückblick in die Vergangenheit von Lotus Domino, vormals Notes Server, hilft, die neuesten Entwicklungen einzuordnen. Bis zur Version 3.x war Lotus Notes nur über eine Formelsprache, deren Wurzeln auf Lotus Symphony zurückgehen, zu programmieren. An den Grenzen dieser Sprache angelangt, mußte der Entwickler auf ein Notes-C-API-Toolkit ausweichen, mit dem sich Notes-Funktionen auf sehr niedrigem Abstraktionsniveau nutzen lassen.

Erst die 1996 vorgestellte Version Notes 4 erhielt mit Lotusscript eine leistungsfähige Skript-Sprache, die eng an Visual Basic angelehnt ist. Durch sie lassen sich Programme an Ereignisse in Notes Datenbanken, -ansichten und -formularen ankoppeln. So kann das Öffnen eines Formulars oder das Drücken einer Schaltfläche ein Lotusscript-Programm anstoßen. Anders als die bisherige Formelsprache verfügt Lotusscript über Schleifenkonstrukte und Routinen zur Fehlerbehandlung.

Darüber hinaus kann man mit Lotusscript Agenten entwickeln, die nicht an die Notes-Oberfläche gebunden sind, sondern sich zeitgesteuert oder durch andere Ereignisse, etwa dem Eintreffen einer Mail, aktivieren lassen. Solche Agenten laufen typischerweise auf einem Domino-Server und können zum Beispiel in Abwesenheit des Benutzers Mails beantworten, weiterleiten oder Workflows steuern.

Die Programmiersprache selbst ist nur ein Vehikel, mit dem der Entwickler Zugriff auf das Notes Object Interface (NOI) erhält (siehe Abbildung 1). Dieses NOI exponiert zwei Klassenhierarchien: die von Jen Kidder entwickelten Front-end-Classes und die Back-end-Classes von Bob Balaban. Erstere enthalten Objekte der Notes-Client-Oberfläche, während Letztere den Zugriff auf alle anderen Notes-Komponenten steuern.

Agenten, die auf der Benutzerschnittstelle von Notes laufen, können sowohl Front-end- als auch Back-end-Classes nutzen. Serverbasierte Agenten dagegen haben keine sichtbaren Komponenten und basieren deshalb vollständig auf Back-end-Classes.

Unter Notes entwickelte Client-Server-Anwendungen können auf die Fähigkeiten eines "dicken" Notes-Client vertrauen. Diese Funktionalität steht bei einem Web-Browser, ob Netscape Navigator oder Microsoft Internet Explorer, nicht zur Verfügung. Diese können weder Lotusscript noch das NOI nutzen.

Um einem normalen Browser einen großen Teil der Notes-Funktionalität zu verleihen, hat Lotus den Domino-Server mit einem HTTP-Server versehen, der selbst unmittelbar auf Notes aufsetzt (siehe Abbildung 2). Anders als ein gewöhnlicher Web-Server liefert er nicht nur statische HTML-Seiten aus dem Dateisystem, sondern baut diese Seiten dynamisch zusammen. So lassen sich Notes-Datenbanken mit eingebetteten Lotusscript-Agenten nutzen, sofern diese ausschließlich auf Back-end-Classes basieren, die auf dem Server ausgeführt werden können. Hier steht die gesamte Funktionalität bereit, die etwa die Zugriffsrechte eines Benutzers prüft und nur die zulässigen Informationen überträgt.

Auf diese Weise entstehen sehr einfach Anwendungen. Ein Besucher meldet sich zunächst bei einem Web-Server an, um dort seinen Benutzernamen und ein Kennwort zu registrieren. Der mittlerweile nicht mehr anonyme Besucher kann jetzt halböffentliche, das heißt eine Anmeldung voraussetzende Bereiche des Servers nutzen. Wenn der Benutzer nach einer entsprechenden Verifizierung durch den Betreiber des Servers mit weitreichenderen Zugriffsrechten ausgestattet wird, paßt sich das Informationsangebot, das der Besucher wahrnimmt, automatisch diesen Autorisierungen an.

Diese durchaus beachtliche Leistung bedarf jedoch einiger wichtiger Verbesserungsmöglichkeiten. Alles, was der Benutzer auf dem Browser-Bildschirm angezeigt bekommt, muß zuvor vom Domino-Server aufbereitet und an den Benutzer über das Netz geschickt werden. Es gibt keinerlei lokale Verarbeitung. Eine Gliederungsansicht, die man in einem Notes-Client einfach und schnell expandieren und kollabieren kann, wird bei einem Browser komplett auf dem Server bearbeitet. Bei jedem Mausklick schickt der Browser einen Request an den Server. Der stellt daraufhin eine neue HTML-Seite zusammen und überträgt sie per HTTP an den Browser.

Derzeit arbeiten die Entwickler daran, einzelne Front-end-Classes nach Java zu portieren. Die eben genannten Gliederungsansichten lassen sich auf diese Weise lokal im Kontext des Browsers ausführen. Domino würde das Applet und die Daten liefern, während der Browser respektive das Java Applet lokal die Anzeige der Gliederung übernimmt. Wenn genügend Front-end-Classes in Java implementiert sind, kann man auch einen vollständigen Mail-Client in einem Browser-Kontext darstellen. Ein entsprechendes Produkt, "Lotus Mail Client for Java", hat Lotus bereits im Januar auf der Lotusphere angekündigt.

Auch wenn sich auf diese Weise ein Browser Zug um Zug zu einem vollwertigen Client ausbauen läßt, bietet Java darüber hinaus noch viel größere Chancen. Aufgabe ist es, das gesamte NOI für Java zu exponieren, so daß man eigenständige Java-Applikationen schreiben kann, die sowohl auf einem Client als auch in Zusammenarbeit mit einem Domino-Server auf Notes-Dienste zugreifen können. Dieses Ziel will Lotus noch dieses Jahr in zwei Schritten erreichen. Ein Teil der Funktionalität wird bereits im Domino 4.7 Release Mitte des Jahres angeboten und mit dem Release 5.0 Ende des Jahres vollendet. In Domino 4.7 wird Lotus die Back-end-Classes für Java exponieren. Ein Java-Programm kann damit direkt auf einem Domino-Server ablaufen. Auch wenn das Programm grundsätzlich auf einem Stand-alone-Java-Interpreter läuft, kann man es auch in eine Notes-Datenbank aufnehmen und dort wie Lotusscript-Agenten anwenden.

Während bei Domino 4.7 nur lokale Java-Applikationen im Einsatz sind, wird Domino 5.0 auch Java Applets unterstützen, die über das Netz zum entfernten Rechner übertragen werden und von dort aus über eine Remote-Schnittstelle mit dem Server kommunizieren.

Diese Java-Applets kann der Domino-Server dynamisch in HTML-Dokumente einbetten und per HTTP an den Browser schicken und dort ausführen lassen. Auf diese Weise entsteht aus dem vergleichsweise einfachen Browser ein leistungsfähiger Client. Dabei verspricht Java eine vollständig plattformunabhängige Implementierung.

Interessanterweise geht Lotus hier einen ganz anderen Weg als etwa Netscape, dessen Entwickler den Client mit immer größerer plattformspezifischer Funktionalität aufblasen. Aus dem ehemals schlanken Browser wird durch die zusätzlichen Anwendungsprogramme für Mail, News, Conferencing, Collaboration eine konstant wachsende Programmsammlung. Lotus dagegen versucht im Moment, den ebenfalls recht dicken Notes-Client durch Java-Lösungen substituierbar zu machen.

Die Verbindung zwischen den Front-end- und Back-end-Classes und der Sprache Lotusscript wird durch sogenannte Lotusscript Extensions (LSX) hergestellt (siehe Abbildung 3). Die Classes selbst sind in C++ entwickelt und exponieren über LSX eine Lotusscript-Schnittstelle. Mit einem Java-Adapter, der vergleichsweise einfach zu implementieren ist, macht Lotus die selben Classes für Java zugänglich.

Wenn man diese Classes jedoch über das Netz einem entfernten Java-Applet bereitstellen will, benötigt man einen Kommunika- tionsmechanismus. Lotus hat sich hier für die von der Object Management (OMG) vorgeschlagene Corba-Lösung (Common Object Request Broker Architecture) entschieden. Corba ist kein Produkt, sondern eine Architektur, die von mehr als 600 Herstellern, darunter IBM, Netscape und Lotus, getragen wird. Microsoft möchte diesem Standard mit einer eigenen Lösung namens DCOM entgegentreten.

Für unterschiedliche Programmiersprachen

Eine Corba-Client-Server-Anwendung besteht aus mindestens zwei ORBs (Object Request Broker) und einem Kommunikationsprotokoll, mit dessen Hilfe die beiden ORBs Informationen austauschen. Der Client-ORB und der Server-ORB benutzen dabei die gleiche Schnittstellendefinition, die in der Sprache IDL (Interface Definition Language) beschrieben wird. Client und Server können nun verschiedene Programmiersprachen haben. Ein sogenannter Emitter erzeugt aus der IDL-Spezifikation eine sprachspezifische Schnittstellenspezifikation und die Bindung an die Objektklassen.

Weil Lotus die Notes-Objekte weiterhin in C++ entwickeln will, bildet man aus den IDL-Definitionen C++ Code-Rahmen, die mit dem vorhandenen Code aufgefüllt werden. Auf diese Weise entsteht ein Corba-kompatibler Object Request Broker, der sich von jedem anderen ORB aus ansprechen läßt.

Wenn Lotus die IDL-Definitionen publiziert, kann man daraus eigene Code-Rahmen in der gewünschten Programmiersprache für die entsprechende Hardware- und Softwareplattform erzeugen und diese mit eigenem Code füllen. Für Java erübrigt sich sogar dieser Schritt, da die passenden Java-Stubs gleich von Lotus mitgeliefert werden.

Auf Protokolle und Standards kommt es an

Die Kommunikation zwischen Client-ORB und Domino, das bereits einen Corba-konformen ORB enthält, findet über das standardisierte IIOP (Internet Inter-Orb Protocol) auf der Basis von TCP/IP statt. Der Client-ORB kann auf jeder beliebigen Plattform laufen und muß, falls er in Java geschrieben ist, nur einmal entwickelt werden. Mit dieser Konstruktion öffnet Lotus den Domino-Server und mittels Back-end-Classes alle Notes- Objekte beliebigen Internet- Clients.

Welche Front-end-Classes dabei als Java-Applets bereitgestellt werden, ist relativ unwichtig, weil die gleiche Funktionalität bereits heute auf beinahe allen Plattformen als Notes-Client verfügbar ist. Sie erleichtert allenfalls die Entwicklung leistungsfähiger Java-Clients.

Sehr wichtig ist dagegen, daß Lotus an die vorhandene Technik nun immer mehr Protokolle anbindet, die gemischte Lösungen mit beliebigen Clients erlauben. Protokolle und Standards - darauf kommt es wirklich an.

Angeklickt

Um einem normalen Browser große Teile der Notes-Funktionalität zu liefern, hat Lotus den Domino-Server mit einem HTTP-Server versehen, der unmittelbar auf Notes aufsetzt. Doch die Erweiterung von Domino als Web-Server war nur der Anfang. Bis zum Jahresende soll Notes mit Java programmierbar sein und einen Corbakonformen Object Request Broker erhalten.

*Volker Weber ist freier Journalist in Darmstadt.