Der WGA Publisher in der Version 2.2.1 bietet als neues Feature die Möglichkeit, Domino-Datenbanken über eine CORBA-Schnittstelle anzusprechen. Damit eröffnen sich einige neue Möglichkeiten für die Publizierung von Web-Content aus Lotus Domino

Generelles zu CORBA und Lotus Domino

Alle Domino-Datenbanken die bislang in WGA eingebunden wurden, wurden über die sogenannte "native Schnittstelle" angesprochen. Diese Schnittstelle ist eine nicht-netzwerkbasierte Kommunikation, bei welcher im Grunde direkt mit den Programmbibliotheken von Lotus Domino über Prozeduraufrufe kommuniziert wird. Daher ist für diese Schnittstelle auch eine lokale Installation von Lotus Domino vonnöten.

CORBA ist ein von der "Object Management Group" erarbeiteter Standard mit welchem Programme ihre internen Objekte anderen Programmen über das Netzwerk hinweg zur Verfügung stellen können. Lotus Domino besitzt bereits seit R5 eine CORBA-Schnittstelle für Java-Programme, und exportiert darüber typische Domino-Objekte wie Datenbanken und Dokumente. Erst R6.5 jedoch ist diese Schnittstelle effektiv und performant genug, um Systeme, die auf hohe Performance und Skalierbarkeit angewiesen sind, mit Daten zu versorgen. Webgate Anywhere ab der Version 2.2.1 unterstützt nun neben der nativen Anbindung an Domino-Datenbanken auch die Einbindung von Domino-Datenbanken per CORBA-Schnittstelle.

Dieses Feature ist vor allem für Kunden interessant, welche die Daten von Domino-Servern einbinden wollen, die sich nicht auf demselben Rechner wie ihr J2EE-Server befinden. Es kann aber auch Sinn machen, existierende Domino-Anbindungen von der nativen auf die CORBA-Schnittstelle umzustellen, wie der folgende Abschnitt über die Unterschiede der Implementierungen deutlich macht.

Unterschiede zwischen nativer und CORBA-Anbindung in Webgate Anywhere

Jenseits der Tatsache, dass CORBA-Anbindungen netzwerkbasiert sind, gibt es weitere Unterschiede zur nativen Anbindung in WGA. Viele der im folgenden beschriebenen Unterschiede sind ein Resultat performancesteigender Maßnahmen. So verwaltet WGA seine CORBA-Verbindungen über eine internes Connection Pooling , und baut alle Datenbank-Sessions ausschliesslich mit dem Master-Login auf (und nicht mit einzelnen Benutzer-Logins, so wie bei der nativen Schnittstelle).

Kommen wir zunächst zu den Restriktionen, welche die CORBA-Schnittstelle ggü. der nativen Schnittstelle besitzt:

• Zusätzliche Leser- und Autorenfelder, die vielleicht per Teilmaske in Content-Dokumente eingepflegt wurden, sind ineffektiv. Lediglich das vorgesehene Feld "Leser", welches sie in den Content-Eigenschaften finden, ist effektiv. Was andere Leser- und Autorenfelder angeht gelten für alle Benutzer die Berechtigungen des Master-Logins, welches sie im WGA Manager festlegen
• In Formelsprache ist kein Zugriff auf WebTML-Variablen möglich wenn die ausführende Domino-Datenbank per CORBA eingebunden wird
• Benutzerbezogene Funktionen in der Formelsprache geben nicht die Daten des angemeldeten Benutzers sondern die des Master-Logins aus
• Das "Default"-Login als Master-Login - dessen Verwendung seit WGA 2.2 nicht mehr empfohlen wird - ist bei der CORBA-Anbindung nicht verfügbar
• Höherer Hauptspeicherverbrauch durch intensiveres Caching. Für einen ausreichenden maximalen Heap-Size des J2EE-Servers sollte gesorgt werden.
• Diese Anbindung ist nur auf Domino Servern ab Version 6.5.1 möglich

Zu den neuen Möglichkeiten der CORBA-Implementierung:

