19.06.2007

Developer-Treffen am 19.06.2007

Vorstellungsrunde: neu Mitglieder von CoMa?: Gehard, Martin

Projekt auf eine kooperative Entwicklungsebene bringen: technisch, sozial, ...

LDAP Integration: Verwaltung mit unzählige Tools für die Verwaltung, aber eigentl. nur Tabelle und Baum als Zugriffsmedium.

Parallelen: selbstbeschreibene Objekte und Relationen sowie kontextsensitive Bearbeitung dieser.

Vorteil: LDAP ist in großen Organisationen in komplexen Szenarien im Einsatz und kann nicht mehr mit den Tools beherscht werden => unterschiedl. Perspektiven.

offene DM-Themen: mitunter Rechtemanagement

Abgrenzung: DM soll vollständig die Klassen und deren Instanzen abbilden können (Schema-Integration).

Ziel: Anhand eines praktischen Beispiels implementieren und dabei auch Erkenntnisse für die weitere DM-Entwicklung nutzen und Schnittstellen festigen.

zu beachten: DM unterstützt keine Mehrfachtypisierung, ist aber abbildbar! LDAP hat Property-basierte ACLs? - DM ist nur auf Typ-Ebene! Geltungsbereich für LDAP Paradigmen kann noch nicht geklärt werden - entweder Workspace-spezifisch.

Möglichkeiten für Zugriff auf LDAP:

• eigener CoperateMemory - derzeitig gibt's nur einen pro Instanz für SQL Datenbank, Problem: bei LDAP als CM müssten die zusätzlichen DM-Attribute irgendwo abgelegt werden (z.B. Positionen, Icons, Workspaces, ...) => evtl. über URI Implementierung ablegbar
• ein DataSource-Topic für die LDAP Abfrage => Duplikate werden im CM abgelegt - es gibt schon DataSourceInterface? für den LDAP Zugriff. DataSource? bietet eine definierte Schnittstelle mit Hooks (Callbacks) die vom Framework aufgerufen werden (Ableitung von LiveTopic?. => beide Szenarien müssen konzeptioniert werden und verglichen werden, um Vor- und Nachteile abzuwägen bzw. eine Entscheidung zu treffen

Anforderungen:

• LDAP Objekte mit anderen Daten assoziieren
• Daten sollen live zur Verfügung stehen (nicht Ereignis-gesteuert) => Memory live Zugriff
• Offline-Arbeiten, z.B. komplizierte LDAP-Änderung durchführen und dann zu einem bestimmten Zeitpunkt veröffentlichen => DataSource? ist in Memory repliziert Wünschenswert wäre, dass die DataSource? beide Varianten unterstützt.
• Dateisystemberechtigungen mit LDAP-ACLs? verwalten, z.B. welche Dateien darf eine Gruppe lesen. => weitere DataSource? FileSystem?!
• aggrigierte Aktionen, z.B. beim Anlegen eines Benutzers für Samba muss eine SID erzeugt und das Passwort in mehrere Felder mit unterschiedl. Algorithmen hinterlegt werden => Funktionen oder Hooks schemaspezifisch hinterlegen (Stichwort Custom Implementation für LDAP-Topic-Typen)
• Assosiationen im LDAP ändern => Änderung an LDAP weitergeben

Schlüsselkomponente könnte URI-Implementierung sein.

LDAP-Relationstypen müssen in DM hinterlegt werden:

• zwei Arten von Gruppen / Benutzer Zuordnung
• Refferal
• Alias
• Parent / Child

Bespielanwendung mit bisheriger LDAP-Anbindung: install/examples/ldap

Voraussetzung für die LDAP-Integration sind die RealationTypeTopics?, da ohne diese keine Relation zw. LDAP und anderen Instanzen mögl. wäre.

LDAP-Weg: Browser -> Editor -> Admin-Tool

AIM: Umstellung auf Logger (System.out.println loswerden) => Vorteil: Umleitung der Ausgaben in beliebigen Logs

AIM: Synchronisation zw. DM-Instanzen mit LDIF über LDAP.