-
Die
vorliegende Erfindung bezieht sich auf ein System und ein Verfahren
zur Realisierung von Transaktionen, wobei Steuerelemente (controls)
eines LDAP-Protokolls verwendet werden. Insbesondere bezieht sich
die vorliegende Erfindung auf ein System und ein Verfahren zur Sicherung
der Konsistenz voneinander abhängiger
Eintragungen in einem Verzeichnis-Informationsbaum (Directory Information Tree)
(DIT), wenn Eintragungen mit Hilfe eines Verzeichniszugriffs-Protokolls,
insbesondere mit dem LDAP V3 (Lightweight Directory Access Protocol), aktualisiert
oder erweitert werden.
-
In
der Informationstechnologie definieren Protokolle Regelmengen, die
die Art und Weise der Datenübertragung
zwischen Computern bestimmen.
-
LDAP
V3 ist ein Protokoll, das für
den Zugriff auf Informationen bestimmt ist, die in einem DIT (Verzeichnis-Informationsbaum)
gespeichert sind. LDAP V3 ist ein vorgeschlagener Internet-Standard
und in IETF RFC Nr. 2251 veröffentlicht.
LDAP V3 ermöglicht
es LDAP-Clients, Anfragen (requests) zur Suche und/oder zum Aktualisieren
von Eintragungen in dem DIT an einen LDAP-Server zu schicken. Der LDAP-Server
führt die
Anfrage des Clients aus und sendet eine Antwort zurück, die
einen Rückkehrcode enthält.
-
LDAP
V3 erlaubt nur unteilbare Anfragen. Eine einzelne Anfrage, die zu
einer Folge von Anfragen gehört,
wird unabhängig
von den anderen ausgeführt.
Insbesondere hebt der LDAP-Server die Auswirkungen der Anfragen,
die bereits erfolgreich ausgeführt
wurden, nicht auf, wenn eine Anfrage der Folge fehlschlägt.
-
LDAP
V3 erlaubt sogenannte Steuerelemente: LDAP-Anfragen können um
zusätzliche
Informationen, nämlich
um einen Namen und einen Wert für das
Steuerelement erweitert werden. Der Name des Steuerelementes ist
ein eindeutiger LDAP-Objektkennzeichner
(OID). Der LDAP-Server muss entscheiden, wie eine Anfrage, die Steuerelemente
enthält,
zu behandeln ist. Der LDAP-Client kann festlegen, dass der LDAP-Server
ein Steuerelement erkennen muss (das Steuerelement ist kritisch)
oder aufgefordert wird, ein Steuerelement zu erkennen (nicht kritisch).
Der LDAP-Server kann auch zu den Antworten, die er an die LDAP-Clients
schickt, Steuerelemente hinzufügen.
-
Wir
setzen voraus, dass zwei Eintragungen A und B in dem DIT stark voneinander
abhängen,
in der Weise, dass die Eintragung B immer aktualisiert werden muss,
wenn die Eintragung A aktualisiert wird. Wenn ein LDAP-Client zwei
aufeinanderfolgende Aktualisierungsanforderungen RA (für die Eintragung
A) und RB (für
die Eintragung B) an den LDAP-Server
schickt, und RA ist erfolgreich, und RB schlägt fehl, dann müssen die
Auswirkungen von RA zurückgesetzt
werden, um den DIT konsistent zu halten.
-
Die
typische Lösung
für dieses
Problem in der Computertechnologie wird als Transaktion bezeichnet:
eine ganze Folge von Anfragen wird ausgeführt, als ob es sich um eine
einzige unteilbare Anfrage handelt. Entweder wird die ganze Anfragefolge
erfolgreich ausgeführt,
oder es wird keine der Anfragen ausgeführt. Eine Transaktion kann
explizit geöffnet, explizit
geschlossen (commit) oder explizit zum Scheitern gebracht werden
(rollback).
-
LDAP
V3 enthält
das Transaktionskonzept nicht. Bisher können LDAP-Clients keine Transaktionen
auf einem LDAP-Server laufen lassen, da LDAP V3 keine syntaktischen
Mittel enthält,
um mit Transaktionen zu arbeiten.
-
Die
Zusammenfassung des japanischen Schrift
JP 11096062 zeigt ein Verzeichniszugriffs-Verfahren
zur Sicherung der Konsistenz von Verzeichnisinformation. Das Verfahren
beruht auf einem Verzeichnisserver und einem Client, die durch ein
Netzwerk miteinander verbunden sind. Eine Datenbank zur Speicherung
und zur Verwaltung der Verzeichnisinformationen ist mit dem Verzeichnisserver
verbunden. Der Verzeichnisserver besitzt einen nicht auf Transaktionen
orientierten Verarbeitungsteil, um die jeweiligen Zugriffsanfragen
als eigenständige
Aktion zu verarbeiten. Ein Transaktionsverarbeitungsteil verarbeitet
eine Folge von Zugriffsanforderungen als eine einzelne Transaktion.
Eine Tabelle zur Verarbeitung von Phasen speichert eine Verarbeitungsphase
für jede
Verbindung mit dem Client. Auf der Grundlage der gespeicherten Verarbeitungsphase
liefert ein Phasenverwaltungsteil die akzeptierte Zugriffsanforderung
an den nicht auf Transaktionen orientierten Verarbeitungsteil oder
an den Transaktionsverarbeitungsteil. Die Darstellung zeigt nicht,
wie das Verzeichniszugriffs-Verfahren der Erfindung innerhalb eines
vorhandenen Protokolls benutzt werden kann, ohne das Protokoll selbst
anzupassen.
-
-
Es
ist Aufgabe der vorliegenden Erfindung, eine Menge von Regeln bereit
zu stellen, die ein einfaches Verfahren für die Arbeit mit Transaktionen
innerhalb eines LDAP Protokolls ergeben, ohne das Protokoll selbst
zu erweitern.
-
Diese
Aufgabe wird durch die Eigenschaften der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen
der vorliegenden Erfindung werden in den Unteransprüchen niedergelegt.
-
Die
vorliegende Erfindung beschreibt ein System und ein Verfahren zur
Realisierung von Transaktionen innerhalb eines LDAP Protokolls,
das für
den Zugriff auf Informationen benutzt wird. Die vorliegende Erfindung
benutzt von dem LDAP Protokoll unterstützte Steuerelemente zur Spezifikation von
Anfragen mit oder ohne Transaktion. Dies wird erreicht, indem Steuerelemente,
z. B. TransactionControl (Transaktionssteuerung) und Transaction Identifier
(Transaktionskennzeichner) (TransactionId) zu einzelnen Anfragen
hinzugefügt
werden. TransactionControl kann ein Steuerelement für das Öffnen oder
Schließen
einer Transaktion sein. TransactionId kennzeichnet jede einzelne
Anfrage, die zu einer bestimmten Transaktion gehört. Eine Transaktion wird von
einem Clientprogramm geöffnet,
indem ein TransactionControl (TxnControl) mit dem Wert NEW zur ersten
Anfrage hinzugefügt
wird. Vorzugsweise erzeugt das Serverprogramm für die geöffnete Transaktion einen Transaction
Identifier (TxnID) und gibt einen Rückkehrcode zurück, der
wenigstens einen Transaction Identifier enthält. Alle nachfolgenden Anfragen,
die zu dieser Transaktion gehören,
müssen von
dem Clientprogramm mit dem Transaction Identifier erweitert werden.
Die Transaktion wird geschlossen, indem zu der einzelnen Anfrage
TransactionControl COMMIT oder ROLLBACK hinzugefügt wird, vorzugsweise zur letzten
Anfrage. In einer bevorzugten Ausführungsform der vorliegenden
Erfindung muss eine Anfrage mit dem Steuerelement TxnControl und
dem Wert COMMIT erweitert werden, wenn der Client eine offene Transaktion
unmittelbar nach der Ausführung
einer Anfrage ausführen
möchte.
Wenn der Client eine offene Transaktion rückgängig machen möchte, ohne
dass die Anfrage ausgeführt
wurde, muss die Anfrage mit dem Steuerelement TxnControl und dem
Wert ROLLBACK erweitert werden.
-
Die
vorliegende Erfindung wird ausführlich unter
Benutzung einer bevorzugten Ausführungsform mit
Abbildungen beschrieben, wobei
-
1A eine
bevorzugte Ausführungsform einer
Client-Server-Architektur
ist, auf der die vorliegende Erfindung benutzt werden kann,
-
1B eine
weitere Ausführungsform
einer Client-Server-Architektur
zeigt, in der die vorliegende Erfindung benutzt werden kann,
-
1C–D eine
Struktur eines Verzeichnis-Informationsbaumes
zeigt, der von dem LDAP-Protokoll
benutzt wird,
-
2A–B grundlegende
Verfahren zur Realisierung einer auf dem LDAP beruhenden Transaktion
entsprechend der vorliegenden Erfindung zeigt,
-
3A–M unterschiedliches
Antwortverhalten des LDAP-Servers
zeigt, das auf den in den Anfragen enthaltenen Informationen beruht.
-
1A zeigt
eine typische Client-Server-Architektur, die von der vorliegenden
Erfindung benutzt wird. Auf dem Client-System werden eine Anwendung und ein
LDAP-Clientprogramm installiert. Die Anwendung kommuniziert mit
dem LDAP-Client, beispielsweise erzeugt und sendet sie Aktualisierungsanfragen
(Hinzufügen,
Modifizieren, Löschen
eines Eintrags in dem DIT) an das LDAP-Clientprogramm.
-
Das
LDAP-Clientprogramm kommuniziert mit einem LDAP-Serverprogramm über das Netzwerk.
-
Der
LDAP-Client und der LDAP-Server benutzen beispielsweise das LDAP-Protokoll,
das auf dem TCP/IP beruht. Das LDAP-Clientprogramm fügt zu einer Anfrage zur Eröffnung einer
Transaktion ein TransactionControl hinzu, wie durch diese Erfindung gezeigt
wird, und schickt diese Anfrage an das LDAP-Serverprogramm. Das
LDAP-Serverprogramm erzeugt eine TransactionID und gibt einen Rückkehrcode
an das LDAP-Clientprogramm
zurück, der
wenigstens diese Transaction ID enthält. Das LDAP-Clientprogramm
extrahiert TxnId aus dem Rückkehrcode
und fügt
zu jeder einzelnen Anfrage, die zu dieser Transaktion gehört, eine
TransactionID hinzu. In einer bevorzugten Ausführungsform delegiert das LDAP-Serverprogramm die
Verwaltung des DIT an Endcomputer (backends). Jeder Endcomputer
1, 2, 3 besitzt einen festgelegten DIT-Teil 1, 2, 3.
-
1B zeigt
eine weitere Ausführungsform einer
Client-Server-Architektur,
die von der vorliegenden Erfindung benutzt wird.
-
In 1B verwaltet
der LDAP-Server den DIT selbst. Anfragen können durch Pufferung oder Aufzeichnung
ausgeführt
werden.
-
Pufferung:
Das LDAP-Clientprogramm sendet eine um TransactionControl erweiterte
Anfrage an das LDAP-Serverprogramm.
Das LDAP-Serverprogramm öffnet
eine neue Transaktion durch Erzeugung einer Warteschlange, in der
alle Anfragen gespeichert werden, die zu der Transaktion gehören.
-
Wenn
die Warteschlangenbildung erfolgreich war, erzeugt der LDAP-Server
unverzüglich
eine Antwort, die an das LDAP-Clientprogramm
geschickt wird.
-
Aufzeichnung
(journalling): Das LDAP-Clientprogramm sendet eine um TransactionControl
erweiterte Anfrage an das LDRP-Serverprogramm. Das
LDAP-Serverprogramm öffnet
eine neue Transaktion, erzeugt einen TransactionId und führt diese Anfrage
unverzüglich
aus. Der Zustand der Daten des Verzeichnis-Informationsbaums vor
der Ausführung
dieser Anfrage wird in einem nichtflüchtigen Speichermedium gespeichert.
-
1C zeigt
einen DIT, wie er vom LDAP benutzt wird. Der DIT besteht aus Eintragungen,
z. B. countryName (Landesname), organizationName (Name des Unternehmens),
organisationUnit (Abteilung des Unternehmens), commonName (Eigenname).
Jede Eintragung gehört
zu einer Objektklasse (z. B. 'person'). Die Objektklasse
bestimmt Attribute. Attribute besitzen werte eines bestimmten Typs.
-
1D zeigt
die Struktur einer Adresse der Eintragung in den DIT. Die Adresse
ist ein charakteristischer Name (DN). Die Adresse einer Eintragung verkettet
alle RDNs auf dem Pfad von der Eintragung bis zur Wurzel. Das DN-Suffix
bezeichnet den Unterbaum.
-
2A zeigt
das grundlegende Verfahren zur Realisierung von Transaktionen, die
von dem LDAP entsprechend der vorliegenden Erfindung unterstützt werden.
Um eine Transaktion auszuführen, die
die Folge R1 R2 ... Rn von LDAP- Aktualisierungsanforderungen
enthält,
muss ein LDAP-Client das Folgende tun:
Hinzufügen des
Steuerelementes TransactionControl mit dem Wert NEW zur Anfrage
R1, um eine neue Transaktion zu öffnen.
Das Steuerelement TransactionId darf nicht festgelegt werden.
-
Alle
nachfolgenden Anfragen R2 ... Rn müssen (wenigstens) um das Steuerelement
TransactionId erweitert werden, das vom LDAP-Server erzeugt wird.
Der Wert des Steuerelementes TransactionId muss ein gültiger ID
für eine
offene Transaktion sein. Der LDAP-Server sendet eine Antwort, die
einen solchen Id enthält,
wenn eine neue Transaktion eröffnet wird
(siehe unten).
-
Wenn
ein LDAP-Client eine offene Transaktion unmittelbar nach der Ausführung von
Rn abschließen
möchte,
muss er Rn mit dem Steuerelement TransactionControl und dem Wert
COMMIT erweitern. Das Steuerelement TransactionId muss auch mit
einem geeigneten Wert festgelegt werden.
-
2B zeigt
das gleiche Transaktionsverfahren wie 2A, aber
mit dem Steuerelement TransactionControl ROLLBACK.
-
Wenn
ein LDAP-Client eine offene Transaktion zurücksetzen möchte, ohne dass Rn ausgeführt wurde,
muss er Rn mit dem Steuerelement TransactionControl und dem Wert
ROLLBACK erweitern. Das Steuerelement TransactionId muss auch mit
einem geeigneten Wert festgelegt werden.
-
Wie
oben dargelegt wurde, sind wenigstens die folgenden Steuerinformationen
notwendig und müssen
vom LDAP-Server unterstützt
werden, um Transaktionen auszuführen:
-
TransactionControl(TxnControl):
-
- OID: Ein eindeutiger LDAP-Objektkennzeichner.
- Beschreibung: Steuerelement, das mit der ersten und der letzten
Anfrage einer als eine Transaktion zu betrachtenden Anfragefolge
benutzt wird.
- Kritikalität
(criticality): immer kritisch.
- Mögliche
Werte: der Wert ist genau eine mit dem Zeichen 0 abgeschlossene
Zeichenkette im UTF-8-Code, die genau eine der Zeichenketten (Worte)
NEW, COMMIT oder ROLLBACK darstellt. Die Groß- oder Kleinschreibung dieser
Zeichenketten spielt keine Rolle.
-
TransactionId(TxnId):
-
- OID: Ein eindeutiger LDAP-Objektkennzeichner.
- Beschreibung: gibt den Transaktions-ID an, der der Transaktion
zugeordnet ist, von der die Anfrage einen Teil ausmacht.
- Kritikalität:
immer kritisch.
- Mögliche
Werte: der Wert ist genau eine mit dem Zeichen 0 abgeschlossene
Zeichenkette im UTF-8-Code, die einen nichtnegativen Wert ungleich
null im Format einer long int – Dezimalzahl
(kleiner oder gleich 2.147.483.647 = (2^31)–1) darstellt, der den Transaktions-Kennzeichner
darstellt. (Es sind nur Werte zulässig, die vorher vom LDAP-Server
empfangen wurden – alle
anderen werden zurückgewiesen).
-
LDAP-Aktualisierungsanforderungen
sind Modify, Add, Delete und ModifyDN.
-
3A zeigte
unterschiedliches Antwortverhalten des LDAP-Servers auf der Grundlage der in den
Anfragen enthaltenen Informationen.
-
Dies
ist ein Beispiel für
den Standardfall im LDAP V3: es ist keine Transaktionsunterstützung ist verfügbar. Alle
Anfragen werden nacheinander ausgeführt. Die einzelnen Anfragen
haben, vom LDAP-Server aus gesehen, keine Beziehungen zueinander
(siehe 3A).
-
Wenn
seitens des LDAP-Servers/Endcomputers keine Transaktions-Einrichtungen
verfügbar sind,
muss der LDAP-Server
verfolgen, ob eine einzelne Anfrage, die zu einer Folge von miteinander
in Beziehung stehenden Anfragen fehlschlägt. Im Falle eines Fehlschlagens
einer Anfrage muss der LDAP-Client die Anfragen manuell aufbauen,
die die alten Daten wiederherstellen (siehe 3B). Die
Anfrage R enthält
weder TransactionControl noch TransactionId: R wird als einzelne
unteilbare Anfrage ausgeführt.
Keins der Steuerelemente TransactionControl oder TransactionId wird
zur Antwort hinzugefügt
(siehe 3C).
-
Eine
Anfrage R, die keine Aktualisierungsanforderung ist und entweder
TransactionId oder TransactionControl oder beides enthält: R wird
nicht ausgeführt,
und die Antwort enthält
den Rückkehrcode "unwillingToPerform", Keins der Steuerelemente TransactionControl
oder TransactionId wird zur Antwort hinzugefügt (siehe 3D).
-
Die
Anfrage R enthält
wenigstens TransactionControl mit einem syntaktisch ungültigen Wert: wie
in RFC 2251 festgelegt. R wird nicht ausgeführt.
-
Die
Anfrage R enthält
wenigstens TransactionId mit einem syntaktisch ungültigen Wert:
wie in RFC 2251 festgelegt. R wird nicht ausgeführt (siehe 3E).
-
Die
Anfrage R enthält
wenigstens TransactionId mit einem Id, der keine offene Transaktion
bezeichnet: R wird nicht ausgeführt,
und die Antwort enthält
den Rückkehrcode "unwillingToPerform". Es wird keines
der Steuerelemente TransactionControl und TransactionId zur Antwort
hinzugefügt
(siehe 3F).
-
Die
Anfrage R enthält
TxnId mit einem gültigen
Id, aber sie enthält
nicht TransactionControl:
R ist auszuführen. Wenn R erfolgreich ausgeführt werden
kann, wird TransactionId mit dem geeigneten Id zur Antwort hinzugefügt. TransactionControl
ist nicht in der Antwort enthalten. Wenn R fehlschlägt, werden
alle Auswirkungen, die von Anfragen verursacht wurden, die zu der
durch Id gekennzeichneten Transaktion gehören, zurückgesetzt, die durch Id gekennzeichnete
Transaktion wird geschlossen, und die Antwort wird um TransactionId
(Wert Id) und TransactionControl (Wert ROLLBACK – siehe 3G) erweitert.
-
Die
Anfrage R enthält
TransactionId mit einem gültigen
Id, und es wird TransactionControl mit dem Wert "NEW"R
ausgeführt.
Die durch Id gekennzeichnete Transaktion bleibt offen. Die Antwort
wird um TransactionId (Wert Id) und TransactionControl (Wert NEW – siehe 3H)
erweitert.
-
Die
Anfrage R enthält
TransactionId mit einem gültigen
Id und TransactionControl mit dem Wert COMMIT:
R ist auszuführen. Wenn
R erfolgreich ausgeführt werden
kann, werden TransactionId (Wert Id) und TransactionControl (Wert
COMMIT) zur Antwort hinzugefügt,
und die durch ID gekennzeichnete Transaktion wird geschlossen (d.h.
bestätigt).
Wenn R fehlschlägt,
werden alle Auswirkungen abgeschlossen, die von Anfragen verursacht
werden, die zu der durch Id gekennzeichneten Transaction gehören, und
die Antwort wird um TransactionId (Wert Id) und um TransactionControl
(Wert ROLLBACK – siehe 3I)
erweitert.
-
Die
Anfrage R enthält
TransactionId mit einem gültigen
Id und TransactionControl mit einem Wert ROLLBACK. R wird nicht
ausgeführt.
Alle Auswirkungen, die von Anfragen verursacht wurden, die zu der
durch Id gekennzeichneten Transaktion gehören, werden zurückgesetzt,
die durch Id gekennzeichnete Transaktion wird geschlossen, und die
Antwort wird um TransactionId (Wert Id) und TransactionControl (Wert
ROLLBACK – siehe 3J)
erweitert.
-
Die
Anfrage enthält
TransactionId nicht, enthält
aber TransactionControl mit dem Wert NEW: Es wird eine neue Transaktion
mit dem Kennzeichner Id geöffnet.
Wenn diese Operation fehlschlägt,
wird R nicht ausgeführt,
und die Antwort enthält
den Rückkehrcode "unwillingToPerform". Die Antwort wird
um TransactionControl (Wert NEW) erweitert. Das Steuerelement TransactionId
ist nicht enthalten. Wenn eine neue Transaktion erfolgreich geöffnet werden kann,
wird R ausgeführt.
Wenn R erfolgreich ausgeführt
werden kann, werden TransactionId (Wert ID) und TransactionControl
(Wert NEW) zur Antwort hinzugefügt,
und die durch Id gekennzeichnete Transaction bleibt offen. Wenn
R fehlschlägt,
werden alle von R verursachten Auswirkungen zurückgesetzt, die durch Id gekennzeichnete
Transaktion wird geschlossen, und die Antwort wird um TransactionControl (Wert
NEW) erweitert. Das Steuerelement TransactionId ist nicht enthalten
(siehe 3K).
-
Die
Anfrage R enthält
TransactionId, und sie enthält
auch TransactionControl mit dem Wert COMMIT: R wird nicht ausgeführt, und
die Antwort enthält den
Rückkehrcode "unwillingToPerform". Keines der Steuerelemente
TransactionControl und TransactionId wird zur Antwort hinzugefügt (siehe 3L).
-
Die
Anfrage R enthält
TransactionId nicht, enthält
aber TransactionControl mit dem Wert ROLLBACK: R wird nicht ausgeführt, und
die Antwort enthält
den Ergebniscode "unwillingToPerform". Keines der Steuerelemente
TransactionControl und TransactionId wird zur Antwort hinzugefügt (siehe 3M).
-
Zusammenfassend:
die vorliegende Erfindung erlaubt es Transaktions-LDAP-Clients,
mit Nichttransaktions-LDRP-Servern
zu arbeiten, wenn Transaktionen nicht benutzt werden. Wenn in diesem Falle
Transaktionen benutzt werden, weist der LDAP-Server Transaktionen
zurück,
obwohl er von Transaktionen nichts weiß. Dies ist ein wesentlicher Vorteil
unserer Erfindung.
-
Nichttransaktions-LDAP-Clients
können
mit Transaktions-LDAP-Servern
ohne Probleme arbeiten.
-
Erweiterte
Anfragen enthalten einfach einen eindeutigen Objektkennzeichner
(OID) und einen (Zeichenketten-) Wert. (Tatsächlich enthalten sie die gleichen
Informationen wie ein LDAP V3 – Steuerelement.)
Erweiterte Anfragen sind selbständige
Anfragen, die sich nicht auf spezielle Eintragungen in dem vom LDAP-Server
verwalteten DIT beziehen. Andererseits werden LDAP V3 – Steuerelemente
zu "normalen" Anfragen wie add,
delete oder search hinzugefügt,
die sich immer auf Eintragungen oder Teile des DIT beziehen.
-
LDAP-Server
können
die Verwaltung gewisser DIT-Unterteile an sogenannte Endcomputer übertragen.
Gerade das wird von dem LDAP-Server OS/390 Security Server getan:
der gesamte DIT ist in Teilbäume
zerlegt, die von den Endcomputern verwaltet werden. Der LDAP-Server
wählt einfach
den geeigneten Endcomputer zur Bearbeitung einer Anfrage aus. Damit
er das tun kann, muss die ankommende Anfrage einen Verweis auf eine
Eintragung oder einen Unterteil des DIT enthalten.
-
Wenn
eine ankommende Anfrage keinen Verweis für den DIT enthält, kann
der LDAP-Server die Anfrage nicht an einen Endcomputer delegieren, da
kein Endcomputer geeignet ist. Dies ist der Fall für LDAP V3 – erweiterte
Anfragen. Sie können
nur von dem LDAP-Server selbst bearbeitet und nicht ohne weitere
Regeln delegiert werden. Solche Regeln können festgelegt werden: Erweiterte
Anfragen mit dem OID x werden vom Endcomputer y bearbeitet. Aber diese
Regeln sind sehr spezifisch und nicht Teil des LDAP V3.
-
Deshalb
ist die Realisierung von Transaktionen unter Benutzung von Steuerelementen
viel leichter als die Benutzung von erweiterten Anfragen. Geeignete "TransactionControls" werden einfach zu
den Anfragen hinzugefügt
und automatisch zum geeigneten Endcomputer geleitet. So ist nur
der Endcomputer verantwortlich für
die Unterstützung
der Steuerelemente und die Realisierung des Transaktionsverhaltens.
Bei dieser Lösung
muss der LDAP-Server die
OIDs der Steuerelemente nicht kennen und hat nichts mit der Unterstützung der
Transaktionen zu tun.
-
Dies
ist anders bei einer Lösung
mit erweiterter Anfrage: wenigstens der LDAP-Server muss die OIDs
der "transaktionserweiterten
Anfragen" kennen und
hat den (die) geeigneten Endcomputer zu informieren. Schlimmstenfalls
muss der LDAP-Server selbst die Transaktionen unterstützen.