• J2EE-Server und Domino-Server können erstmals auf verschiedenen physikalischen Rechnern beheimatet sein. Auf dem Rechner des J2EE-Servers ist dabei keine Domino- oder Notes-Installation notwendig.
• Bei der nativen Anbindung ist die einzig mögliche Authentifizierungsquelle (d.h. das Verzeichnis verfügbarer Logins) das Domino Directory. Bei der CORBA-Anbindung ist auch das Domino Directory die Standard-Authentifizierungsquelle. Es können jedoch auch andere Quellen gewählt werden. So haben sie die Möglichkeit ihre verfügbaren Logins entweder in einer XML-Datei festzulegen, von einem LDAP-Server zu beziehen oder auch von einem beliebigen anderen Domino-Server, der nicht identisch mit dem Server sein muss, der ihre publizierten Datenbanken enthält
• Der anonyme Zugriff auf den Domino-Server kann deaktiviert werden. Anonymes Browsen über WGA bleibt trotzdem möglich.

Einrichtung einer Domino-Datenbank für den CORBA-Zugriff

Die Einbindung einer Domino-Datenbank in WGA ist recht einfach zu bewerkstelligen. Zunächst zu den Voraussetzungen:

• Es muss ein Domino Server der 6.5.1 oder höher vorliegen
• Der DIIOP-Task des Domino Servers muss aktiv sein
• Im Serverdokument des Domino Servers, Bereich "Ports->Internet Ports->DIIOP" muss der Zugriff per Name & Passwort aktiviert sein. Der anonyme Zugriff kann deaktiviert werden.
• Ebenfalls im Serverdokument, Bereich "Internet Protokolle->DIIOP" sollte der Name des Hosts eingetragen werden.
• Im Klassenpfad des J2EE-Servers muss die JAR-Datei "NCSO.jar" eingebunden werden. Diese befindet sich im Unterverzeichnis "domino/java" des Domino-Data-Verzeichnisses. Um eventuelle Klassenlade-Konflikte auszuschliessen empfehlen wir, direkt alle Domino-Verbindungen vom nativen auf den CORBA-Zugriff umzustellen und dann die JAR-Datei "Notes.jar" - die nun nicht mehr notwendig ist - aus dem Klassenpfad zu entfernen. Ansonsten kann die gleichzeitige Verwendung der beiden JAR-Dateien, je nach Klassenlader-Architektur, zu Problemen führen, bei welchen einzelne notwendige Klassen der JAR-Dateien nicht ladbar sind

Der Bereich "Internet-Protokolle->DIIOP" im Serverdokument.

Um schliesslich eine Domino-Datenbank für den CORBA-Zugriff einzurichten gehen sie wie folgt vor:

• Starten sie den WGA Manager. Wenn sie eine existierende Datenbank-Anbindung auf CORBA-Zugriff umstellen wollen, so suchen sie deren Eintrag unter Reiter "Content". Legen sie anderenfalls unter diesem Reiter eine neue Datenbank an.
• Im Feld Database type finden sie nun sowohl für die "WGA Content Store for Lotus Domino", als auch für die "Custom Lotus Domino Database" jeweils zwei Einträge. Ein Eintrag endet auf "(native access)" und ist die bereits bekannte native Schnittstelle zu Lotus Domino. Der andere Eintrag endet auf "(CORBA access)" und ist die neue Implementierung. Wählen sie letztere.
• Im Feld Database path geben sie wie gewohnt den Pfad zur Datenbank ein. Vor diesem Pfad geben sie jedoch zusätzlich, und vom Pfad durch ein Semikolon getrennt, den Hostnamen des Domino-Servers ein. Verwenden sie hier bitte keine Loopback-Adressen, wie "localhost" oder "127.0.0.1", sondern idealerweise denselben Hostnamen, den sie auch im Serverdokument, Bereich "Internet Protokolle->DIIOP" angegeben haben.
• Geben sie als Master-Login ein Domino-Login mit Benutzername und (Internet-)Kennwort an, welches...
  • a) in ihrer Datenbank Manager-Rechte besitzt, sowie...
  • b) - falls es sich um eine WGA Content Store handelt - die [Admin]-Rolle, sowie ...
  • c) Im Serverdokument, Bereich "Sicherheit", für das Ausführen "unbeschränkter Methoden und Operationen" konfiguriert ist
    Das Default-Login kann, wie eingangs beschrieben, nicht verwendet werden.

Eine fertig eingerichtete Domino-Datenbank mit CORBA-Anbindung

Auch für die Personalisierung existieren nun zwei Datenbanktypen die einerseits auf der nativen andererseits auf der CORBA-Schnittstelle basieren. Die Einrichtung der Personalisierungs-DB auf Basis der CORBA-Schnittstelle ist identisch zu dem oben beschriebenen Verfahren.

