Virtual Member Manager-Hierarchie

Die Hierarchie von Virtual Member Manager ist so konzipiert, dass die Integration in LDAP-Verzeichnisse, insbesondere in Verzeichnisse mit bereits vorhandenen Daten erleichtert wird.

Jedes LDAP-Verzeichnis hat einen Verzeichnisinformationsbaum (DIT - Directory Information Tree), der eine hierarchische Strukturierung der Einträge auf dem LDAP-Server ist. Jeder Eintrag auf einem LDAP-Server belegt eine Position im DIT, und der definierte Name eines LDAP-Eintrags gibt die Position des Eintrags im DIT an.

Da Virtual Member Manager vorhandene LDAP-Verzeichnisse verwenden muss (sowohl aus ihnen lesen, als auch in sie schreiben), ist die Hierarchie von Virtual Member Manager die hierarchische Strukturierung der Entitäten. Diese hierarchische Struktur bildet so weit wie möglich die LDAP-DIT-Struktur ab. Dadurch kann Virtual Member Manager verschiedene Operationen verwenden, wie z. B. "create", um einen Eintrag in ein LDAP-Verzeichnis zu stellen und dabei die bereits vorhandene DIT-Struktur berücksichtigen.

Die hierarchische Struktur von Virtual Member Manager stellt außerdem einen hierarchischen Namespace zur Verfügung. In Anlehnung an die Konzepte in LDAP-Verzeichnissen haben die einzelnen Namen im hierarchischen Namespace von Virtual Member Manager dasselbe Format, wie ein definierter Name in LDAP. In Virtual Member Manager werden die definierten Namen als "uniqueNames" (eindeutige Namen) bezeichnet. Jeder eindeutige Name gibt eine Entität in Virtual Member Manager eindeutig an, ein eindeutiger Name ist jedoch nicht statisch, d. h. er kann geändert werden, und er kann auch wiederverwendet werden. Daraus folgt, dass ein eindeutiger Name einen Eintrag nur zu einem bestimmten Zeitpunkt eindeutig definiert, nicht auf Dauer.

Wenn Virtual Member Manager mit mehreren Repositorys gleichzeitig verwendet wird, wird die Hierarchie von Virtual Member Manager unter diesen Repositorys aufgeteilt, so dass die eindeutigen Namen der unterschiedlichen Repositorys nicht kollidieren.

Beispiel: Virtual Member Manager ist mit drei Repositorys konfiguriert, von denen zwei den Typ "LDAP" und eines den Typ "Datenbank" aufweist. Die LDAP-Verzeichnisse haben die im Diagramm gezeigten DIT-Strukturen. Die entsprechende Virtual Member Manager-Hierarchie ist ebenfalls im Diagramm abgebildet:

Abbildung 1. Virtual Member Manager-HierarchieDiese Abbildung zeigt den Unterschied zwischen der LDAP-Hierarchie und der Virtual Member Manager-Hierarchie.
Der Anfang der Virtual Member Manager-Hierarchie ist ein imaginäres Stammelement, das hier nicht abgebildet ist. Die Einträge unter dem Stammelement sind einem oder mehreren Haupt-Repositorys zugeordnet.
Anmerkung: Ein Repository für Merkmalserweiterungen wird nicht als Haupt-Repository betrachtet.
Einträge aus einem Haupt-Repository befinden sich unter den zugehörigen Einträgen, die dem Repository zugewiesen sind. Wenn ein Repository keine explizite Struktur hat (wie der LDAP-DIT), ist der Repository-Adapter dafür zuständig, eventuell notwendige Transformationen auszuführen. Beispiel: Das Datenbank-Repository im Diagramm hat möglicherweise einen unstrukturierten Namespace (z. B. haben die Einträge Primärschlüssel von 1-100). Der Datenbank-Repository-Adapter ist dafür zuständig, einen eindeutigen Virtual Member Manager-Namen in einen Primärschlüssel zu übersetzen, den die Datenbank verstehen kann.

Virtual Member Manager enthält ein Konstrukt namens "Realm", das aus allen oder aus Untergruppen der Einträge aus einem Haupt-Repository unter einer Partition der Virtual Member Manager-Hierarchie besteht. Ein Realm wäre in der Abbildung z. B. dc=comA,dc=com.

Wenn ein Eintrag von Virtual Member Manager erstellt werden soll, kann der Aufrufende optional einen übergeordneten Eintrag in der Hierarchie von Virtual Member Manager angeben, unter welchem der neue Eintrag erstellt werden soll. Wenn kein übergeordneter Eintrag angegeben wurde, wird ein übergeordnetes Standardelement verwendet, das nicht für jeden einzelnen Realm verwendet wird. In Virtual Member Manager kann für jeden Entitätstyp in jedem Realm ein übergeordneter Standardeintrag konfiguriert werden.

Einträge in der Virtual Member Manager-Hierarchie unter dem imaginären Stammelement können während der Konfigurationszeit definiert oder über das Programm zur Ausführungszeit erstellt werden.
Anmerkung: Die Einträge entsprechen möglicherweise nicht den realen Einträgen in den Profil-Repositorys. Beispiel: der Eintrag "o=comC" in der Hierarchie entspricht möglicherweise nicht einem realen Eintrag im Profil-Repository für ein Unternehmen mit dem Namen C, "company C".
Das dargestellt Schema impliziert, dass wenn mehrere Repositorys Einträge mit demselben Namen haben (z. B. zwei unterschiedliche LDAP-Verzeichnisse, die beide einen Eintrag mit dem Namen o=USdiv aufweisen) und der Kunde diese Einträge direkt unter dem Stammelement in der Virtual Member Manager-Hierarchie konfigurieren möchte, müssen die Einträge in eindeutige Namen geändert werden. So kann z. B. eins der LDAP-Verzeichnisse mit dem Eintrag o=USdiv diesen auf den Eintrag o=USdiv in der Virtual Member Manager-Hierarchie zugeordnet werden. Das andere Verzeichnis mit dem Eintrag o=USdiv muss in der Virtual Member Manager-Hierarchie jedoch einem Eintrag mit einem Namen wie o=USdivision zugeordnet werden.
Anmerkung: o=USdivision ist ein eindeutiger Name, der in Virtual Member Manager konfiguriert wird, er wird jedoch nicht im LDAP-Verzeichnis als ein realer Eintrag gespeichert.

Wenn Virtual Member Manager mit nur einem Repository konfiguriert wird, belegt dieses Repository die gesamte Virtual Member Manager-Hierarchie.

Um die potenziell global eindeutige Natur der definierten Namen in LDAP zu nutzen (für alle gemäß RFC 2247, indem Internetdomänennamen verwendet werden), unterstützt Virtual Member Manager dc=com als Teil eines eindeutigen Virtual Member Manager-Namens ("uniqueName"), selbst, wenn dc=com keinen Eintrag in Virtual Member Manager angibt.

Die Hierarchie von Virtual Member Manager ist für Virtual Member Manager dasselbe, was der DIT für LDAP darstellt. Die folgenden Punkte sollten jedoch berücksichtigt werden:


Rechtliche Hinweise | Feedback