LDAP klassisch ...
Ein kleines Beispiel soll die klassische Verwendung eines LDAP-Servers zeigen. Eine Applikation braucht die E-Mail -Adresse zu einem Namen. Die E-Mail-Adresse ist ein Attribut mit dem Namen mail. Dieses Attribut wird abgefragt. Listing 2 zeigt, wie wenig Zeilen dafür notwendig sind. Die äquivalente LDAP-Url sieht wie folgt aus (einfach mal im Netscape eingeben):
ldap://localhost:389/cn=Bablokb,o=CSP,c=DE?sn,mail
Einer der Vorteile von JNDI ist es, sich nicht mit den lästigen Details der Url-Kodierung auseinandersetzen zu müssen.
|
Abb. 2: Umwandlung von Objekten bei der Speicherung im LDAP-Server.
|
Vergleicht man die Beispiele 1 und 2, sieht man dasselbe Pattern. Zuerst wird die Umgebung konfiguriert, anschließend ein Initial(Dir)Context erzeugt, mit dem verschiedene Operationen (in den Beispielen die verwandten Methoden lookup() und getAttributes()) durchführbar sind.
... und für Java-Objekte
LDAP-Server sind nicht dafür ausgelegt, Java-Objekte zu speichern. Da es aber möglich ist, beliebige Schemata zu definieren, ist das kein prinzipielles Problem. Aufgabe des Service Providers ist es dabei, die Objekte beim Speichern in eine Form umzuwandeln, die der LDAP-Server versteht, und beim Lesen diese Form wieder in sein Original zurückzuübersetzen. Die folgenden Ausführungen beziehen sich auf den LDAP-Service-Provider von SUN. Die zu den Java-Objekten gehörenden Schemata werden auch mit dem Tutorial mitgeliefert.
Die einfachste Art Objekte im LDAP-Verzeichnis zu speichern ist (es), sie zu serialisieren. Dazu muss die Klasse das (Marker-)Interface java.io. Serializable implementieren. Der Nachteil daran ist, dass erstens nicht alle Klassen serialisierbar sind und zweitens die serialisierte Form sehr groß sein kann. Große Einträge sind aber für LDAP-Server nicht sehr effizient zu handhaben, insbesondere in verteilten Topologien.
Es gibt aber mehrere Alternativen zu der Speicherung in der serialisierten Form. Anstatt das Objekt selbst zu speichern, kann man eine Referenz speichern. Dazu muss das Objekt entweder eine Subklasse von javax. naming.Reference sein oder das Interface javax.naming.Referenceable implementieren. Letzteres enthält die Methode getReference(), die beim Speichern mittels DirContext.bind() aufgerufen wird.
Eine Referenz enthält alle notwendigen Informationen um das Objekt wieder erzeugen zu können. Kann das Objekt beispielsweise aus einer Datenbank-Query erstellt werden, so könnte die komplette Query (oder die relevanten Teile daraus) in der Referenz enthalten sein. Außerdem muss die Referenz wissen, welche Factory-Klasse aus diesen Informationen wieder das Originalobjekt herstellen kann.
| Whitepaper |
|---|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
|
Usage Landscape Enterprise Open Source Data Integration
Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