Optimierung der Performance - Gecachte Queries

Obwohl die CORBA-Schnittstelle was Performance angeht unter R6 gewaltige Fortschritte gemacht hat, mag es weitere Schritte benötigen um über diese Schnittstelle die Performance zu erlangen die man erwartet. Ein wirksames Hilfsmittel ist ein weiteres neues Feature in WGA 2.2.1: gecache Queries.

Bislang wurde in WGA jedesmal, wenn ein <tml:query>-Tag rerendert wurde, eine Anfrage an die Datenbank im Hintergrund weitergeleitet, auch dann wenn dieselbe Anfrage schon hunderte Male zuvor verarbeitet wurde. Dies ist unter Umständen sehr ineffektiv, da sich das Ergebnis vieler Anfragen nicht verändern kann, solange sich nicht auch die zugrundeliegenden Daten in der Datenbank ändern. Eine simple Anfrage per Formelsprache _news = "J" wird erst dann andere Ergebnisse bringen als im vorherigen Aufruf, wenn ein Dokument neu erfasst, modifiziert oder gelöscht wurde, wodurch sich die Menge der Dokumente mit einem Feld "_news" und dessen Inhalt "J" verändert.

Genau für diese Art Anfragen wurden gecachte Queries in WGA integriert. Sie können für vorhandene <tml:query>-Tags sehr leicht durch Hinzufügen eines Attributes "cache" aktiviert werden:

<tml:query db="artikel" type="formula" cache="true">_news = "J"</tml:query>

Dieser Zusatz sorgt dafür, dass die Ergebnisse der Abfrage, sobald sie einmal ausgeführt wurden, zwischengespeichert werden. Alle weitere Aufrufe derselben Anfrage werden daraufhin aus dem zwischengespeicherten Ergebnis geliefert, ohne dass die Datenbank die Abfrage erneut ausführen muss. Dies geschieht solange, bis der Content der Datenbank geändert wird und somit die zwischengespeicherten Ergebnisse verworfen werden.

Auch Anfragen, deren Text über einen Parameter variabel gehalten wird, können so gecacht werden, z.B.:

<tml:query db="artikel" type="fulltext" cache="true"><tml:urlparameter name="searchFor"/></tml:query>

In diesem Fall werden für jede Variante des Suchtextes eigene Caches angelegt und verwaltet. Der Cache funktioniert also NICHT pro Query-Tag sondern pro Suchtext.

Ungeeignet für gecachte Queries sind solche Anfragen mit Kriterien, die nicht alleine auf den Daten der Datenbank basieren. Ein Beispiel dafür ist der Einbezug des aktuellen Datums in die Abfrage:

<tml:query db="artikel" type="formula">_showMeUntil < @Today</tml:query>

Da sich hier das Ergebnis der Anfrage quasi minütlich ändern kann und nicht nur von Änderungen in der Datenbank abhängig ist, ist es nicht effektiv zwischenspeicherbar.

Optimierung der Performance - TMLScript statt Formelsprache

Basis aller Performanceoptimierungen für die CORBA-Implementierung ist die Minimierung der Rückgriffe auf die Datenbank. Ein Baustein in dieser Minimierung ist der Verzicht von Formelsprache in WebTML-Konditionen und Evaluate-Tags. Da WGA selbst keine Formelsprache ausführen kann muss es jede einzelne Formel zur Ausführung an die Datenbank zurückreichen und von ihr ein Ergebnis anfordern. Dieser Vorgang führt bei der CORBA-Implementierung zu nicht zu unterschätzendem Netzwerk-Traffic, welcher das Ergebnis bremst.

Zusammen mit anderen Limitierungen der Formelsprache bei CORBA-Zugriff (Kein Zugriff auf WebTML-Variablen, Keine Abfrage der Benutzerdaten) bedeutet dies, dass die Formelsprache in diesem Fall sehr unattraktiv ist und generell durch TMLScript ersetzt werden sollte.

TMLScript als Ausdruckssprache bietet hier eine Reihe von entscheidenden Vorteilen:

• Es ist generell in der Ausführung schneller als die Formelsprache, da sein Code nicht jedesmal neu geparst werden muss
• Es wird von WGA selbst interpretiert. Es ist also nur zur Ausführung kein Rückgriff an die Datenbank notwendig.
• Es benutzt sämtliche in WGA integrierten Caches um die Daten der Datenbanken zu verarbeiten. Auch dadurch werden Datenbank-Rückgriff minimiert.

