In jeder größeren Firma, für die ich arbeitete, nutzten sie LDAP als Möglichkeit, auf das zentrale Repository von Benutzerinformationen zuzugreifen, aber nur sehr wenige haben sich bemüht, das Schema um objectClasses zu erweitern, die nicht von inetOrgPerson abgeleitet sind.
Microsoft Active Directory führt umfangreiche Schemaerweiterungen durch, aber nur sehr wenige kommerzielle Produkte nutzen die Fähigkeiten von LDAP.
Liegt es daran, dass die meisten LDAP-Entwickler nicht in der Lage sind, über Benutzer hinaus zu modellieren? Finde darin einen Wert, aber hast nur nicht tief darüber nachgedacht? Habe es ausprobiert und bin auf Leistungsprobleme gestoßen? Etwas anderes? L
Ich persönlich denke, es liegt daran, dass LDAP ein Verzeichnis ist, keine Datenbank. Verzeichnisse eignen sich gut zum Nachschlagen von Personen und ihren zugehörigen Daten, aber sie eignen sich nicht besonders gut zum Nachverfolgen von relationalen Daten - so sehen viele unserer Daten aus. Tatsächlich ist unsere Verwendung von LDAP tatsächlich ein Frontend für "People" -Daten, bei dem viele Datenströme in einer einzigen Verzeichnisansicht zusammengeführt werden. Wir haben immer noch die "People" -Daten in den Backend-Datenbanken zusammen mit dem Rest unserer institutionellen Daten und haben nur LDAP (in unserem Fall ADAM) als Front-End gewählt, um eine bequeme Suche nach den zusammengeführten "People" -Daten zu ermöglichen. Jetzt, da wir auf Web-Services umsteigen, um auf diese Daten zuzugreifen, bin ich mir nicht sicher, ob es sogar sinnvoll ist, die LDAP-Route weiter zu bearbeiten (außer zur Unterstützung bestehender Dienste, die nicht aktualisiert wurden).
>Ich würde denken, dass es aufgrund von A) der Komplexität der Arbeit mit LDAP (viel höher als SQL) und B) der Tatsache, dass Ihr Produkt vollständig damit verbunden wäre. Das heißt, es würde keinen Markt außerhalb großer Organisationen mit LDAP geben. Für weniger Geld und Aufwand könnte ich eine App erstellen, die überall funktioniert.
Nun sind interne Anwendungen, die speziell für Organisationen geschrieben wurden, die Zugriff auf andere LDAP-Daten benötigen, eine andere Geschichte. Aber Sie werden offensichtlich weniger über sie hören, weil sie nicht kommerziell vermarktet werden.
Ich dachte, dass LDAP für schnelle, häufige Lesevorgänge optimiert wurde. Ich glaube nicht, dass sie für Transaktionssysteme skalieren würden.
Das relationale Modell und sein Ausdruck in SQL ist eine mächtige Sache. Ich denke nicht, dass es leicht durch LDAP oder Objektdatenbanken ersetzt werden kann.
Tags und Links active-directory ldap adam