Zu den Überraschungen der diesjährigen Lotusphere gehörte zweifellos die Ankündigung von Lotus-Chef Al Zollar, dass der Nachfolger von Notes/Domino 6 auf der Java 2 Enterprise Edition (J2EE) und relationaler Datenbanktechnologie basieren werde. Viele Konferenzteilnehmer schlossen daraus irrtümlich, dass die Funktionen des Domino-Servers auf Grundlage des IBM-Applikations-Servers "Websphere" und der Datenbank "DB2" neu geschrieben würden. Diese Auslegung kam freilich nicht von ungefähr, weil Beobachter schon länger eine grundlegende Erneuerung des Notes-Programmiermodells für erforderlich hielten. Es ist nämlich geprägt von Inkonsistenzen und den Beschränkungen eines über lange Zeit gewachsenen Produkts. Aus diesem Grund lassen sich komplexere Notes-Anwendungen vergleichsweise schwer warten und erfordern erhebliches Wissen über eine proprietäre Umgebung.
Lotus-Chef Al Zollar stiftete mit der Ankündigung seiner Java-Strategie Verwirrung. Die vermeintliche Revolution entpuppte sich weitgehend als Fortentwicklung von Notes/Domino. (Foto: IBM)
Im Zuge der Java-Ausrichtung von IBM ergänzte Lotus seine Groupware schon in der Version 4.5 um Unterstützung für die Sun-Technologie. Damit war auch die Hoffnung verknüpft, dass Notes/Domino von der rasch wachsenden Java-Gemeinde profitieren könne. Allerdings war die Java-Entwicklung an das bisherige Programmiermodell gebunden, wo die Sun-Sprache nicht durchgängig genutzt werden konnte, sondern nur einen weiteren Beitrag zum Notes-typischen Sprachmix leistete.
Mit der nun angekündigten J2EE-Strategie vollzieht die IBM einen Bruch mit dem bisherigen Java-Konzept und stellt den Übergang zu einem konsistenten und offenen Programmiermodell in Aussicht. Die wesentliche Änderung gegenüber dem bisherigen Java-Einsatz besteht darin, dass die Entwicklung nicht mehr innerhalb der Notes-Datenbank stattfinden soll. Nach dem bisherigen Modell kapselt diese sowohl die Daten als auch den Programmcode und Designelemente. Stattdessen sieht Lotus zukünftig vor, dass Java-Programme auf einem separaten J2EE-Server ablaufen sollen und von dort auf Dienste von Notes/Domino zugreifen. Seinen Niederschlag findet diese Neuorientierung darin, dass die bis vor kurzem angekündigten Java-Features aus der Version 6 eliminiert wurden. Betroffen war davon vor allem die geplante Engine zur Ausführung von Servlets und Java Server Pages (JSPs), die unter dem Codenamen "Garnet" noch Bestandteil der Beta 4 war und auf "Apache Tomcat" beruhte. Die Servlet-Unterstützung wird nun für das fertige Produkt, das Lotus zum Ende des dritten Quartals ausliefern will, auf dem Stand von Domino R5 eingefroren. Immerhin können so bestehende Anwendungen weiter benutzt werden.
Diese Ankündigung veranlasste einige Analysten und Anwender zu harscher Kritik an IBM. Sie vermuteten darin vornehmlich einen Trick, um an Notes-Kunden Websphere-Server verkaufen zu können. Derartige Marketing-Erwägungen dürften den IBM-Verantwortlichen sicher nicht fremd sein, dennoch liegt darin kaum der wesentliche Grund für den neuen Java-Kurs. Plausibel klingt jedenfalls das offiziell vorgetragene Argument, IBM wolle die Kosten für eine zweigleisige Entwicklung von J2EE-Middleware sparen.
Teamfunktionen für Geschäftsanwendungen
Ausschlaggebend für die Veränderung des Anwendungsmodells indes dürfte die von Big Blue neu ausgerufene Strategie der "Contextual Collaboration" sein. Sie sieht vor, dass die hauseigene Collaborate-Software nicht mehr für separate und isolierte Anwendungen genutzt, sondern mit allen möglichen Anwendungen verflochten wird. Notes-Applikationen bisherigen Typs erweisen sich meist als selbstgenügsam und sträuben sich gegen eine solche gezielte Nutzung von Teamfunktionen durch externe Programme.
Als Beispiel für die Integration von Funktionen zur Online-Zusammenarbeit nannten IBM-Vertreter etwa das Einblenden von Terminkalendern in Business-Applikationen, um Meetings zu planen, oder die Möglichkeit, in unterschiedlichen Kontexten Diskussionsforen oder Communities einzurichten.
Antiquiertes Notes: Zu den zahlreichen Ungereimtheiten der Notes-Entwicklung gehört beispielsweise, dass nicht triviale Anwendungen immer aus einem Sprachmix bestehen, zu dessen Bestandteilen neben dem Basic-Dialekt "Lotusscript" auch eine Formelsprache aus der PC-Steinzeit gehört. Durch die Öffnung der Plattform für die Web-Entwicklung kommen häufig Javascript-Code und überall verstreutes HTML-Markup hinzu. Da Standardwerkzeuge zur Softwareentwicklung typische Designelemente der proprietären Notes-Datenbank wie Ansichten, Masken oder Felder nicht kennen, bieten sich dem Notes-Programmierer praktisch keine Alternativen zum mitgelieferten "Designer". Trotz erheblicher Fortschritte in der Version 5 bleibt dieser in vielerlei Hinsicht hinter den führenden Tools aus der Microsoft- oder Java-Welt zurück.
Technisch betrachtet lassen sich derartige Dienste bereits von Domino R5 aus anderen Anwendungen abrufen. Die Backend-Klassen können heute schon über die Java-APIs angesprochen werden, in verteilten Anwendungen erfolgt die Kommunikation mittels Remote Method Invocation (RMI) über das von Corba stammende Internet Inter-ORB Protocol (IIOP). Dies soll auch in Zukunft ein gängiger Mechanismus bleiben, um in Java-Geschäftsanwendungen Domino-Dienste zu nutzen. Allerdings will die IBM den Entwicklern, die heute solchen Code durchgängig manuell erstellen müssen, zukünftig Unterstützung durch komfortable Tools bieten. Die Company kündigte solche Java-Werkzeuge auf Basis des Open-Source-Frameworks "Eclipse" an, das seinerseits auf dem Quellcode der "Websphere Workbench" beruht.
Domino 6 verbessert JSP-Unterstützung
Zuvor allerdings soll Domino 6 das derzeit mühsame Programmieren von Java-Anwendungen etwas vereinfachen, indem es die Backend-Klassen und zahlreiche weitere Funktionen über mitgelieferte JSP Tag Libraries zugänglich macht. Mittels Custom-Tags lassen sich Domino-Funktionen innerhalb von JSP-Anwendungen über XML-Elemente ansprechen. Im günstigsten Fall sind dann Web-Designer ohne Java-Kenntnisse in der Lage, etwa Notes-Ansichten in ihre HTML-Seiten einzubinden.
Derartige Anwendungen, die vornehmlich für die Erzeugung von Benutzeroberflächen JSPs einsetzen, bedürfen keineswegs eines J2EE-Schlachtschiffs wie Websphere. Vielmehr reicht in solchen Fällen ein Servlet/JSP-Container wie Tomcat aus. Die IBM hingegen sieht ihre Chance vor allem in komplexen Lösungen, wo der hauseigene Applikations-Server durch enge Domino-Integration (etwa Single- Sign-on) und ergänzende Dienste glänzen kann. Dies gilt insbesondere für Enterprise-Portale, die im Konzept der Contextual Collaboration eine zentrale Rolle spielen.
Die IBM-Marketiers bauen dabei auf Prognosen von Marktforschern, wonach Online-Zusammenarbeit ein typisches Merkmal für die nächste Generation dieser Informationspforten sein wird. Derzeit sind viele Unternehmen noch damit beschäftigt, Intranets zu konsolidieren und Content unter einer einheitlichen Oberfläche zusammenzuführen. In der nächsten Stufe, so die Vorhersage, beschränken sich Portale nicht mehr auf die Aggregierung von Dokumenten, sondern integrieren auch Anwendungen und Enterprise-Daten. In diesem Kontext sei es dann erwünscht, Informationen nicht nur zu konsumieren, sondern beispielsweise Dokumente gemeinsam bearbeiten zu können oder über Chat Rückfrage zu bestimmten Geschäftsvorgängen zu halten (die Schlagworte dafür lauten: plan, share, coordinate, brainstorm, build communities).
XML und Web-Services für Lotusscript: Trotz klarer Ausrichtung auf Java will die IBM Notes-Entwickler, die weiter auf das bisherige Anwendungsmodell setzen, nicht aus der schönen neuen Welt der Web-Services ausschließen. Allerdings mutet das Sammelsurium an Tools, das Lotus mit Domino 6 anbieten wird, recht bunt gemischt und unvollständig an. Während bisher nur Java-Entwickler mit Hilfe von Packages wie "Apache Soap" externe Web-Services abrufen konnten, indem sie von Hand Domino-Agents oder Servlets codierten, kommen nun auch Lotusscript-Programmierer zum Zug. Über neue XML-Backend-Klassen stehen auf Basis der Apache-Tools "Xerces" und "Xalan" ein DOM- und SAX-Parser sowie ein XSLT-Prozessor zur Verfügung. Sie bieten zumindest die Voraussetzung dafür, dass per Soap eingehende XML-Nachrichten interpretiert und bei Bedarf auf ein anderes Schema konvertiert werden können.
Zum Lieferumfang von Domino 6 gehören aber keine Soap-bezogenen Funktionen für Lotusscript. Solche bietet die IBM indes über "Alphaworks" als "Soapconnect for Lotusscript" an, das seinerseits Bestandteil des "Web Services Toolkit" ist. Von dort stammende Software befindet sich im Alphastadium und entsprechend erhalten Anwender dafür keinen offiziellen Support. Zumindest können aber Basic-Programmierer unter Notes damit Web-Services nutzen. Wenn es darum geht, Domino-Anwendungen als Web-Services anzubieten, führt vorerst kein Weg an Java vorbei. Allerdings muss dafür ein weiteres Paket von Alphaworks herhalten, das "Web Services Enablement Kit". Dieses erlaubt nicht nur, eigene Notes-Programme Web-Service-fähig zu machen, sondern definiert auch schon die Schnittstellen für gängige Funktionen mehrerer Lotus-Server. Lotusscript-Entwickler, die sich partout nicht mit Java anfreunden können, bietet die IBM
auch hier ein Hintertürchen: Domino 6 sieht generell die Möglichkeit vor, aus dem Basic-Dialekt Java-Klassen aufzurufen.
Für solche kommenden Anwendungsszenarien sollten aus Sicht der IBM keine leichtgewichtigen Java-Server den Collaborative Services vorgeschaltet werden, sondern nach Möglichkeit der "Websphere Portal Server". Dieser tritt derzeit noch im Duo mit der "Lotus K-Station" auf, in der kommenden Version 4 sollen die Funktionen der beiden Produkte dann auf Basis von Websphere verschmolzen werden. Als Anwendungsbausteine fungieren dort so genannte Portlets, die jeweils einen Ausschnitt des Portals mit Funktionen oder Daten versorgen. Sun und IBM brachten kürzlich einen Vorschlag zur Standardisierung von Portlets in den Java Community Process ein. Derartige Programme sollen demnach auf der Servlet-Spezifikation beruhen und zwischen Applikations-Servern portabel sein.
IBM will den Websphere Portal Server in der nächsten Version mit Hunderten solcher Bausteine ausliefern. Viele davon dienen als Fenster zu Lotus-Produkten, etwa für den Zugriff auf den Mail-Eingangsordner oder den Kalender von Notes, zum Einblenden von Foren aus "Quickplace", zur Überprüfung per "Sametime", ob jemand online erreichbar ist ("People Awareness") oder zur Sicht auf Dokumentkategorien im "Discovery Server".
Collaborative Services für Portale
Neben Stand-alone-Anwendungen, die über Java-APIs oder JSP Custom Tags die Collaborative Services von Lotus-Software nutzen, sollen mithin auch Portlets zu wichtigen Clients dieser Dienste werden. Daneben aber folgt die IBM einem aktuellen Trend der Softwareindustrie und macht die Backend-Funktionalität der Lotus-Produkte per Web-Services von außen zugänglich. Allerdings zeichnen die Ankündigungen des Herstellers noch ein etwas unklares Bild. Offensichtlich bevorzugen die IBM-Strategen auch hier das neue Anwendungsmodell, bei dem Java-Programme die von ihnen beanspruchten Lotus-Backend-Dienste quasi indirekt über einen Applikations-Server publizieren sollen. Gleichzeitig aber erhalten alle Server-Produkte selbst Web-Service-Interfaces. Dies gilt nicht nur für die Basisprodukte, sondern auch für solche, die auf Domino aufsetzen wie etwa "Domino.Doc" oder "Domino Workflow".
Umbau erfolgt hinter Web-Services-Fassade
Big Blue verspricht sich von diesem XML-basierenden Komponentenmodell gleich mehrere Vorteile. Zum einen bietet es die Chance, für alle Server übergreifend so etwas wie ein Collaborative API zu definieren. Über ein solches konsistentes Lotus-Server-API ließen sich dann die immer wieder beschworenen "Collaborative Components" schon auf Basis der bestehenden Produkte realisieren. IBM will Web-Services nicht nutzen, um auf diesem Weg jede API-Methode zugänglich zu machen, sondern beabsichtigt, logisch zusammengehörige Funktionen zu komplexeren Features zu gruppieren. Sie könnten zukünftig die Bausteine einer Contextual Collaboration abgeben.
Für den Low-Level-Zugriff auf Programmier-Schnittstellen setzt Big Blue weiterhin auf Mechanismen wie RMI oder Corba. Darin zeichnet sich ein Unterschied zur Microsoft-Welt ab, wo DCOM unter .NET zum alten Eisen gehört - entsprechend werden dessen Aufgaben dort Web-Services übernehmen müssen. Das ändert aber nichts grundsätzlich daran, dass die beiden dominierenden Anwendungsmodelle, Java und Windows/.NET, zukünftig auf ein gemeinsames Komponentenmodell bauen.
Derzeit werden Anwendungen zur Online-Zusammenarbeit noch vornehmlich separat genutzt. Im Rahmen der Contextual Collaboration sollen sie Bestandteil von Business-Software werden.
Die Vorteile eines solchen Standards zeigen sich für die IBM auch darin, dass Windows-Versionen der Lotus-Produkte nicht mehr so vieler plattformspezifischer Verrenkungen bedürfen. Bisher musste Notes/Domino die meisten der Redmond-spezifischen Standards unterstützen, von COM über MAPI bis ODBC. Dank Web-Services ergeben sich auch neue Möglichkeiten in puncto Client-Anbindung, vor allem nachdem Microsoft Office mit Hilfe eines kürzlich freigegebenen Add-ons ebenfalls mit dem neuen Standard kompatibel ist. Hinter der geplanten, durchgängigen Web-Service-Fassade kann die IBM ihre Server-Produkte in kleinere Komponenten zerlegen, ohne dass sich dies auf externe Anwendungen auswirkt. Besonders für Domino steht eine stärkere Modularisierung schon länger auf der Tagesordnung. Aus historischen Gründen bringt dieser Server einige Funktionen mit, die heute gängige Bestandteile der IT-Infrastruktur sind. Dazu zählen besonders eine eigene Datenbank sowie
ein integriertes Verzeichnissystem. Während relationale Datenbanken in den Anfangszeiten von Notes noch auf wenige Standarddatentypen beschränkt waren, können ihre objektrelationalen Nachfolger auch beliebige Multimedia-Daten speichern. Der schwindenden Daseinsberechtigung der Notes-Datenbank (NSF) trägt die IBM Rechnung, indem sie mit Domino 6 Funktionen des "Lotus Enterprise Integrator" in das Basisprodukt übernimmt. Damit lassen sich NSFs weitgehend virtualisieren, das heißt, sie dienen bei Bedarf nur mehr als Fenster in eine DB2- oder Oracle-Datenbank. Auf ähnliche Weise soll auch das Domino-Directory in späteren Versionen als Hülle für externe Verzeichnissysteme fungieren.
Alter Kern bleibt erhalten
Der Reiz dieser Verfahren liegt darin, dass sich der Domino-Server für alle jene, die das wollen, weiterhin als der alte Bekannte präsentiert - die Notes-Datenbank steht jedenfalls wie gewohnt zur Verfügung. Hinter dem neuen Java- und Web-Services-Gesicht verbergen sich auch in puncto Anwendungsentwicklung die alten Notes-Persönlichkeiten. In gewissem Umfang lässt ihnen Big Blue noch ein Faceliftig angedeihen: So wurde die Formelsprache für Domino 6 überarbeitet und um neue Funktionen erweitert. Allerdings stellt sich die Frage, ob Notes-Entwickler gut beraten sind, wenn sie dem alten Anwendungsmodell verhaftet bleiben. Künftig können Programmierer Anwendungen für Domino durchgängig in Java schreiben und dabei Werkzeuge nutzen, die dem Designer überlegen sind. Der Startvorteil von alten Notes-Hasen, die mit den zahllosen Macken einer proprietären Umgebung vertraut sind, geht also zunehmend verloren.