Sie können die Ausdrücke ihrer existierenden Datenbank schrittweise von Formelsprache auf TMLScript umstellen, um sukzessive kleine Performance-Gewinne zu erzielen. Auch der komplette Verzicht auf Formelsprache lohnt sich, da sie dann durch gezieltes Abstellen der Formelsprachen-Unterstützung eine weitere Performanceverbesserung erzielen lässt. Dies können sie durch folgende DB-Option:

FormulaSupport := false

Ist die Unterstützung für Formelsprache deaktiviert, so kann WGA intern weitere Optimierungen vornehmen.

HINWEIS: Die in diesem Kapitel dargelegten Optimierungen beziehen sich NICHT auf Abfragen die in Formelsprache formuliert werden, sondern ausdrücklich nur auf Formelsprache in Konditionen, sowie in Evaluate-Tags. Ebenso führt die deaktivierung der Formelsprache per DB-Option "FormulaSupport" NICHT zu einer Deaktivierung der Formelsprache in Abfragen

Steuern des anonymen Zugriffes auf die Website

Ein Vorteil der Verwendung der CORBA-Implementierung ist die Tatsache, dass der Domino Server keine anonymen Verbindungen erlauben muss damit die WGA-Site ohne Anmeldung aufrufbar ist. Dennoch benötigt man eine Möglichkeit, den anonymen Zugriff auf die WGA-Site zu steuern bzw. zu unterbinden, falls dieser nicht erwünscht ist. Dies gelingt mit folgender DB-Option:

AnonymousAccessLevel := NOACCESS / READER / AUTHOR / EDITOR / MANAGER

Diese Option setzt das Zugriffslevel für anonymen Zugriff fest. Die Standardeinstellung ist READER. Falls sie keinen anonymen Zugriff auf die Site wünschen, wählen sie NOACCESS.

Alternative Authentifzierungs-Quellen - Alternativer Domino-Server

Wie eingangs schon erwähnt eröffnet sich mit der CORBA-Implementierung die Möglichkeit, andere Authentifizierungs-Quellen als das Domino-Directory. Unter Authentifizierungs-Quelle wird hierbei jede Einrichtung verstanden, die in der Lage ist Logins aus Benutzername und Kennwort entgegenzunehmen und zu verifizieren. In WGA steuert diese Authentifizierungs-Quelle, welche Logins die Datenbank akzeptiert. Diese Quelle wird über DB-Optionen im WGA Manager konfiguriert.

Solange nichts weiter konfiguriert wird, authentifiziert sich die CORBA-Implementierung gegen das Domino Directory des Domino Servers, auf dem sich die publizierte Datenbank befindet. Relativ einfach lässt sich die Authentifizierung jedoch auch auf das Domino Directory eines anderen Servers umleiten. Dazu sind folgende beiden DB-Optionen notwendig:

auth.module := domino
auth.host := myother.dominoserver.de

Der alternative Authentifizierungs-Server muss ebenfalls für den Empfang von CORBA-Verbindungen über den DIIOP-Task konfiguriert sein

Alternative Authentifzierungs-Quellen - XML-Datei

Ebenso einfach kann man die Authentfizierung auf den Daten einer XML-Datei basieren lassen. Folgende DB-Optionen genügen:

auth.module = file
auth.file = C:\pfad\zur\datei.xml

Dieses Authentifizierungs-Modul akzeptiert das folgende XML-Format zur Definition von Benutzer-Logins und Gruppen:

<users allowanonymous="true">
<user name="CN=Vorname Nachname/O=Organisation" password="dasPasswort" mail="die@emailAdresse.de" aliases="Vorname Nachname, vn"/>
<user .... >
...
<group name="[admin]" members="Oliver Weise"/>
<group ...>
...
</users>

Über dieses simple Format können sie beliebige Benutzer- und Gruppen angeben. Achten sie darauf, dass sie unter Attribut "aliases" alle alternative Namensvarianten angeben, die eventuell in Benutzerfeldern (z.B. dem Leserfeld von Content-Dokumenten) Verwendung finden. Das Attribut "allowanonymous" im Root-Tag steuert hierbei die Verfügbarkeit anonymer Verbindungen.

