John Banks-Binici:
R5 Messaging & Directories
Interview von
Betsy
Kosheff
(Übersetzt von
Thomas Gumz)
Level:
Beginner
Works with:
All
Updated:
03-May-99
John Banks-Binici ist als Manager der R5 Messaging und Directory Teams für einen Großteil des erklärten Hauptziels von R5 zuständig: Das beste Enterprise-Messaging Produkt zu liefern, welches Unternehmen aller Größenordungen für Geld kaufen können. Unterstützung von Internet Standards wie z.B. MIME, SMTP, POP3, IMAP4, HTML und LDAP sind dabei nur der eine Teil. Interoperabilität ist wichtig, jedoch einfach nicht gut genug, um das beste Produkt zu liefern. In diesem Bericht lesen wir, wie John's Team sich auf einfache Bedienbarkeit, Sicherheit und transparente Interoperabilität konzentriert um diese Herausforderung zu meistern.
Beginnen wir mit Messaging. Welche Probleme versuchst Du hier zu lösen ?
Das eigentliche Ziel des Entwicklungsaufwandes zum Thema R5 Messaging führt einfach darauf zurück, zum einen ein Weltklasse-Internet Mailingsystem zu sein und zum anderen interoperabel mit den anderen Mailsystemen unser Kunden und auch
derer
Kunden zu sein. Gleichzeitig haben wir dabei streng auf die Betriebskosten für so ein System geachtet. Unser Administrations-Entwicklungsteam hat also ein komplett neues Userinterface entwickelt, welches das Produkt einfacher bedienbar und administrierbarer macht. Des weiteren haben wir viel Aufwand investiert um die Migrationsbedürfnisse unserer cc:Mail Kunden zu befriedigen. Das Administrationsteam hat diese Migrationswerkzeuge direkt in das Produkt integriert und wir haben ebenfalls die von cc:Mail Administratoren erwarteten neuen Routerfeatures integriert.
Während der ganzen Entwicklungszeit war die Motivation eigentlich die, unseren Kunden zu helfen, deren Kunden per Internet zu erreichen. Bis vor kurzem war die Fokussierung der Unternehmen wohl eher darauf ausgerichtet, ihre internen Kommunikationsprobleme zu lösen. Die innovativeren Kunden sind jedoch gleich einen Schritt weitergegangen und haben formale Kommunikationsstandards mit deren Kunden und Geschäftspartnern definiert. Notes wurde dafür sehr effektiv eingesetzt. Heute ermöglicht das Internet diesen Unternehmen ihre Systeme
direkt
auf die Endkunden einzustellen um damit Geschäftsvorteile zu erzielen, und genau dabei helfen wir ihnen, das bestmöglichst zu tun.
Was jedoch
,
wenn Kunden dies gar nicht wollen und stattdessen nur einfaches e-mail möchten ?
Da gibt es nichts dagegen einzuwenden. Für bestimmte Geschäftsbereiche kann es jedoch große Auswirkungen haben, wenn die sich ständig verändernden Kundenerwartungen nicht rechtzeitig erkannt werden. Zum Beispiel hatte sich die US Firma "Fidelity" dazu entschieden, sich nicht besonders um den Kleinanlegermarkt zu kümmern, welcher den Aktienhandel lieber online durchführen wollte und hat sich stattdessen auf den High-End Markt konzentriert. Und damit haben sie im Endeffekt einen signifikanten Anteil ihrer Kunden verloren. Fälle wie dieser haben viele unserer Kunden dazu gebracht, sich auf Interoperabilität zu konzentrieren. Unsere Aufgabe ist Lösungen dafür anzubieten und etwas, nachdem der Makt ganz klar gefragt hat, sind neuere und bessere Wege um existierende Systeme ans Internet anzubinden.
Was sind die großen Verbesserungen im Messaging, an denen Du für R5 arbeitest ?
Wir arbeiten hier an insgesamt vier Großbereichen quer über das ganze Produkt:
Echtes
RFC 822 Messaging und damit verbundene MIME und HTML Unterstützung,
echtes
SMTP routing,
echte
Internetadressierung und alternative Namensunterstützung für unsere Internationalen Kunden, welche kontrollieren möchten, wie deren Namen in anderen Sprachen erscheinen sollen. Zusätzlich hat der Notes Client jetzt volle Unterstützung für echtes RFC 822 Messaging, MIME, HTML Unterstützung, IMAP4 Unterstützung um IMAP4 Mailserver ansprechen zu können und LDAP3 Unterstützung für Verzeichnissuchen und Mailfilter, welche sofort synchron bei Mailempfang ausgeführt werden.
Für Messaging sehr wichtig, unser Datenbankteam hat jetzt Transaktionsaufzeichnung, "Online" und "In-Place" Kompaktierung und API's für Onlinesicherungen hinzugefügt. Wir haben außerdem eine Menge Arbeit ins Domino Directory investiert, worüber wir etwas später sprechen werden.
Ganz nebenbei, unser Messagingteam ist eigentlich ein "interner" Kunde des gesamten Entwicklungsaufwandes run um MIME, welcher von einer anderen Gruppe hier bei Iris geleistet wurde. Das MIME Entwicklungsteam hat eine der schwersten Projekte überhaupt von R5 gehabt und ich bin sehr stolz auf die hervorragende Arbeit, welche diese Gruppe geleistet hat !
Reden wir von MIME -- Was ist hier die technische Herausorderung?
Es ist ja bekannt, daß Notes ein eigenes, proprietäres Format benutzt hat, um Nachrichten im "Rich Text" Format zu speichern, und das lange Zeit bevor es überhaupt irgendwelche Standards gab. Früher mußten wir also das Notes Rich Text Format (genannt CD records, CD für "
C
ompound
D
ocument") ins MIME Textformat konvertieren, wenn Nachrichten ins Internet gesendet wurden, und das ganze umgekehrt, wenn Nachrichten vom Internet zu Notes kamen. Dieser Konvertierungsvorgang konnte zum Flaschenhals im Lotus MTA (Message Transfer Agent) werden, welche diese Konvertierungen vorgenommen hat.
Wir mußten also RFC 822 Nachrichten und deren MIME Textformat oder HTML Anhänge ein natives Format von Notes machen, um diese Konvertierungen vermeiden zu können. Damit erreichen wir gleichzeitig das beste Level von Interoperabilität, da bei Konvertierungen immer die Chance besteht, daß Details verloren gehen können. Wir hatten hier eine Reihe von Integrierungspunkten: Der Notes Client, der Mailer (im Client), die Mailschablone, der Server, der Router und das Directory. Das waren die Bereiche, in denen wir neue Logik implementieren mußten, um die neuen Formate und Protokolle zu verarbeiten, und zwar so, damit sie mit vorherigen Versionen von Notes kompatibel sind. Das war eine große Herausforderung für alle von uns hier. Ich habe hier das Glück, ein exzellentes Team von wirklich hochbegabten Mail und Directory-Entwicklern leiten zu dürfen, und damit ist diese Aufgabe gleichzeitig mit sehr viel Spaß verbunden.
Ist MIME eigentlich genausogut wie das Notes Rich Text format ?
Dazu muß ich zuerst einmal die Terminologie klarstellen. Technisch gesehen speichern wir RFC 822 Nachrichten vom Internet direkt in Notes als Objekte ab. Wir nennen das "echte MIME" Unterstützung, wobei hier zu beachten ist, daß eine RFC 822 Nachricht ja nicht unbedingt MIME enthalten muß. Allerdings ist es heute so, daß die meisten Nachrichten als MIME strukturiert sind. Eine MIME Nachricht enthält meistens einen HTML Bereich und einige, jedoch nicht unbedingt alle Objekte, welche von der HTML referenziert werden. Dies wird eine MHTML Nachricht genannt. Es ist also die HTML, welches das funktionale Gegenstück zu den Notes CD Records in diesem Kontext darstellt.
Und jetzt kann ich auch diese Frage beantworten, welche tatsächlich darum geht, wie HTML mit den CDs vergleichbar ist. Ich würde sagen, HTML deckt ca 98% von dem ab, was das Notes Rich Text Format kann. Es gibt immer noch bestimmte Konstrukte, welche in Notes einfach besser dargestellt werden können -- z.B. "expandierbare Sektionen" -- was in HTML nicht funktioniert. Das stellt jedoch nicht unbedingt ein Problem dar, da man solche Dinge auch anders darstellen kann, allerdings heißt das für Lotus, daß jene CD Features, welche nicht überlappen, standardisiert werden müssen. Das ist etwas, was von Lotus direkt nachdem R5 ausgeliefert wird, in Angriff genommen werden muß.
Wie verbessert sich MIME Unterstützung in R5 gegenüber R4.6 ?
Indem wir ganz einfach die Notwendigkeit des MTA's eliminieren. Das verbessert die Interoperabilität genauso wie einen potentiellen Flaschenhals, da der MTA im Unternehmen für das Internet Messaging einfach nicht mehr gebraucht wird. Alle MIME Services sind nun gleichmäßig zwischen den R5 Servern verteilt, anstatt auf nur ein oder zwei MTA's konzentriert. Nebenbei, die Art und Weise wie wir MIME Objekte intern speichern, ist wesentlich effizienter als in R4.6.
Es wird also keine Konvertierung mehr benötigt ? Wird das die Performance erhöhen ?
Ja, das erhöht die Performance ein ganzes Stück. Allerdings stimmt es nicht ganz, daß wir überhaupt keine Konvertierungen mehr durchführen. Wir brauchen diese Funktionalität immer noch für die älteren Clients und älteren Server. R5 braucht diese Konvertierungen allerdings nicht mehr. In einer gemischten R5 und pre-R5 Umgebung haben wir unser bestmögliches getan, damit solche Konvertierungen ebenfalls nicht mehr benötigt werden, und falls doch, daß die Performance um einiges besser ist als vorher.
Und wie hast Du dieses Ziel erreicht ?
Anstatt des MTA's nimmt nun der Server selbst diese Konvertierungen vor um pre-R5 Clients zu unterstützen. Auch haben wir neuen Code in unsere SMTP Services eingebaut, so daß, wenn eine RFC 822 Nachricht vom Internet in einem R5 Server ankommt, in einem Format abgespeichert wird, welches keine Konvertierung mehr benötigt und dann Stück für Stück so an die Clients weitergegeben wird, wie sie benötigt wird. In R4.6 haben wir auch schon Nachrichten abgespeichert, allerdings als reines Attachment, sozusagen ein ganzer RFC 822 oder MIME "Blob". Das war OK, allerdings mußte der Server dann mit dem kompletten "Blob" herumhantieren, wenn ein Client eine Nachricht lesen wollte. Ein wichtiger Punkt unserer MIME Unterstützung ist der, daß wir RFC 822 Nachrichten in mehrere Teile aufbrechen, so daß der Server nicht immer die komplette Nachricht lesen muß um sie zu bearbeiten. Diese Möglichkeit erhöht die Performance ein ganzes Stück, speziell für SMTP, IMAP und POP3 Dienste.
Siehst Du es als Deine Aufgabe an, diese interne Komplexität nach außen hin abzuschirmen ?
Absolut. Kunden, welche R5 einsetzen werden, und ganz speziell Kunden welche schon Notes einsetzen, werden davon nichts merken, da alles völlig transparent für sie automatisch gemanagt wird. Wir haben viel Logik in die Software eingebaut, so daß automatisch immer das richtige mit diesen Nachrichten geschieht. Also wenn z.B. jetzt jemand eine MIME Nachricht an einen R4.x Benutzer schickt, dann stellen wir sicher, daß diese ins CD Format übersetzt wird. Wenn die gleiche Nachricht an einen R5 Client geht, wird gar nichts mehr konvertiert.
Wie genau werden die verschiedenen Benutzereinstellungen spezifiziert ?
Jeder Benutzer in einem Domino Directory kann eine von drei Einstellungen haben: Reines Internet, Notes und Internet, oder nur Notes. Das wird im jeweiligen Personendokument festgelegt. Diese Einstellung legt fest, welches Format der Nachrichten der Benutzer bevorzugt. Also ist z.B. die Standardeinstellung für R5 Benutzer "Notes und Internet", da der R5 Client beide Formate empfangen und senden kann. Das Wissen über die jeweilige Benutzereinstellung ermöglicht uns die optimale Speicherung und Lieferung der Daten zum Client. Wenn also z.B. Ihre Einstellung statt dessen "Nur Internet" ist, weil Sie z.B. nur einen IMAP Client benutzen, dann wissen andere R5 Clients automatisch, daß Sie MIME Format wollen, weil sie im Domino Directory oder Katalog (mehr dazu später) nachschauen und genau das Format senden, welches Sie von Anfang an bevorzugen. Das spart die Konvertierung schon vom Start weg. Wenn umgekehrt jemand Ihrem IMAP Client CD Records schickt stellen wir sicher, daß die Nachricht konvertiert wird, bevor sie ankommt und speichern sie in der neuen und optimal auslesbaren Struktur, welche wir "echtes MIME" nennen.
Gibt es einen Zusatzgewinn hier wenn man den R5 Client benutzt?
Sicher. Wenn der R5 Client derjenige ist, welche die Nachricht sendet, und die Nachricht geht an zehn oder mehr Leute, schaut er jede einzelne Person im Domino Directory nach und ermittelt, wer MIME oder CD Records möchte oder auch keine speziellen Einstellungen vorgenommen hat. Der Notes Editor arbeitet hier mit dem neuen "Zwei-Phasen Mailer" im Client zusammen und splittet die Nachricht auf in MIME für diejenigen, welche MIME wollen und CD Record Format für die anderen. Dieser Prozess ist keine Konvertierung. Konvertierung wäre schlecht, da etwas, wenn es erstmal in HTML vorliegt, nicht immer optimal zurück ins CD Record Format oder auch umgekehrt übersetzt werden kann.
Der Notes Editor ist also hier der einzige, welcher optimal HTML generiert, da er derjenige ist, der den kompletten Inhalt der Nachricht als erster erzeugt und den Inhalt besser "versteht" als TAGS das jemals vermitteln können. Ergo ist der Editor der optimalste Platz um HTML (oder CD) zu erzeugen. Des weiteren weiß der Client, wenn er eine neue Nachricht erzeugt, welches Format der Empfänger bevorzugt, so daß die Nachricht jeweils entsprechend verschlüsselt werden kann. Das ist deshalb so wichtig, da man eine einmal signierte oder verschlüsselte Nachricht später nicht mehr ohne Einschränkungen konvertieren kann. Verschlüsselung und Signierung der Nachricht darf nur einmal erfolgen, und zwar beim Ursprung der Nachricht.
Also weiß der R5 Client genau, welches Format er zu dem jeweiligen Empfänger senden muß, und auch welcher Algorithmus benutzt werden soll, um eine Verschlüsselung und Signierung mittles S/MIME Seite-an-Seite mit Notes Veschlüsselung und Signierung durchführen zu können. Es ist wirklich ganz einfach. Sie wählen nur aus, an welche Leute die Nachricht gesendet werden soll und wir stellen fest, wie und was gesendet werden muß. Und wenn der Empfänger nicht im Directory verzeichnet ist, wird as Format verwendet, welches der Administrator des Systems festgelegt hat. Außerdem stellen wir automatisch fest, ob die Empfängeradresse eine RFC 821 oder 822 Adresse ist, so daß wir automatisch eine MIME Nachricht an diese Benutzer schicken, ohne daß diese zuvor im Directory nachgeschaut werden müßen. Dieser Zwei-Phasen Mailer ist ganz einfach ein extremer Zugewinn, ganz speziell für Extranets, welche eine Menge unterschiedlicher Clients haben.
Soviel zu existierenden Notes Kunden; was ist drin für Leute, welche vorher noch nie Notes benutzt haben ?
Es ist die Reichhaltigkeit unserer Funktionen und die Stabilität unserer Produkte, welche die Menschen von Iris, Lotus und IBM erwarten. Unsere Sicherheitsinfrastruktur ist bekannt für ihre Robustheit. Unsere Hochverfügbarkeits Clustering Technology ist State of the Art. Die Zeit, welche wir benötigen, um eine Lastverteilung oder Umleitung eines Clients auf einen anderen Server durchzuführen, wird in Millisekunden gemessen. Wir skalieren von Mittelstand über Enterpriseunternehmen hin bis zu Flugzeugträgern und Marineflotten. Verschiedene Betriebssystemplatformen sind ebenfalls ein großes Plus. In
allen
erwähnten Bereichen haben wir einen signifikaten Technologievorsprung. Und wir sind dennoch weitergegangen und haben noch Extrafunktionen zu R5 hinzugefügt. Zum Beispiel haben wir viel Arbeit in Agents bei synchroner Nachrichtenzustellung investiert, und das ist ein genereller Zugewinn des Notes Mailsystems, weit mehr als nur eine reine Unterstützung des SMTP Standards.
Und langjährige Markterfahrung bedeutet das Ein und Alles wenn es darauf ankommt, ein stabiles Mailsystem anbieten zu können. Unser Mailrouter ist seit zehn Jahren auf dem Markt und hat eine ganze Reihe großartiger Funktionen. Zusätzlich haben wir noch neue Funktionen hinzugefügt. Zum Beispiel haben wir neue Kontrollfunktionen eingebaut, um ungewünschte SPAM und Werbemails vom Internet ins Intranet auszufiltern. Wir haben ebenfalls auf unsere cc:Mail Kunden gehört und Funktionen hinzugefügt um Mails zurückzuschicken oder die Priorität zu ändern, so daß die Nachricht, abhängig von ihrer Größe, z.B. nur Nachts gesendert wird. Dies sind alles Einstellungen im Domänen-Konfigurationsdokument.
Was ist sonst noch Neu im Router ?
Generell gesagt haben wir den Router so erweitert, daß er sowohl via SMTP als auch via NRPC (Notes Remote Procedure Calls) routen kann. Internet Standards wie SMTP sind so designed, daß sie lediglich festlegen, wie Mail von einer Domäne in die andere gelangt, aber sie tun rein gar nichts um festzustellen, wir die Nachricht zum Endbenutzer zugestellt wird, nachdem sie in der Domäne angekommen ist. Wenn Sie also z.B. noch viele verschiedene Protokolle wie z.B. SPX benutzen und die Mails auch hierüber geleitet werden müßen, bietet Ihnen SMTP nicht viel. Notes RPC hingegen unterstützt SPX als auch X.25 und NetBIOS. Unser Router kann also die MIME Mail ohne Konvertierung trotzdem zustellen, was Ihnen andere Mailsysteme einfach nicht bieten. Diese Flexibilität ist das, was die IS Administratoren lieben, denn die wissen nie, mit welcher anderen Firma demnächst fusioniert wird und mit welcher zusätzlichen Infrastruktur dann gearbeitet werden muß. Für sie ist es eine Frage der Betriebskosten. Ein weiteres Beispiel unserer harten Arbeit um diese Betriebskosten zu senken ist die eigentliche SMTP Konfiguration. Wir haben sie auf ein Konfigurationsdokument minimiert.
Wie sieht es mit der Routerperformance aus ?
Wir haben lange an der Performance unseres Routers gearbeitet. Wir haben die größtmögliche Parallelität eingebaut, die heute möglich ist. Zum Beispiel benutzen wir jetzt mehrere Instanzen von mail.box Dateien gleichzeitig (in welchen geroutetes mail in transit kurzfristig zwischengespeichert wird.) Das warten des Routers für den Zugriff auf eine einzige mail.box Datei ist eine der größten Flaschenhälse in punkto Routerperformance. Die Verwendung von mehreren mail.box Dateien mit verteiltem Zugriff darauf elimiert dieses Problem.
Unser Router war schon immer Multi-Threaded, aber Nachrichtentransfers zu jeweils anderen Servern wurden immer nur mit jeweils einem Thread durchgeführt. In R5 haben wir jetzt auch mehrere Threads zwischen den gleichen Endpunkten, so daß zum Beispiel eine große Nachricht nicht mehr viele andere kleinere Nachrichten blockiert. Das erhöht speziell dann den Durchsatz wenn wir gleichzeitig Nachrichten für andere oder älterne Clients konvertieren müssen.
Des weiteren haben wir jetzt auch mehrere Zustellungs-Threads. Früher konnten z.B. Agents für neue Mails immer nur asychron ausgeführt werden. Dies war ein Problem, denn abhängig davon was die Agents getan haben, konnte es eine lange Zeit dauern bis diese Agents abgearbeitet waren, was in diesem Falle die Mailzustellungsperformance beeinträchtigt hatte. Jetzt, mit mehreren Zustellungs-Threads kann man einen synchronen Mail Agent benutzen, ohne daß die Routerperformance für alle anderen negativ beeinträchtigt wird.
Noch weitere neue Routerfunktionen ?
Diese hier mag ich ganz besonders: Man kann jetzt vordefinierte Regeln beim Empfang neuer Mails ablaufen lassen. Die sind alle direkt in C programmiert und daher extrem schnell. Es gibt vier verschiedene Arten von Regeln und man kein ein Selektionskriterium definieren, für welche Mails die Regeln gelten sollen. Zum Beispiel basierend darauf wer der Absender der Mail ist oder was auch immer das Kriterium sein soll. Die Regel kann so definiert werden, daß dann das Mail gelöscht wird, in einen Ordner kopiert oder die Priorität geändert wird. Wenn man also Mitglied einer Mailing-List ist, kann man diese Nachrichten automatisch in den ensprechenden Ordner legen lassen.
Eg gibt auch noch eine neue "Pull" Funktion im Router mit welcher wir Mails abholen können. Früher ging das nur über das X.PC Protokoll und wurde "Opportunistisches Routing" genannt. Jetzt funktioniert das über alle von Notes unterstützten Protokolle, einschließlich SMTP über TCP/IP, so daß man periodisch beim Service Provider wartende Mails abholen kann. Wir haben auch jede Menge
an der IMAP Performance gearbeitet. Echte MIME Unterstützung alleine schon ist hier ein großer Zugewinn -- Wir haben jetzt die Performance schon mehr als verdoppelt und sind sicherlich immer noch nicht damit fertig.
Was bringt die neue Unterstützung für direkte Internetadressierung den Benutzern ?
Direkte Internetadressierung bedeutet, daß jeder Benutzer gleichzeitig eine Notes e-mail Adresse und eine Internet Adresse haben kann. Abhängig davon, wie es im Unternehmen implementiert ist, kann man die eine oder andere als Hauptadresse benutzen, oder sogar beide. Zusätzlich liefern wir die Administrationswerkzeuge um die Einzigartigkeit aller neuen Internetadressen zu gewährleisten und diese auch programmatisch zu generieren.
Man kann also ein Muster festlegen, in welchem z.B. jeder Benutzer innerhalb des Unternehmens der erste Buchstable des Vornamens, gefolgt von den ersten zehn Buchstaben des Nachnamens den ersten Teil der RFC 821 Adresse darstellt, dem wir dann ein @ Zeichen mit der Domäne hinzufügen. Der Administrator kann mit den neuen Werkzeugen die Benutzer so registrieren und auch existierende Benutzeradressen damit pflegen, um sicherzustellen, daß niemand seine Adresse geändert hat oder eine Adresse benutzt welche schon vergeben ist.
Betrifft dieses neue Adressieren schon existierende Benutzer ?
Wir haben viel Zeit in Rückwärtskompatibilität investiert, so daß wenn neue Internet Adressen vergeben werden, die alten Applikationen weiterhin korrekt funktionieren. Jede Nachricht welche wir erzeugen hat sowohl eine Notesadresse als auch eine Internetadresse -- abhängig davon, ob die Nachricht über SMTP versandt wird, wählen wir die richtige Adresse aus für das jeweilige Protokoll. Wenn die Nachricht über SMTP mit der Internetadresse gesendet wird und von einem Domino Server emfangen wird, wissen wir die eingebettete Notesadresse, so daß die existierenden Workflowapplikationen weiterhin funktionieren.
Gibt es einen Vorteil abgesehen von der Rückwärtskompatibilität, zwei verschiedene Adressen zu benutzen ?
Ja, den gibt es. Die Notesadressierung funktioniert so, daß beim Sender bestimmt wird, welchen Pfad die Nachricht nehmen soll, oder ein Administrator kann Domänendokumente definieren, welche festlegen, wie die Nachrichten zur richtigen Domäne gelangen. Im Internet hingegen wird immer vorausgesetzt, daß alle Domänen miteinander verbunden sind. Wenn man will, daß Nachrichten von Domäne A zur Domäne C gehen, dann verbindet man sich einfach mit Domäne C, welche in der Adresse angegeben ist, und liefert die Nachricht einfach ab. Mit Notes Mail muß man das nicht machen -- man kann die Domäne B dazwischenhaben und die Nachricht dann an Domäne C übermitteln lassen. Der Vorteil hier ist, daß man nicht unbedingt ein komplett verbundenes Netzwerk braucht, was oft wünschenswert ist.
Wir erlauben also immer noch Mail von einem Notes Benutzer an den anderen zu schicken, ohne einen Kompromiß zwischen beiden Ansätzen eingehen zu müssen. Jeder hat zwei Adressen und man kann jede davon benutzen. Wenn die Internetadresse benutzt wird -- super, wir verbinden uns mit Domäne C und liefern die Nachricht ab. Wenn die Notesadresse benutzt wird, dann wissen wir ebenfalls was damit zu tun ist. Es liegt ganz am Administrator, welche Art der Routing Infrastruktrur eingesetzt werden soll. Wir sind flexibel.
Wie sieht's mit LDAP und Directory Interoperabilität aus ?
Es gibt verschiedene Stufen von Directory Interoperabilität und LDAP spielt darin eine Schlüsselrolle, damit es auch wirklich funktioniert. Ultimativ gesehen wollen wir weitergehen in der Interoperabilität zu etwas, was wir heute
"Interchangeability" nennen -- Die Möglichkeit, ein Directorysystem gegen ein anderes auszutauschen. Zum Beispiel möchte ein Kunde die Sicherheitsinfrastruktur unseres Directories benutzen und gleichzeitig mit anderen LDAP Directories arbeiten. Das ist deren erste Sorge, und sie möchten wissen, wie LDAP Referrals und Adressierungsanfragen für Mail in deren Directoryumgebung funktionieren. Wir tun das für sie mit dem Domino Directory. Nach einiger Zeit jedoch könnte der Kunde sich dazu entscheiden, das Domino Directory als
das
primäre Enterprise Directory zu benutzen, oder sie wollen unser Directory überhaupt nicht benutzen. Wir möchten erreichen, daß beides möglich ist.
Was wurde dazu unternommen ?
Wir haben LDAP V3 Unterstützung hinzugefügt, so daß man sowohl Informationen lesen als auch schreiben kann, anstatt nur lesen. Unser generelles Ziel ist das Domino Directory
das
beste Directory für alle möglichen Anwendungen zu machen, nicht nur für Notes Anwendungen. Um das zu erreichen, muß man nicht-Notes Anwendungen erlauben, nicht nur zu lesen und zu schreiben, sondern auch deren eigene Applikationsdaten in unserem Directory abzulegen. Man muß "Extensible Schema" Unterstützung bereitstellen, damit diese Applikationen ihre eigenen Objekte im Directory administrieren können. Und genau das haben wir in R5 getan.
Kannst Du ein Beispiel für "Extensibe Schema" Directoryunterstützung geben ?
IBM hat eine Reihe von Windows NT BackOffice Applikationen, zum Beispiel DB2, und diese Applikationen arbeiten mit LDAP Directories. Hier wird IBM das Domino Directory benutzen, um deren Anwendungsinformationen via LDAP abzuspeichern. Die Anwendungen können bestimmte Informationen über die Benutzer abspeichern und diese Informationen dann zum Personendokument hinzufügen, wenn die Anwendung benutzt wird. Wir haben ein API definiert, damit ein Personendokument automatisch mit Subforms erweitert werden kann. Man benutzt den Domino Designer Client um das Subform zu erstellen und liefert es dann mit der Applikation aus.
Klingt so, als wenn das R5 Directory
die
primäre LDAP Quelle für das Enterprise sein kann.
Ja, das ist, was ein generelles Directory leisten muß. Wie haben außerdem den Domino HTTP Server so erweitert, daß er Clients in einem anderen Directory authentifizieren kann. Man kann jetzt also ein LDAP Directory aufsetzen, welches Informationen wie z.B. Passwörter und X.509 Zertifikate beinhaltet für Benutzer, welche kein Notes benutzen. Man kann jetzt unsere "Directory Assistance" Datenbank dazu benutzen, um "fremde" LDAP Directories zum Nachschauen zu benutzen. Das löst das Problem, Namen in ein Domino Directory eingeben zu müssen, wenn diese schon woanders definiert sind. Außerdem haben wir auch das umgekehrte wahrgemacht; wir haben erfolgreich dem Netscape Enterprise Server ermöglicht, Benutzer mit unserem Directory via LDAP zu authentifizieren.
Was ist der R5 Directory Katalog ?
Darüber sind die Leute nun wirklich begeistert. Man kann eine optimierte lokale Kopie des kompletten Enterprise-weiten Domino Directories speichern und dann eine direkte Adressenauflösung während der Eingabe haben, direkt auf dem Laptop. Sogar wenn man im Flugzeug unterwegs ist ! Und die Anforderungen an freien Festplattenplatz sind sehr gering. Zum Beispiel kann das weltweite IBM Directory, welches Iris und Lotus mit beinhaltet -- insgesamt also ungefähr 350.000 Einträge -- in knapp weniger als 50MB untergebracht werden. Damit kann man die e-mail Adresse von jemanden heraussuchen (und auch andere Dinge, je nachdem wie der Katalog konfiguriert wurde), ohne zuvor mit dem Directoryserver verbunden sein zu müssen.
Wir haben es nicht nur möglich gemacht, Adressen für Ihr ganzes Unternehmen im Flugzeug oder auch bequem von zu Hause aus zu adressieren, wir sind sogar noch einen Schritt weitergegangen: Sie können diese sogar verschlüsselt mit deren Öffentlichem Schlüssel (Public Key) schicken! Dazu ist es nicht notwendig, 350.000 Öffentliche Schlüssel von je 1 bis 4 KB auf die Festplatte zu laden, nur um verschlüsselte email zu schicken, wenn man nicht ans Netzwerk angebunden ist. Ich meine sogar, daß dieser Ansatz sogar einen neuen Meilenstein in der Skalierbarkeit darstellt. Meiner Meinung nach bedeutet daß wirklich, daß man sich auch weiterhin darauf verlassen kann, daß Lotus Notes das dominierende Produkt im Bereich "Disconnected Mail" bleiben wird.
Mit welchen LDAP Directories arbeitest Du im Moment zusammen?
Wir haben die von Microsoft, Netscape, IBM und Novell getestet. Generell kann man sagen, daß wenn das Directory LDAP unterstützt, wir es nutzen können um Benutzer zu authentifizieren. Man hat außerdem die Möglichkeit, den LDAP Server in unsere Directory Assistance Datenbank (vorher bekannt als "Master Address Book") einzutragen und damit zu einem der Server zu machen, den wir bei Directoryanfragen ansteuern. Man kann Regeln in der Directory Assistance Datenbank definieren und damit sucht es automatisch in dem richtigen Directory nach den Benutzern.
Was sind die Pläne für Microsoft's WIndows NT 5.0 Active Directory ?
Unser Integrationspunkt mit Active Directory ist LDAP. Unser Ziel ist, jedes beliebige Directory benutzen zu können, und mit R5 sind wir diesem Ziel schon sehr nahe gekommen mit der Möglichkeit, externe Authentifizierung mit fremden Directories durchzuführen. Aber LDAP ist nur der erste Schritt zum ultimativen Endziels eines kompletten und umfassenden Directories. Die nächsten Schritte bestehen darin, die Problematik zu adressieren, daß nämlich alle Directories verschiedene Schemas, Name Spaces und Zugriffskontrollmechanismen haben, und, um solche Directories daher zusammenschließen zu können, diese sich miteinander synchronisieren lassen müssen. Jeder in dieser Industrie weiß, daß es noch eine Weile dauern wird, bis all diese Standards komplett definiert und umgesetzt werden. Wir werden dabei eine große Rolle spielen. Zum Beispiel definiert LDAP keinen Standard für einen Replikationsmechanismus, und deshalb arbeiten wir mit IBM und dem Rest der Industrie zusammen mit dem IETF daran, diesen Problem zu lösen, indem wir unsere jahrelange Erfahrung mit Multi-Master Directory Replikation beisteuern und einsetzen. Danach ist dann der nächste Schritt, die Applikationen und E-mail von bestimmten festgelegten Directories abzukoppeln, damit der Kunde das Directory seiner Wahl einsetzen kann. Natürlich hoffen wir hier, daß die Wahl dabei auf das Domino Directory fällt. Das ist, was wir unter "Interchangeability" verstehen, nicht einfach nur Interoperabilität.
Du lieferst also tatsächlich mehr im Thema Messaging als nur einfache Unterstützung der Internet Standards ?
Definitiv. Wir liefern eine zusammenfassende, sichere und integrierte Architektur um die Internetprotokolle auszunutzen. Wir haben eine ganz klare Großzahl von Kunden, welche unsere Produkte einsetzen, und wir haben viel Arbeit investiert, deren Applikationen nahtlos ins Internet zu bringen. Mit R5 haben wir unser Versprechen eingelöst, ein Weltklasse Internet Mailsystem anzubieten, und wir führen diesen Markt weiterhin an mit neuen Funktionen wie dem Directory Katalog, Just-in-time Verschlüsselung, neuen Routerfeatures, Synchrone Mailagenten und Mailregeln. Das sind Tatsachen, die nicht nur unsere Interoperabilität abrunden, sondern gleichzeitig unser Kommitment darstellen, weiterhin
der
führende Anbieter in diesem Markt zu sein.
BIOGRAPHIE
John Bank-Binici ist ein Softwarearchitekt bei Iris und hat sehr viel am Design und der Implementierung des NTI Network Layers in Notes mitgearbeitet. Er kennt sich bestens mit Email-basierten Calendar und Scheduling Applikationen aus und arbeitet im Moment im Bereich Mail und Directory für R5. Nebenbei spielt er Gitarre in der Iris-eigenen Rockband "Iris Notes."