Auffällig ist, das hier eine Gruppe mit dem Namen "[admin]" angelegt wurde. Da es bei der XML-Authentifizierung keine Rollen gibt, sind Gruppen hier gleichbedeutend mit Rollen. Daher können sie, wenn sie Rollennamen als Gruppen verwenden, ihren Benutzern bestimmte Rechte auf die Content Store geben, welche sie normalerweise über Rollen in der ACL zuweisen würden.

Eine Verschachtelung von Gruppen (Gruppen die wiederum andere Gruppen als Mitglieder haben) ist nicht möglich.

Alternative Authentifizierungs-Quellen - Verzeichnisdienste

Zusätzlich zu diesen Varianten haben sie die Möglichkeit einen LDAP-Server als Authentifizierungs-Quelle zu verwenden. Diese Variante basiert auf dem "Java Names Directory Interface" (kurz JNDI) und ist in der Lage alle JNDI-Quellen als Authentifizierungs-Quelle zu verwenden, die eine Anmeldung akzeptieren. Aufgrund der vielen denkbaren Varianten ist eine Authentifizierung per JNDI komplizierter einzurichten als die zuvor besprochenen Quellen.

Folgende DB-Optionen zum Beispiel richten die Authentifizierung gegen den LDAP-Task eines Domino-Servers ein:

Option	Wert
auth.module	jndi
jndi.contextfactory	com.sun.jndi.ldap.LdapCtxFactory
jndi.path	ldap://my.dominoserver.de:389
jndi.objectclass.group	dominoGroup
jndi.attribute.mail	mail
jndi.nameattributes.people	cn,uid
jndi.nameattributes.groups	cn
jndi.dominonames	true

Für Unterstützung bei der Einrichtung einer JNDI-basierten Authentifizierungsquelle kontaktieren sie bitte ihren InnovationGate-Support.

Stolperfallen

Ein paar Fehlverhalten, über welche sie stolpern könnten und ihre Ursachen:

NoClassDefFoundError: lotus/domino/cso/Document (oder ähnliche Klassen)
Entweder befindet sich die JAR-Datei "NCSO.jar" nicht im Klassenpfad oder es liegt ein Ladekonflikt mit der "Notes.jar" vor. Im letzteren Fall sollten sie dafür sorgen dass sie entweder
a) alle WGA-Verbindungen zu Notes-Datenbanken auf die CORBA-Schnittstelle umstellen und die Datei "Notes.jar" aus dem Klassenpfad entfernen
oder
b) Notes.jar und NCSO.jar über denselben Klassenlader einbinden. Einige J2EE-Server, z.B. Websphere, bieten hierfür spezielle Konfigurationsmöglichkeiten

NotesException: Could not get IOR from Domino Server: java.net.ConnectException: Connection refused: connect
Es konnte keine Verbindung zum DIIOP-Server hergestellt werden. Dies kann viele Ursachen haben:

• Der im Datenbankpfad eingegebene Hostname ist nicht korrekt
• Der DIIOP-Task des Servers ist nicht aktiv
• Der Domino-Server akzeptiert keine DIIOP-Verbindung unter diesem Hostnamen, da er nicht identisch mit dem Hostnamen im Serverdokument, Bereich "Internet Protokolle->DIIOP" ist
• Der Port 63148 der von CORBA für die Verbindung verwendet wird, wird von einer Komponente des Netzwerkes, z.B. einer Firewall, abgefangen
• Über besagten Port liefert der Domino-Server keinen IOR (eine Art Netzwerkadresse für die CORBA-Verbindung). Dies kann auf älteren Domino-Servern bzw. unter bestimmten Konfigurationen der Fall sein. Als Workaround können sie den Domino HTTP-Task starten und im Datenbankpfad den Port dieses Tasks zum Hostnamen hinzufügen, z.B:
  hostname:80;pfad/zur/db.nsf

Prüfen sie im Zusammenhang mit diesem Fehler auch Ausgaben auf der Domino-Konsole die Aufschluss über die Fehlerursache geben könnten.

Instabilitäten der CORBA-Verbindung, des DIIOP-Tasks bzw. des Domino Servers
Die CORBA-Schnittstelle war unter frühen Domino-R6-Versionen noch mit einer Vielzahl von Fehlverhalten behaftet. Wir empfehlen die Version 6.5.1, da diese vorwiegend zum Test der WGA CORBA-Implementierung verwendet wurde und ein stabiles Laufzeitverhalten zeigte.