Einführung eines Zentralen Verzeichnisdienstes zur Harmonisierung und Integration der dezentralen Verzeichnissysteme der Fachhochschule Köln

Transkript

1 Einführung eines Zentralen Verzeichnisdienstes zur Harmonisierung und Integration der dezentralen Verzeichnissysteme der Fachhochschule Köln Analyse und Konzeption Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker an der Fachhochschule Köln Abteilung Gummersbach Fachbereich Informatik Studiengang Allgemeine Informatik 1.Prüfer: Hr. Prof. Dr. Horst Stenzel 2.Prüfer: Fr. Prof. Dr. Heide Faeskorn-Woyke Holger Mauritz Matrikelnummer: Gummersbach, den 13. Februar 2003

2 Inhaltsverzeichnis 1 Einführung Problemstellung Zielsetzung Theoretische Grundlagen Lightweight Directory Access Protocol LDAP Definition eines Verzeichnisses X.500 und DAP Meta Directories Grundlagen Struktur Vor- und Nachteile Common Object Request Brokerage Architecture (CORBA) Grundsätzlicher Aufbau ORB Interface Definition Language CORBA Dienste Zusammenfassung

3 Inhaltsverzeichnis 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Anforderungen der FH Köln und mögliche Lösungen Zentrale Anforderungen - Use Cases Überblick über die vorhandenen Systeme / Schnittstellen User und Gruppen Lösung durch kommerzielle Systeme Lösung durch Verwendung von SuperX Lösung durch Neuentwicklung SuperX - Ein Datawarehouse-System für Hochschulen Allgemein Funktionsweise Möglichkeiten von SuperX Vergleich von SuperX und einem Zentralen Verzeichnisdienst Einführung von SuperX an der Fachhochschule Köln Die verwendeten Systeme Installation des Kernmoduls Installation des SOSPOS-Moduls Erstellen eigener Berichte und Statistiken Fehler und Probleme bei der Administration des Systems Organisation Fazit Neuentwicklung Allgemein Konzeption Schrittweise Einführung des Systems Zusammenfassung und Ausblick Literaturverzeichnis 78 3

4 Inhaltsverzeichnis A Shell-Skripte 80 A.1 Das angepaßte Shell Skript zum Entladen der SOSPOS Daten aus der HIS Datenbank A.2 Das angepaßte Shell Skript zum Entladen der SOSPOS Schlüsseltabellen 96 A.3 Das angepaßte Shell Skript zum Erzeugen des SOSPOS Moduls B Inhalt der CDROM 111 C Die Dokumente der X.500 Serie im Überblick 112 4

5 Abbildungsverzeichnis 2.1 Darstellung eines Directory Information Tree Komponenten einer Meta Directory Umgebung Client Server Kommunikation Erstellen von Client und Server (SII) CORBA Architektur Systeme an der FH Köln Funktionsweise SuperX Die Abfragen des SuperX SOSPOS Moduls Das PropAdmin Tool Allgemeine Darstellung des Systems

6 Tabellenverzeichnis 2.1 Anbieter von Meta Directory Lösungen Gruppen und Institute Die Tabelle Organigramm Die Tabelle Themenbaum Die Tabelle maskeninfo Die Tabelle felderinfo

7 Abkürzungs und Symbolverzeichnis LDAP: CORBA: MICO: OMG: SQL: RPC: RMI: DAP: DNS: IDS: XML: XSLT: SII: DII: IDL: ORB: OMA: Lightweight Directory Access Protocol Common Object Brokerage Architecture Mico Is Corba Object Management Group Structured Query Language Remote Procedure Call Remote Method Invocation Directory Access Protocol Domain Name Service Informix Dynamic Server Extensible Markup Language Extended Stylsheet Language for Transformations Static Invocation Interface Dynamic Invocation Interface Interface Definition Language Object Request Broker Object Modelling Architecture

8 Tabellenverzeichnis OA: BOA: POA: UML: IDL: DII: DSI: NDS: ASCII: FH: IT: bzw: JDBC: ITU: ITU-T: DOS: http: etc: HIS: Object Adapter Basic Object Adapter Portable Object Adapter Unified Modelling Language Interface Definition Language Dynamic Invocation Interface Dynamic Skeleton Interface Network Directory Services American Standard Code for Information Interchange Fachhochschule Informations Technologie beziehungsweise Java Database Connectivity International Telecommunication Union Telecommunication Standardization Sector of ITU Disc Operating System Hyper Text Transfer Protocol et cetera Hochschul Informations System GMBH 8

9 1 Einführung Die vorliegende Diplomarbeit basiert auf der Arbeit der Projektgruppe Zentraler Verzeichnisdienst unter Leitung von Herrn Prof. Dr. Horst Stenzel an der Fachhochschule Köln, die bereits einen Anforderungskatalog für die Einführung eines gleichnamige Dienstes für die FH Köln erstellt hat. Innerhalb dieser Diplomarbeit sollen weitergehende Betrachtungen zu diesem Thema angestellt werden, die dann als Grundlage für ein weiteres Vorgehen bzw. für eine Lösung der Problematik dienen können. 1.1 Problemstellung Die Verwendung unterschiedlicher Softwaresysteme für die jeweiligen Verwaltungsbereiche und Institutionen der Fachhochschule führt zu einer Verteilung der Daten über entsprechend viele Datenbanken und Verzeichnisse. Für die tägliche Arbeit ist es notwendig, aus Teilen dieser Daten Listen zu generieren, z.b Adressenlisten für Serienbriefe. Die Erstellung dieser Listen ist kompliziert, da kein einheitlicher Zugriffsmechanismus auf die Gesamtmenge der Daten zur Verfügung steht. Die Folgen daraus können fatal werden (z.b bei Verwendung von veralteten Listen, die falsche Daten beinhalten). Es entsteht aber in jedem Fall ein großer Arbeitsaufwand, um die benötigten Daten zu erhalten bzw. um diese zu aktualisieren. In vielen Fällen müssen diese Listen von Hand generiert werden oder die Anwender verwenden einen umständlichen Workaround. Der zuständige Administrator exportiert die relevanten Daten als ASCII-File, der dann vom Sachbearbeiter mit Excel weiterverarbeitet 9

10 1 Einführung wird. Teilweise werden auch Personenlisten aus bereits vorhandenen Listen generiert, so dass die resultierenden Listen schon beim Erstellen mit veralteten Daten gefüllt werden. Bei der Ausgabe von gedruckten Verzeichnissen (z.b. Telefonverzeichnis der Fachhochschule Köln), kann man davon ausgehen, dass diese zum Ausgabezeitpunkt bereits nicht mehr aktuell sind. Aus diesen und weiteren Gründen entstehen viele Verzeichnisse, die mehrfach vorhanden sind, aber getrennt gepflegt werden, z.b wird jeder Mitarbeiter sein eigenes Adressverzeichnis pflegen, da das Telefonverzeichnis nicht aktuell ist. Zusätzlich werden diverse Operationen mit Daten ausgeführt, die nicht korrekt sind. Diese Probleme sind auf die Software Entwicklungen und -Einführungen der Vergangenheit zurückzuführen. Einerseits wurden neue Systeme möglichst schnell eingeführt, andererseits wurde der Aspekt der Interoperabilität der Anwendungen erst in den letzten Jahren erkannt 1. Dabei kann man den Software Herstellern unterstellen, dass diese bewußt Anwendungen implementierten, die nicht mit den Anwendungen anderer Hersteller agieren konnten, um die Kunden dauerhaft an das Unternehmen zu binden. Anmerkung: Die hier geschilderten Probleme treten nicht nur an Hochschulen auf, sondern betreffen jede größere Einrichtung, die eine entsprechende IT-Struktur hat. Daher ist zu erwarten, dass die Software Entwicklung zukünftig deutliche Fortschritte in Richtung Interoperabilität der Anwendungen und Datenhaltungssysteme machen wird, da die großen finanzstarken Unternehmen diesem Aspekt eine gößere Beachtung schenken werden. Die daraus resultierenden Probleme an der FH Köln sollen nun durch die Einführung eines sogenannten Zentralen Verzeichnisdienstes gelöst werden. Dazu wurde eine gleichnamige Projektgruppe gegründet, die bereits die Anforderungen, die ein solcher Dienst abdecken soll, untersucht hat 2. Weiterhin wurde schon ein Datenmodell entwickelt, und die Zuständigkeiten bei der Datenpflege wurden verbindlich geklärt. 1 Dieses Problem wurde erstmals mit der Spezifikation der X.500 Serie behoben. Siehe Siehe [12] 10

11 1 Einführung 1.2 Zielsetzung Aus dem Bericht der Projektgruppe Zentraler Verzeichnisdienst gibt es bereits die folgende Zielsetzung hinsichtlich der Einführung eines gleichnamigen Dienstes an der FH Köln 3 : Projektziel ist der Aufbau einer einheitlichen, leicht zu benutzenden Datenbasis für Telefon Verzeichnis, Internet Personensuche, E Mail Verzeichnis und Verteiler, Comfax Verzeichnis, funktionsbezogene Adresslisten für Serienbriefe, Adressaufkleber und ähnliches Innerhalb dieser Arbeit soll untersucht werden, wie die oben genannten und weitere Ziele erreicht werden können. Dazu sollen besonders drei Möglichkeiten untersucht werden: 1. Kauf eines kommerziellen Produktes 2. Einführung des Informationssystem SuperX, das auf OpenSource basiert 3. Entwicklung eines neuen Systems durch Auftragsausschreibung bzw. durch FH Angehörige 3 Bericht [12] 11

12 2 Theoretische Grundlagen Der Begriff des Zentralen Verzeichnisdienstes wird heutzutage immer häufiger verwendet. Dabei geht es meistens um den Bedarf, den dieser Dienst decken soll, und seltener um Lösungen. Als Quasi-Standard hat sich mittlerweile eine Lösung mit einem LDAP-Server als zentraler Komponente herausgebildet. Weiterführende Lösungen, die wesentlich effizienter sind, sind die sogenannten Meta Directories. Diese Systeme sollen nahezu 80 Prozent aller verwendeten elektronischen Datenhaltungssysteme integrieren und verwenden können 1. Beide Begriffe LDAP und Meta Directory sind mittlerweile untrennbar mit dem Begriff eines Zentralen Verzeichnisdienstes verbunden und sollen deshalb zunächst intensiver dargestellt werden, um als Grundlage für die Betrachtungen in den folgenden Kapiteln zu dienen. 2.1 Lightweight Directory Access Protocol LDAP Definition eines Verzeichnisses Ein Verzeichnis ist ein Hilfsmittel, das zum Speichern und Organisieren von Daten benutzt wird. Dabei kann es sich um ein herkömmliches Telefon oder Branchenbuch in gedruckter Form handeln oder um ein elektronisches Adressbuch, z.b. eines E Mail 1 Nach Aussage der Firma Siemens im Dezember download/dirx_datenblatt.pdf 12

13 2 Theoretische Grundlagen Programmes 2. Ein elektronisches Verzeichnis bringt zusätzlich Regeln für den Zugriff auf die enthaltenen Daten mit. Dies beinhaltet einen Authentifizierungsmechanismus (Leserecht) und die Möglichkeit, Datensätze zu identifizieren X.500 und DAP Die Unterschiede der Software Hersteller bei der Implementierung ihrer Produkte führten in der Vergangenheit zu Inkompatibilitäten zwischen den Produkten. Deshalb wurden 1988 die X.500 Spezifikationen von der ITU-T herausgegeben 4. Dabei handelt es sich um ein Bündel technischer Dokumente, aus denen Methoden hervorgehen, wie Produkte verschiedener Hersteller auf Informationen zugreifen und diese bereitstellen können. Die Daten selbst werden dabei nicht definiert, sondern nur ein Standardformat für Organisation, Benennung und Zugriff. Mit diesen Spezifikationen wurde erstmals eine Grundlage geschaffen, welche die Bereitstellung von Informationen in Verzeichnissen behandelte. Technische Daten X.500 Richtlinien festgelegt: In den X.500-Spezifikation wurden unter anderem folgende * Verzeichnisinformationen werden in einer hierarchischen Datenbank abgelegt * Verzeichnisse sind leseoptimiert * Als Netzwork-Protokoll wird das Directory Access Protocol (DAP) verwendet, welches das OSI 7 Schichtenmodell vorraussetzt Durch diese Spezifikationen wurden die Grundlagen geschaffen, alle Informationen eines Netzwerkes in einer Datenbank abzulegen. Dabei gibt es drei Arten von Informationen: 2 [9, Seite 14ff] 3 Nach [5, Kapitel 2] 4 Alle Dokumente des X.500 Bündels: Siehe Anhang C 13

14 2 Theoretische Grundlagen 1. Informationen über Benutzer: z.b. E Mail Adressen, Name, Telefonnummer Informationen über Server und Dienste: z.b. Adressen von Netzwerkschnittstellen 3. Informationen über das Verzeichnis selbst, die der Konsistenzprüfung und Replikation dienen. 5 Da das OSI-Modell des DAP sehr Ressourcen intensiv ist, wurde das einfachere Lightweight- DirectoryAccessProtocol (LDAP) geschaffen. LDAP basiert auf dem TCP/IP-Protokoll und vereinfacht dadurch die X.500-Empfehlungen. Es verwendet Strings zur Identifizierung von Einträgen, während dies unter X.500 mit ID S erreicht wird, die nach der ASN.1 Kodierung gebildet werden. Desweiteren sind die Operationen von LDAP weniger umfangreich als die von X.500, bringen aber dennoch die gleiche Funktionalität mit. Dadurch ist LDAP allgemeiner einsetzbar als ein reines X.500 System 6. Aktuell wird LDAPv3 verwendet, das einen Quasi-Standard bei der Arbeit mit Verzeichnissen bildet. Anmerkung: LDAP ist zwar ein Teil der X.500 Empfehlungen, braucht diese aber nicht. Es genügt die wesentlich schlankere LDAP Spezifikation, die von den übrigen X.500 Spezifikationen losgelöst werden kann. Im Folgenden interessieren nur die technischen Daten des LDAP-Standards, die natürlich zum großen Teil auf den X.500-Spezifikationen basieren. Auf X.500 soll aber nicht näher eingegangen werden, da dies eher von historischem Interesse ist und für eine Eigenentwicklung von Software nicht verwendet wird. Technische Daten LDAPv3 Mit LDAPv3 wurde eine Möglichkeit geschaffen, beliebige Daten in einer hierachischen, im Netz verteilten Datenbank abzulegen. Diese Datenbank kann beliebig groß werden, repliziert werden und ist optimiert für Leseoperationen. Die Daten werden dabei im Directory Information Tree (DIT) abgelegt. Jeder Eintrag in diesem Baum wird in einem Knoten abgelegt, dem ein eindeutiger Name (Relative Distingushed Name: RDN) zugeordnet wird. 5 Vgl. [? ] 6 Nach [3, Seite 446ff] 14

15 2 Theoretische Grundlagen Abbildung 2.1: Darstellung eines Directory Information Tree Abbildung 2.1 auf Seite 15 zeigt einen Ausschnitt eines solchen Baumes, wie er für die Fachhochschule Köln aussehen könnte. An der Spitze steht ein leerer Knoten, das sogenannte Root Directory. Danach folgen beliebig viele Knoten, die Einträgen (entrys) entsprechen. Jeder Eintrag besteht aus Attributen. Jedes Attribut besteht aus einem Attributtyp (Name des Attributs) und hat einen oder mehrere Werte. Zur Charakterisierung erhält jeder Eintrag ein Objekt Klassen Attribut, über das auch die Optionalität der übrigen Attribute definiert wird. Diese Objektklassen unterstützen die Vererbung von Attributwerten. Zusätzlich haben Attributtypen eine Syntax, der die zugehörigen Attributwerte unterliegen, und bringen einfache Vergleichsregeln (matching rules) mit. Aus diesen Werten kann ein Schema gebildet werden, das den gesamten Baum defi- 15

16 2 Theoretische Grundlagen niert 7. Mit dem LDAPv3 Standard gibt es bereits einige vordefinierte Standard Objektklassen. Die wichtigsten sollen hier kurz aufgelistet werden: * country : Attribut countryname oder c * organization: Attribut organizationname oder o * organizational Unit: Attribut organizationalunit oder ou * person: Attribut common Name oder cn Die Verwendung dieser Standard-Klassen ermöglicht es, den LDAP Server global im Internet freizugeben. Man kann sich aber ein eigenes Schema definieren, um ein erweitertes Datenmodell zu erhalten. In diesem Fall sollte das Schema standardisiert oder zumindest veröffentlicht werden 8. Die meisten Standard Software Produkte wie E Mail Programme und Web Browser unterstützen LDAP allerdings nur rudimentär und können nur mit Standard Objektklassen umgehen, so dass eine Registrierung nicht unbedingt erforderlich ist. Die Anwendungen, die mit dem Schema arbeiten sollen, müssen letztlich daran angepaßt werden. Zum einfachen Datenaustausch (Import und Export) mit LDAP-Servern steht das LDAP Data Interchange Format (LDIF) zur Verfügung. Dabei handelt es sich um ein einfaches ASCII-Dateiformat, mit dem der gesamte Baum dargestellt werden kann. Diese Methode ist wichtig, um den LDAP-Baum mit Daten aus anderen Anwendungen füllen zu können. LDAP Applikationen Die Verwendung von LDAP nimmt immer weiter zu. Alle größeren Software Hersteller haben die Bedeutung mittlerweile erkannt und unterstützen LD- AP zumindest rudimentär. So wird LDAP vor allem von Verzeichnisdiensten benutzt und dient zur Suche nach Personendaten in E Mail Programmen. 7 Nach [8] 8 Nach [? ] 16

17 2.2 Meta Directories 2 Theoretische Grundlagen Grundlagen Bei LDAP handelt es sich um die Spezifikation für ein Verzeichnis, das die Daten nach dem jeweilig definierten Schema abspeichert. In allen größeren Unternehmen gibt es aber eine Vielzahl von Verzeichnissen und Datenbanken, die miteinander inkompatibel sind, aber teilweise die gleichen Daten beinhalten. Ein -Verzeichnis beinhaltet Informationen von Personen, die auch im Telefonverzeichnis der Telefonanlagen gespeichert werden. Dadurch wird ein erhöhter administrativer Aufwand benötigt, wenn sich Daten ändern. Dies kann leicht zu inkonsistenten Daten führen. Durch die Unterschiede in der Datenhaltung ist es nicht möglich, Applikationen zu entwickeln, die mit der gesamten Datenbasis des Unternehmens operieren können. Um diese und ähnliche Probleme zu lösen, wurden die sogenannten Meta Directories entwickelt, die alle Verzeichnisse durch ein einziges in einer einheitlichen Form mit standardisierten Schnittstellen(z.B. LDAP) darstellen sollen. Dabei handelt es sich meist um X.500-basierte Lösungen. Die vorhandenen Verzeichnisse werden über spezifische Konnektoren in ein DAP-Server-Verzeichnis repliziert und von dort über eine LDAP- Schnittstelle zur Verfügung gestellt. Zur zentralen Datenhaltung wird immer die Lösung des Herstellers verwendet. Deshalb ist an dieser Stelle keine Integration bestehender Systeme möglich. In Umgebungen mit vielen verschieden Verzeichnisdiensten und Datenbanken übernehmen Meta Directories den zentralen Zugriff auf die Gesamtmenge der zur Verfügung stehenden Daten. Dazu zählt sowohl der lesende als auch der schreibende Zugriff. Das Meta Directory übernimmt gewissermaßen die Funktionalität aller Basisverzeichnisse und stellt diese transparent dar. Für eine Applikation entspricht dies dem Zugriff auf ein Verzeichnis. Dadurch wird der administrative Aufwand für die Datenpflege auf ein Minimum reduziert. Wenn ein neuer Mitarbeiter in ein Unternehmen kommt, müssen zunächst seine Personendaten in den verschiedenen Datenbanken und Verzeichnisse eingetragen werden (z.b. E 17

18 2 Theoretische Grundlagen Mail Verteilerlisten). Zusätzlich muss dem neuen Mitarbeiter der Zugriff auf die für seine Arbeit benötigten Rechner gewährleistet werden. An dieser Stelle hat ein Meta Directory den Vorteil, dass diese Daten nur einmal an zentraler Stelle aufgenommen werden und an die untergeordneten Verzeichnisse automatisch weitergereicht werden. Wenn sich Daten ändern, z.b. durch Wechsel eines Mitarbeiters in eine andere Abteilung, werden diese Daten ebenfalls nur einmal zentral geändert und stehen dezentral in allen Anwendungen und Verzeichnissen zur Verfügung. Damit werden auch sogenannte Karteileichen vermieden, wie z.b. nicht mehr benötigte Accounts, da diese automatisch vom Meta Directory entfernt werden 9. Durch Meta Directories wird die Handhabung und Abfrage der Informationen aus den Basisverzeichnissen deutlich vereinfacht bzw. erst möglich. So kann z.b. der Abgleich von E Mail Adressen erst durch die Verwendung eines Meta Directories geregelt werden, da an einer Stelle Lotus Notes, an anderer Microsoft Exchange oder Netscape Mail verwendet wird. 9 Diese Funktionalität wird allerdings bislang nur von der Firma Siemens angeboten 18

19 2 Theoretische Grundlagen Struktur Abbildung 2.2: Komponenten einer Meta Directory Umgebung Quelle: Die Abbildung stammt aus einem White Paper der Firma IBM. siehe [11] Einen Standard oder eine exakte Definition des Begriffes Meta Directory s gibt es nicht. Aus diesem Grunde weichen die Implementationen der einzelnen Hersteller voneinander ab. Da aber die Anforderungen, die daran gestellt werden, relativ detailliert sind, ergeben sich grundlegende Gemeinsamkeiten, die im Folgenden ausgeführt werden. Ein Meta Directory ist in erster Linie dafür verantwortlich, die Gesamtmenge der Verzeichnisse (im Folgenden Basisverzeichnisse genannt) durch einen einheitlichen Zugriffs- 19

20 2 Theoretische Grundlagen mechanismus transparent darzustellen. Dazu werden die Basisverzeichnisse über spezifische Konnektoren oder Treiber abgefragt. Datenhaltung Die derzeit verfügbaren Meta Directory Implementationen verwenden einen Directory Service Agent (DSA) zur Replikation der Basisverzeichnisse. Dabei handelt es sich um einen LDAP oder X.500 Server des jeweiligen Herstellers. Für die Funktionalität des Meta Directory ist dies nicht zwingend vorgegeben, da die Informationen auch zur Laufzeit aus den Basisverzeichnissen entnommen werden könnten. Die Verwendung eines DSA kann aber als Quasi Standard vorausgesetzt werden, da alle Meta Directory Implementationen auf die X.500 Empfehlungen zurückgeführt werden können. Konfiguration Zur Steuerung des Datenflusses zwischen den Verzeichnissen bringen die Meta Directories die Möglichkeit mit, Regeln zu definieren. Dies beinhaltet z.b. die Auswahl der zu transferierenden Informationen oder das Anlegen eines Objektes in einem Verzeichnis als Folgeaktion auf das Hinzufügen eines Objektes in einem anderen Verzeichnis. Allgemein werden hier Ereignisse gesteuert. Wenn in Verzeichnis A etwas passiert, ergibt sich daraus eine Aktion in Verzeichnis B. Die Aufstellung dieser Regeln, bedeutet den größten Aufwand bei der Administration eines Meta Directory s, beinhaltet aber gleichzeitig die größte Stärke, da erst dadurch ein Automatismus zwischen den einzelnen Verzeichnissen eingerichtet werden kann. Alle Hersteller bringen zum Erstellen dieser Regeln graphische Tools mit, die diesen Vorgang erleichtern. Es ist aber in jedem Fall zunächst eine Analyse der Basisverzeichnisse sowie der darin enthaltenen Daten und der Anwendungsstruktur erforderlich. Konnektoren Die Konnektoren dienen zur Anbindung der Basisverzeichnisse an das Meta Directory. Sie beinhalten eine auf das Basissystem zugeschnittene Schnittstelle, über die dann der Zugriff erfolgt. Die Qualität bzw. die Einsatzmöglichkeiten eines Meta Directory hängt entscheidend von den mitgelieferten Konnektoren ab, da ein Meta Directory, 20

21 2 Theoretische Grundlagen das nicht alle Verzeichnisse einer Einrichtung integrieren kann, von geringem Nutzen ist. In diesem Bereich ist die Firma Siemens bereits sehr weit fortgeschritten 10. Anbieter Der Markt der Anbieter ist relativ klein aber wachsend. Ein kurzer Überblick über die wichtigsten Anbieter und ihre Produkte soll hier gegeben werden. Firma Siemens Microsoft Novell Critical Path ehemals Isidor Netscape Sun & iplanet Produkt DirX Active Directory DirXML (früher NDS) CP Netscape Directory Sun ONE Meta Directory 5.0 Tabelle 2.1: Anbieter von Meta Directory Lösungen Vor- und Nachteile Meta Directories können beliebig viele Verzeichnisse einheitlich darstellen und integrieren. Der Zugriff auf die Daten, welche in diesen Verzeichnissen gehalten werden, ist über eine breite Palette von Standard Schnittstellen möglich. Dadurch können viele Probleme bei der Arbeit mit den Basisverzeichnisse behoben werden. Die besonderen Stärken von Meta Directories liegen in der Verwaltung von X.500 oder LDAP Diensten, es gibt aber auch in einigen Fällen die Möglichkeit weitere Dienste zu integrieren z.b. durch Konnektoren zu SAP Systemen. Bei der Verwendung von weniger verbreiteten Verzeichnissen gibt es keine Konnektoren, so dass diese extra entwickelt werden müssen bzw. das Fehlen dieser Konnektoren 10 Vgl. LanLine Heft Vergleich von Meta Directory Diensten 21

22 2 Theoretische Grundlagen den Nutzen des Meta Directories vermindert. Die Integration von speziellen Systemen ist meistens nur für Produkte des gleichen Herstellers möglich. Diese Herstellerabhängigkeit wird durch fehlende Spezifikationen verursacht. Die Datenhaltung eines Meta Directories ist nicht in allen Fällen optimal. Es wird hierbei vorausgesetzt, dass der Datenzugriff überwiegend lesend erfolgt. Bei einem weniger lese lastigen Zugriffsverhalten kann ein relationales Datenbanksystem die bessere Wahl sein. 2.3 Common Object Request Brokerage Architecture (CORBA) Der CORBA-Standard beschreibt eine Middleware Architektur für verteilte Systeme. Spezifiziert wird dieser Standard von der 1989 gegründeten Object Management Group (OMG) 11. Dabei handelte es sich zunächst um die Firmen 3Com, American Airlines, Canon, Data General, Hewlett-Packard, Phillips Telecommunications N.V., Sun Microsystems und Unisys. Aktuell besteht die OMG aus über 700 Mitgliedern. Ziel der OMG ist es unter anderem, Standards zur Entwicklung und Integration verteilter objektorientierter Anwendungen in heterogenen Umgebungen zu verabschieden 12. Daraus entstand das Objekt Modell der OMG, die Object Management Architecture(OMA), aus dem wiederum der CORBA Standard abgeleitet wird wurde der erste CORBA-Standard(1.0) verabschiedet. Im Jahre 2002 kam dann der zurzeit aktuelle Standard 3.0 heraus. Im Folgenden soll eine kurze Einführung in die Funktionalität von CORBA gegeben werden, da dies in Kapitel 3.4 vorausgesetzt wird. Allerdings kann hier nur auf die ele- 11 Alle Informationen über die OMG und den CORBA Standard können auf der Homepage der OMG nachgeschlagen werden. Eine gute Einführung bietet [6, Kapitel 5]oder [7, Kapitel 5,6] 12 Nach 22

23 2 Theoretische Grundlagen mentarsten Dinge eingegangen werden, da die Spezifikation des CORBA Standards über 1000 Seiten füllt Grundsätzlicher Aufbau Das Prinzip von CORBA basiert auf Client und Server Objekten, die über den Objekt Request Broker(ORB) miteinander kommunizieren können. Dazu fragt der Client eine Objekt Referenz beim ORB an, über die dann der entsprechende Server angesprochen werden kann. Damit der ORB diese Referenz übergeben kann, muss sich der entsprechende Server vorher bei ihm registriert haben. Der ORB speichert die vom Server angebotenen Dienste (Schnittstellen) im sogenannten Interface Repository. Ein Server besteht aus einem oder mehreren CORBA Objekten. Welche Objekte der Server beinhaltet, speichert der ORB im Implementation Repository. Grundsätzlich hat ein CORBA Client zwei Möglichkeiten, mit einem Server in Verbindung zu treten: 1. Static Invocation Interface: Zum Zeitpunkt des Kompilierungsvorgangs ist die Schnittstellenbeschreibung des Servers bereits bekannnt 13. Mit diesem Verfahren können die meisten Anforderungen bei der Softwareentwicklung abgedeckt werden. 2. Dynamic Invocation Interface: Zusätzlich gibt es unter CORBA die Möglichkeit, Objekte und Server dynamisch abzufragen. Dies wird für Klienten benötigt, die zum Kompilierungszeitpunkt den zuständigen Server mit seinen Schnittstellen nicht kennen. Dazu steht auf Client-Seite das Dynamic Invocation Interface (DII) und auf Serverseite das Dynamic Skeleton Interface zur Verfügung (DSI). Grundsätzlich macht es für die einzelnen Objekte keinen Unterschied, wo die anderen sich befinden (Ortstransparenz), und wie sie implementiert sind (Unabhängigkeit vom Betriebssystem und der verwendeten Programmiersprache). Im Folgenden wird dies anhand des SII erläutert. 13 Siehe Graphik

24 2 Theoretische Grundlagen CORBA Objekt bieten die Möglichkeit der Remote Procedure Calls(RPC). Dazu stellt der jeweilige Server seine Schnittstellen über das Server Skeleton zur Verfügung. Der Client greift über den Client Stub darauf zu (siehe Graphik 2.3). Abbildung 2.3: Client Server Kommunikation Bei Verwendung des SII Ansatzes werden die gemeinsamen Schnittstellen zwischen Client und Server mit der Interface Definition Language(IDL) in einem File festgehalten. Daraus werden dann mittels eines IDL Compilers die Stub und Skeleton Files gebildet, über die dann der Datenaustausch abgewickelt wird. Der Programmierer muss sich nur um die Implementation der eigentlichen Funktionalität des Servers bzw. des Clients kümmern. Der Datenaustausch erfolgt automatisch. Datenaustausch Zum Datenaustausch zwischen Client und Server stehen spezielle CORBA Datentypen zur Verfügung. Diese entsprechen den Datentypen der Programmiersprachen, haben aber den Vorteil, dass sie von allen CORBA Objekten identisch verstanden werden. Dadurch wird der Datenaustausch unabhängig von Betriebssystem und Programmiersprachen. Die Methodenaufrufe des Clients werden vom Stub übersetzt (Marshalling), dabei werden die Client spezifischen Datentypen auf CORBA Datentypen gemappt. Das 24

25 2 Theoretische Grundlagen Server Skeleton nimmt den Aufruf entgegen. Es folgt ein erneutes diesmal Server spezifisches Marshalling. Anschließend geht eine eventuelle Antwort des Servers den gleichen Weg zurück. Abbildung 2.4: Erstellen von Client und Server (SII) Die Graphik zeigt die Vorgehensweise, mit der Client und Server unter Verwendung des SII erstellt werden [10, Seite 12] ORB Der ORB bildet, wie bereits oben erwähnt, die zentrale Anlaufstelle bei der Interprozesskommunikation zwischen CORBA Objekten. Insbesondere sorgt der ORB für die korrek- 25

26 2 Theoretische Grundlagen te Zustellung von Dienstanfragen an verteilte Objekte und die Übermittlung einer eventuell vorhandenen Antwort an den Anfragenden. Abbildung 2.5: CORBA Architektur Quelle: Internet Von K. Geihs, Uni Franfurt, mwcorba1.pdf.. Graphik 2.5 veranschaulicht das Zusammenspiel der einzelnen Elemente einer CORBA Architektur. Beim Start des Servers registriert dieser sich beim ORB. Der ORB speichert Informationen über die Dienste, die der Server anbietet, im Interface Repository. Im Implementation Repository wird festgehalten, wie der Server angesprochen werden kann. Dazu gehören Informationen wie Name, IP Adresse und Port Nummer des Servers. Wenn nun ein Client eine Verbindung zu einem Server aufbauen möchte, wird diese zunächst über das ORB Interface abgefragt. Dieser Vorgang nennt sich Binding. Der Client sendet nur die Anfrage und der ORB ist dafür zuständig, dass diese beim richtigen Dienst ankommt. Zur Verbindung zwischen ORB, Skeleton und Server Implementierung steht der Objekt Adapter zur Verfügung. Dabei handelt es sich im Prinzip um einen Teil des ORB s, der aber aus Gründen der Code Kapselung und zur Vereinfachung des Kompilierungs- 26

27 2 Theoretische Grundlagen vorgangs bei der Server Erstellung ausgelagert wurde. Dabei gibt es zwei Arten von Adaptern. Den älteren Basic Object Adapter (BOA) und den moderneren Portable Object Adapter (POA). Bei der Wahl eines ORB s sollte darauf geachtet werden, das dieser in jeden Fall eine POA mitbringt, da der ältere BOA noch zu ungenau spezifiziert war, was zu Kompatibilitätsproblemen führen kann. Für die Kommunikation zwischen den einzelnen Objekten wird das Internet Inter ORB Protocol (IIOP) verwendet, das eine konkrete Implementierung des in CORBA 2.0 spezifizierten General Inter ORB Protocol (GIOP) darstellt Interface Definition Language Mit der Interface Definition Language (IDL) steht eine Möglichkeit zur Verfügung, die Schnittstellen zwischen Client und Server in einem Vertrag zu manifestieren. Dabei ist es nicht notwendig zu wissen, in welcher Programmiersprache Client und Server implementiert werden. Für Client und Server reicht es aus, die entsprechende Schnittstelle auf der anderen Seite zu kennen. Zur Beschreibung der Schnittstellen stehen die folgenden Möglichkeiten zur Verfügung: Basisdatentypen Größe numerische, boolesche Werte und Buchstaben mit festgeschriebener Objektreferenzen Zeiger auf ein Objekt Template-basierte Typen Eigenschaften von Templatedatentypen werden über Parameter bei der Definition festgelegt, z.b typedef unsigned short Matrix [5] [5]; Benutzerdefinierte/zusammengesetzte Datentypen Zusammensetzung aus den obigen Typen. 27

28 2 Theoretische Grundlagen Module Ein Modul kann mehrere Objekte zusammenfassen, aber selbst keine Operationen oder Attribute enthalten. Module werden über das Schlüsselwort module definiert. Interfaces Objekte werden über das Schlüsselwort interface definiert, sie können im Gegensatz zu Modulen Attribute und Operationen enthalten. Operationen werden ähnlich wie in C++ definiert, allerdings muss bei Parametern angegeben werden, in welche Richtung sie gereicht werden sollen. Dafür werden den Parametern die Schlüsselworte in, out oder inout vorangestellt. Attribute können Daten eines Objektes speichern. Sie bezeichnen les- und schreibbare Werte. Attribute werden über das Schlüsselwort attribute definiert CORBA Dienste Zusätzlich zur Infrastruktur verteilter Systeme gibt es unter CORBA Dienste (CORBAfacilities oder CORBAservices), die zusätzliche Funktionalität in das Gesamtsystem bringen. Zu unterscheiden sind hierbei die horizontalen (horizontal facilities) und vertikalen Dienste (vertical facilities). Bei den horizontalen CORBAfacilities handelt es sich um Dienste für spezielle Branchen wie das Gesundheitswesen oder die Telekommunikation. Etwas allgemeiner sind die vertikalen Dienste, die Funktionalität für Informationsmanagement, Benutzerschnittstelle, Systemmanagement und Task Management zur Verfügung stellen. Explizit erwähnt werden sollen hier nur: * Der Event Service ermöglicht das Publizieren und Erhalten von Nachrichten * Der Security Service bietet die Möglichkeit der Authentifizierung * Der Object Transaction Service bietet die Möglichkeit, Transaktionen zu verwenden 28

29 2 Theoretische Grundlagen Die Verfügbarkeit dieser Dienste ist aber abhängig von der jeweiligen Implementation des ORB Herstellers. Es sind zwar alle im CORBA Standard definiert, es werden aber nicht alle angeboten Zusammenfassung Die Vorteile der CORBA Architektur liegen in erster Linie in der Unabhängigkeit von der Implementierung der einzelnen Objekte und in der Flexibilität des Systems. Die einzelnen Objekte können jederzeit ausgetauscht oder neu implementiert werden, solange sich die Schnittstellenbeschreibung im.idl File nicht ändert. Das System ist unabhängig: 1. vom Instanziierungsort: Der Client weiss nicht, wo der Server ist. 2. von der Implementierungssprache: Client und Server können in unterschiedlichen Sprachen implementiert sein. 3. vom Betriebssystem: Das zugrundeliegende Betriebssystem ist unerheblich. 4. von der Kommunikationstechnik: Für den Client ist es unerheblich, wie und in welchem Format der ORB seine Anfrage weiterleitet. Zusätzlich bringen die CORBAfacilities einen deutlichen Mehrwert in das System, so stehen bereits fertige Anwendungen für Sicherheitsaspekte bzw. für Transaktionsmanagement oder andere Anforderungen zur Verfügung 29

30 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln 3.1 Anforderungen der FH Köln und mögliche Lösungen An der Fachhochschule Köln werden verschiedene, voneinander unabhängige Verzeichnisdienste verwendet. Die wichtigsten Dienste nutzen dabei relationale Datenbanken zur Speicherung der Personendaten. Zusätzlich gibt es weitere Systeme, die aber nicht die gleiche Bedeutung haben (Vgl. Abbildung 3.1). Alle diese Dienste stellen Daten zur Verfügung, die jeweils nur über die zugehörigen Applikationen abgefragt und geändert werden können. Ein lesender oder schreibender Zugriff über mehrere Systeme ist nicht möglich. Bei der Verwaltung der Fachhochschuldaten werden Systeme der Hochschul Informations System GmbH (HIS) verwendet. 30

31 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Abbildung 3.1: Systeme an der FH Köln Die Abbildung stammt aus einem Vortrag von Hrn. Prof. Dr. Horst Stenzel anläßlich des Workshops Informations- und Verzeichnisdienste an Hochschulen am an der Heinrich Heine Universität in Düsseldorf ([13]) und zeigt die aktuell verwendeten Systeme der FH sowie solche, die eingeführt werden sollen. 31

32 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Aus den in der Problemstellung (1.1) und weiter oben genannten Gründen ist es nötig einen zentralen Dienst einzuführen, der * die gesamte Datenmenge transparent darstellt, * die zugrundeliegenden Datenbanken auf Konsistenz prüft * und Änderungen zurückverfolgt Zentrale Anforderungen - Use Cases Funktionalität Die folgende Anforderungen wurden von der Projektgruppe Zentraler Verzeichnisdienst genannt 1 : * Nachschlage- und Suchsystem für Personen, nach Name oder Namensteilen, Gremienund Organisationszugehörigkeit, Funktionen. * Generator für Namenslisten, -Verzeichnisse, -Verteiler, Telefon- und Faxlisten, Adresslisten bzw. Aufkleber für Serienbriefe; nach Einrichtungen, Standorten, Funktionen, Gremien. * Enge Beziehung mit HIS SVA für die Daten zu Mitarbeitern. * Koordinierung mit Buisy für Funktionsräume. Weitere Anforderung werden in der Machbarkeitsstudie der Firma Saxess genannt 2 : * Automatische Weitergabe von Personalstammänderungen an die jeweiligen Sekretariate. * Verfolgung der Informationsflüsse zu den Sekretariaten und Einsicht in die Aktivitätshistorie. 1 [12, Seite ] 2 [4, Seite 8ff] 32

33 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln * To-do-Listen zu Modifikationswünschen von Personalstammdaten. * Automatischer Erinnerungsdienst für unterschiedliche Ereignisse, z.b. Ablauf eines Zeitvertrages. * Änderungen von Adressen-Personaldaten erfassen und weiterleiten. * Anzeige des Vorlesungsvorzeichnisses. * Zuordnung von Räumen zu Veranstaltungen. * Meine Stammdaten ändern bzw. Änderungsanträge versenden. Technische Umsetzung * die bestehenden Systeme dürfen nicht geändert oder ersetzt werden * Es sollen keine neuen Verantwortlichkeiten für die Datenpflege entstehen. * dezentraler Zugriff. * einfache Bedienung (web-basiert). * einfache Einführung. Bei der Umsetzung ist besonders zu beachten, dass nur ein sehr begrenztes Budget zur Verfügung steht, so dass der Verwendung von kostenfreien Lösungen (Open Source Produkten) besondere Aufmerksamkeit geschenkt werden soll Überblick über die vorhandenen Systeme / Schnittstellen Die Systeme, die für die Integration der Daten von primärer Bedeutung sind, werden im Folgenden kurz aufgelistet: * HIS-SVA: Mitarbeiterverwaltung 33

34 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln * HIS-SOSPOS: Studenten und Prüfungsverwaltung * HIS-COB: Kostenstellen * Buisy: Raumbuchungssystem * TELBA/Alcatel: Verzeichnis der Telefonanlage * Univis: digitales Vorlesungsverzeichnis (noch nicht eingeführt) * LDAP: E Mail, Comfax und Accountverwaltung (wird derzeit eingeführt) User und Gruppen Aus dem Bericht der Projektgruppe Zentraler Verzeichnisdienst ergeben sich bereits die Zuständigkeiten für die Datenpflege. Daraus läßt sich ein erstes Modell für die Benutzung des Systems erstellen. User Als User wird jeder Angehörige der Fachhochschule gesetzt. Dazu gehören die Studenten und Mitarbeiter. Zusätzlich besteht die Möglichkeit spezielle Informationen für Ehemalige (Alumni) freizugeben. Die Erstellung eines Gast Accounts für Informationen, die jedermann zugänglich sein sollen, ist ebenfalls notwendig. User werden in erster Linie benötigt, um an alle potentiellen Benutzer des Systems eine Login zu vergeben. Die Rechtevergabe sollte nur in Einzelfällen über die Benutzerkennung geschehen, z.b. bei Mitarbeiter mit speziellen Aufgaben. Im Normalfall sollten die Rechte über entsprechende Gruppenzugehörigkeiten verteilt werden. Gruppen und Institutionen Die benötigten Gruppen ergeben sich aus den zu betrachtenden Informationen. Aus den Zuständigkeiten für die Datenpflege können einfach Gruppen gebildet werden, die mit den entsprechenden Rechten ausgestattet werden müssen. Es sollte grundsätzlich für jeden Teilbereich eine eigene Gruppe gebildet werden, um die Rechtevergabe sehr fein steuern zu können. In keinem Fall darf ein Benutzer durch eine 34

35 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Gruppenzugehörigkeit mehr Rechte erhalten als ihm zustehen. Aus diesem Grunde sollen die folgenden Gruppen noch nicht als endgültig betrachtet werden. Sie sollen lediglich als Grundlage für ein noch zu verfeinerndes Modell dienen. Damit die Rechtevergabe nicht zu kompliziert wird, können Gruppen zu Institutionen oder anderen Übergruppen zusammengefaßt werden. Dabei ist aber zu beachten, dass nicht jeder Mitarbeiter eines Institutes zwangsläufig die gleichen Rechte hat. Name Beschreibung Dez_1 bis 7 Mitarbeiter der Dezernate 1 bis 7 Fachbereiche Angehörige der einzelnen Fachbereiche Sg. 7.2, 4.1, 1.3, 1.2 und 1.1 Sachgebiete der Dezernate Tabelle 3.1: Gruppen und Institute Lösung durch kommerzielle Systeme Auf dem Software-Markt ist bereits eine breite Palette von Produkten vorhanden, die das Thema Zentraler Verzeichnisdienst in der einen oder anderen Form zu lösen versuchen. So gibt es im Bereich der Meta-Directories z.b DirX von Siemens 3, Network Directory Services(NDS)von Novell 4 und Active Directory von Microsoft 5. Am weitesten ausgereift ist hierbei DirX von Siemens, allerdings rechnet der Hersteller den Preis des Systems nach der Anzahl der Einträge im zugrundeliegenden X.500-Server ab (dies können leicht mehrere Millionen Einträge werden). Zusätzlich müssten die Konnektoren zur HIS erst noch entwickelt werden. Im Fall von Novell und Microsoft sind die Lösungen sehr eng an den übrigen Produkten dieser Hersteller orientiert. Im Falle von Microsoft werden sogar ausschließlich Windows-Systeme unterstützt. Die auf dem Markt vorhandenen Lösungen haben meist den Nachteil, dass sie die bestehenden Systeme ersetzen. Eine Integration 3 Siehe

36 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln von bestehenden Systemen ist nur bei der Verwendung von Meta-Directories möglich. In diesem Fall müssen allerdings erst noch Konnektoren für die HIS-Systeme entwickelt werden, da diese noch nicht vorhanden sind. Alle diese Systeme unterstützen in erster Linie die Produktpalette des Herstellers und können nur begrenzt an andere Produkte angepaßt werden. Dadurch kann bestenfalls eine Kompromißlösung an der Fachhochschule erreicht werden. Das einzige Produkt, dass laut Hersteller alle Anforderungen aus den Phasenberichten der Projektgruppe abdecken kann, ist DirX der Firma Siemens. Die entstehenden Kosten können allerdings nicht genau abgeschätzt werden. Zusätzlich zu den Kosten des Meta Directories, würde die Entwicklung von Konnektoren weitere Kosten verursachen, da dies nur vom Hersteller übernommen werden könnte. DirX bringt sehr viel Funktionalität mit, die an der Fachhochschule nicht gebraucht wird, aber im Preis des Produktes berücksichtigt wird z.b. die Integration von mobilen Endgeräten. Aus diesen Gründen macht es derzeit keinen Sinn, die Einführung eines kommerziellen Produktes weiter zu untersuchen Lösung durch Verwendung von SuperX An der Universität Duisburg wird aufgrund der oben geschilderten Probleme ein eigenes Informationssystem SuperX entwickelt. SuperX hat den entscheidenden Vorteil, dass es kostenlos zu erhalten ist und als einziges System speziell für die Arbeit mit HIS- Datenbanken entwickelt wurde. Aus diesem Grund wird die mögliche Einführung von SuperX in einem eigenen Kapitel untersucht Lösung durch Neuentwicklung Die Entwicklung eines neuen Systems bietet die meisten Vorteile: * größtmögliche Flexibilität 36

37 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln * keine Kompromisse * jede Anforderung kann abgedeckt werden. Das entstehende Softwaresystem wird allerdings so komplex, dass eine lange Entwicklungs und Einführungszeit eingeplant werden muss. Im Vergleich zu den anderen Lösungsansätzen ist eine Neuentwicklung natürlich der umständlichste Weg. Es muss aber nicht der teuerste sein. In Kapitel 3.4 wird dieser Ansatz genau spezifiziert. 3.2 SuperX - Ein Datawarehouse-System für Hochschulen Allgemein Das Projekt SuperX wurde 1995 an der Universität Karlsruhe unter der Leitung von Herbert W. Roebke entwickelt. Mittlerweile wird es an der Universität Duisburg vom SuperX- Team weiterentwickelt. Es handelt sich dabei um ein Data-Warehouse-System, das speziell auf Hochschulen zugeschnitten wurde. Die SuperX-Anwendung ist ein Open-Source-Projekt unter der Lizenz von Campus- Source und darf daher an die Bedürfnisse des jeweiligen Verwendungszweck angepaßt werden. 6 SuperX ist insbesondere dafür geeignet die verteilten Datenquellen, der an den meisten Hochschulen verwendeten HIS-Produkte zusammenzufassen und für statistische Zwecke aufzubereiten. Anmerkung: In der Dokumentation wird SuperX als Datawarehouse- System bezeichnet. Diese Bezeichnung wird deshalb im folgenden übernommen. Ob dieser Begriff zutreffend ist, soll an dieser Stelle nicht untersucht werden. 6 Lizenz siehe: 37

38 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Funktionsweise Zentrale Komponente von SuperX ist eine Informix-Datenbank, die aus den bestehenden Datenquellen der Hochschule gefüllt wird. Dazu werden Shell-Skripte benutzt, die die Export-Funktion der zugrundeliegenden Datenbanken benutzen, um einen Datenextrakt zu erstellen, der dann über die Import-Funktion in die resultierende Datenbank eingelesen wird. Die Datenabfrage funktioniert über ein Java-Servlet, das über eine Servlet-Engine (z.b.tomcat) zur Verfügung gestellt wird und ein Java-Applet an den Browser des Clients sendet (Siehe Graphik 3.2 ). Servlet Engine Superx DB JDBC Superx Servlet https Browser SuperX Applet Abbildung 3.2: Funktionsweise SuperX Module Um die verschiedenen Datenquellen der Hochschulen einzeln in die SuperX- Datenbank importieren zu können, werden Module verwendet. Zwingend notwendig ist hierbei nur das Kernmodul, das bei der Installation die für den SuperX-Betrieb notwendigen Tabellen und Prozeduren sowie das Servlet mitliefert. Zusätzlich werden das SOSPOSund das COB-Modul für die entsprechende HIS-Datenbank zur Verfügung gestellt. Die übrigen HIS-Module (Bau, Inv, Mbs und SVA) müssen von der Hochschule selbst erstellt 38

39 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln werden. Anmerkung: Laut der SuperX-Dokumentation können die oben erwähnten Module einfach eingespielt werden, um ein funktionierendes System zu erhalten. In der Praxis müssen die Installations-Skripte und die Datenbanktabellen allerdings noch angepaßt werden. Näheres dazu folgt in Abschnitt 3.3 Diese Module enthalten bereits Shell-Skripte, um die zugrundeliegende Datenbank zu entladen und entsprechend der mitgelieferten Auswertungsmöglichkeiten zu aggregieren. Dazu werden in der SuperX-Datenbank neue Tabellen zur Aufnahme der Daten und eine Reihe von Masken angelegt, die bereits eine Grundfunktionalität zur statistischen Auswertung mitbringen. Abbildung 3.3 auf Seite 40 zeigt einen Überblick über die Abfragen des SOSPOS- Moduls. Über Cron-Jobs werden diese Tabellen dann täglich aktualisiert. Zum Betrieb von SuperX sind diese Module nicht zwingend erforderlich, sie liefern lediglich erweiterte Funktionalität für die Arbeit mit SuperX. Falls keine Zusatz Module verwendet werden, muss diese Funktionalität erst noch entwickelt werden. Die mitgelieferten Auswertungsmöglichkeiten können allerdings keine der Anforderungen aus der Arbeit der Projektgruppe abdecken, so dass ein Mehraufwand in jedem Fall einzuplanen ist. In Kapitel 3.3 wird detailliert auf die praktischen Schritte zur Installation des SOSPOS Moduls eingegangen. Tabellen Zum Betrieb von SuperX sind die Tabellen des Kernmoduls notwendig. Zwei der wichtigsten sollen im Folgenden kurz beschrieben werden, da diese für die Administration des Systems von Bedeutung sind. Eine Beschreibung der weiteren Datentabellen kann im Administrator Handbuch [1] nachgelesen werden. Allerdings ist die Beschreibung der Tabellen dort leider unvollständig. 39

40 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Abbildung 3.3: Die Abfragen des SuperX SOSPOS Moduls Bei der Abbildung handelt es sich um einen Screenshot des SuperX Applets. Der zu sehende Themenbaum stellt zur Verfügung stehende Auswertungen dar. 40

41 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Organigramm Die Tabelle Organigramm ist die zentrale Tabelle zur Einordnung der verschiedenen Institute der Hochschule in ein hierarchisches Modell. siehe Tabelle3.2 superx.organigramm Feldname Typ NULL tid serial nein key_apnr char(10) ja parent char(10) ja drucktext char(50) ja name char(150) ja ebene integer ja lehre smallint ja gueltig_seit date nein gueltig_bis date nein orgstruktur integer ja Tabelle 3.2: Die Tabelle Organigramm Das Feld tid beinhaltet die interne Nummer der entsprechenden Institution oder Lehreinheit. Das Feld key_apnr entspricht der Nummer unter der die Einrichtung in den HIS Systemen geführt wird. Als Wurzel wird der key_apnr Wert der Fachhochschule Köln gewählt (aus dem HIS System). Dieser Datensatz hat als einziger Eintrag keinen parent Wert. Die übrigen Einträge haben als parent Wert den key_apnr Wert der übergeordneten Einrichtung.Dadurch ergibt sich eine Baumstruktur, in welche die Daten der Fachhochschulverwaltung eingeordnet werden. 41

42 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln superx.themenbaum Feldname Typ NULL tid serial nein name char(50) ja maskeninfo_id interger ja parent integer ja gueltig_seit date nein gueltig_bis date nein erlaeuterung char(240) ja Tabelle 3.3: Die Tabelle Themenbaum Themenbaum Die Tabelle Themenbaum enthält die Daten, aus denen der Abfragebaum den der User nach erfolreichem Login sieht, generiert wird. 7 Sie ist strukturell ähnlich zu der Tabelle Organigramm aufgebaut. Allerdings werden hier die möglichen Abfragen und Auswertungen in ein hierarchisches System eingeordnet. Bei der Tabelle Organigramm handelt es sich um die zugrundeliegenden Daten der Hochschule. Der Themenbaum beinhaltet alle möglichen Auswertungen, die im System zur Verfügung stehen. Vgl. dazu auch User- und Gruppenverwaltung bzw. Auswertungen und Masken User- und Gruppenverwaltung Aus Sicherheitsaspekten bringt SuperX ein Authentifizierungssystem mit, das Berechtigungen und Auswertungs Masken nach User Namen, Gruppen und Institutionszugehörigkeit zuordnet. Dazu gibt es ein Administrationstool, mit dem diese Einstellungen gemacht werden können. Leider ist dieses Tool dem Beta Status noch nicht entwachsen, so dass die administrativen Einstellungen besser von Hand über SQL Skripte gemacht werden. 7 Siehe auch Graphik 3.3 auf Seite40, die einen möglichen Themenbaum zeigt. 42

43 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Anmerkung: Bei dem mitgelieferten Administrations Tool handelt es sich um ein Java Servlet, mit dem einige Einstellungen in der SuperX Datenbank gemacht werden können. Die Entwicklung dieses Tools ist aber noch nicht so weit fortgeschritten, dass es eine wirkliche Hilfe für den Administrator darstellt. Es soll an dieser Stelle nur darauf hingewiesen werden, dass in Zukunft eventuell eine einfacherer Bedienung möglich ist. Siehe auch Die Leserechte eines Users werden aus den folgenden Tabellen zusammengesetzt und beziehen sich jeweils auf das Recht, eine Auswertungsmaske aus der Tabelle Themenbaum abfragen zu dürfen: 1. Tabelle userinfo: Dies ist die Basistabelle, in der die Personendaten der SuperX User gespeichert werden. 2. Tabelle user_masken_bez: Über diese Tabelle kann einem User explizit die Berechtigung für einzelne Masken erteilt werden. 3. Tabelle sachgeb_maske_bez: In dieser Tabelle werden Auswertungen mit den Einträgen aus der Tabelle Sachgebiete (Siehe Auswertungen und Masken) verknüpft 4. Tabelle user_sachgeb_bez: Hier kann man einem User die Rechte eines Sachgebietes zuteilen. 5. Tabelle user_institution: Zuordnung der Leserechte zu den Institutionen aus dem Organigramm 6. Tabelle groupinfo: Erstellen von User Gruppierungen 7. Tabelle user_group_bez: Zugehörigkeit der User zu den verfügbaren Gruppen 8. Tabelle group_masken_bez und 9. Tabelle group_sachgeb_bez: Hier werden die Rechte der Gruppen gespeichert 43

44 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Dieses System, die Rechte zu vergeben, ist für den zuständigen Administrator schwierig zu bedienen, da hier in erster Linie Handarbeit gefragt ist. In Zukunft soll dieses System allerdings vereinfacht werden 8, indem die Userrechte direkt mit dem Themenbaum verknüpft werden sollen. Nach der erfolgreichen Anmeldung am System wird für den Benutzer von SuperX ein Themenbaum mit den Auswertungen aufgebaut, für die der Benutzer Leserechte besitzt. Dazu wird durch die Stored Procedures sp_user_orga und sp_user_orga_child ein Teilbaum, basierend auf den obigen Rechtezuordnungen, generiert. Nur dieser Ausschnitt des Baumes wird vom Java Applet angezeigt. Auswertungen und Masken Das Auswertungs- bzw. Abfragesystem von SuperX basiert auf konfigurierbaren Masken. Dazu werden die benötigten Informationen in der Datenbank abgelegt und dynamisch vom Applet zu ausführbaren Abfragen zusammengesetzt. Dabei ist es möglich, die Abfragen über Parameter zu steuern. Jede Maske erhält eine eindeutige ID. Zur Darstellung der zu betrachtenden Datensätze und zur Steuerung der Abfragen über Parameter beinhalten die Masken Felder. Die Informationen zur jeweilige Maske werden auf die folgenden Tabellen verteilt. 1. Tabelle felderinfo: Jede Maske besteht aus Feldern. Diese habe eine eindeutige tid und Attribute (Vgl. Tabelle 3.5). 2. Tabelle masken_felder_bez: In dieser Tabelle werden den Masken die zugehörigen Felder zugeordnet. Das Feld Tabelle maskeninfo_id entspricht dabei dem entsprechenden tid Feld der Tabelle maskeninfo. 3. Tabelle maskeninfo: In dieser Tabelle werden die Masken definiert.siehe Tabelle sachgebiete: In dieser Tabelle können mehrere Auswertungen zu Sachgebieten (Gruppen) zusammengefaßt werden, so dass die Rechte nicht einzeln vergeben 8 Nach [Seite 42 ][1] 44

45 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln werden müssen. 5. Tabelle sachgeb_maske_bez: Zuordnung von Masken zu Sachgebieten, daraus ergibt sich die Einordnung im Themenbaum Das Feld sachgebiete_id, entspricht dem Feld tid in der Tabelle sachgebiete. Das Feld maskeninfo_id, entspricht dem Feld tid in der Tabelle maskeninfo. superx.maskeninfo Feld tid name select_stmt xil_proplist erlaeuterung cleanup_stmt Beschreibung Nummer der Maske Name der Maske SQL-Statement, das die Abfrage ausführt Hiermit werden die Felder der Ergebnismaske und ihre Attribute definiert. Darüber können das Erscheinungsbild und die Funktionalität der Felder gesteuert werden. Erläuterung SQL-Statement, das bei Beendigung der Maske ausgeführt wird. Tabelle 3.4: Die Tabelle maskeninfo superx.felderinfo Feld tid nummer typ obligatorisch Beschreibung Interne Nummer des Feldes. Nummer des Feldes integer, char oder sql zwingend(1) oder freiwillig(0) Tabelle 3.5: Die Tabelle felderinfo Die Tabelle stellt eine Auswahl der wichtigsten Felder der SuperX Tabelle felderinfo dar. 45

46 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln tid: Der Wert von tid in der Tabelle felderinfo ist abhängig vom tid Wert der Maske in der Tabelle maskeninfo. Die Felder haben ihrer Anzahl entsprechend fortlaufende Nummern, beginnend mit der tid aus maskeninfo bis tid+n-1 (n bezeichnet die Anzahl der Felder einer Maske). typ: Die Werte, die ein Feld zum Abfragezeitpunkt enthält, werden als Parameter des entsprechenden SQL Statements(sql_stmt aus maskeninfo) weitergegeben. Über den Typ des Feldes wird das Format der Weitergabe spezifiziert. Möglich sind die Werte integer, char und sql. Zusätzlich gibt es einige Felder, mit denen das Erscheinungsbild der Felder auf der Maske gesteuert werden kann Möglichkeiten von SuperX Mit SuperX können alle Datenbanken der HIS zu einer einzigen zusammengefaßt werden und über bedienungsfreundliches Frontend dargestellt werden. SuperX bietet dabei allerdings nur lesenden Zugriff auf Daten, die nicht mehr exakt denen der zugrundeliegenden Datenbanken entsprechen. Zur Weiterverarbeitung dieser Daten können diese einfach per copy and paste an Standard Office Programme weitergereicht werden. Eine Änderung von Datensätzen nicht möglich Vergleich von SuperX und einem Zentralen Verzeichnisdienst SuperX kann den Anforderungen an einen Zentralen Verzeichnisdienst in keiner Weise gerecht werden. Es ist aus auch nicht zu diesem Zweck entworfen worden. In diversen Gesprächen mit Mitgliedern der Projektgruppe und der Verwaltung wurde aber der Wunsch nach einer SuperX Einführung häufiger geäußert, so dass dies in dieser Arbeit untersucht wird. Durch die Verwendung von SuperX können einige Punkte aus den ursprünglichen Forderungen der Projektgruppe abgedeckt werden. Ebenso wie durch die Verwendung eines Meta Directories ode eines anderen Dienstes. Ein Vergleich zwischen den Systemen 46

47 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln ist nicht möglich, da diese auf unterschiedlichen Architekturen basieren. Als mögliche Lösung für die Generierung von Listen, wie sie im Vorfeld spezifiziert wurden, ist SuperX prinzipiell geeignet, da die Möglichkeit besteht, das gesamte System variabel zu konfigurieren und dadurch an die Anforderungen der FH anzupassen. Die dazu notwendigen Schritte werden im nächsten Kapitel dargestellt. 3.3 Einführung von SuperX an der Fachhochschule Köln In diesem Kapitel soll die praktische Einführung des SuperX-Systems an der Fachhochschule Köln untersucht werden. Ziel dieser Untersuchungen ist es nicht, SuperX einzuführen, sondern eine Auflistungen der dazu notwendigen Schritte zu machen, um eine Aufwandsabschätzung für eine eventuelle Einführung machen zu können. Dabei wird die Einführung von SuperX unter dem Aspekt der möglichen Lösungen für die Anforderungen aus dem Bericht der Projektgruppe Zentraler Verzeichnisdienst untersucht. Inwieweit SuperX unter anderen Gesichtspunkten sinnvoll ist, soll nicht Ziel dieser Betrachtungen sein Die verwendeten Systeme Als Basissystem wurde ein einfacher PC (Pentium III 500 MHz mit 512 MB RAM) mit einem Suse Linux Betriebssystem mit Kernel verwendet. Als Datenbankserver wurde Informix 9.30.UC2 für Linux verwendet. Zur SuperX Installation wurden folgende Files von der SuperX Homepage verwendet 9 : * kernmodul.tar.gz vom * sos_modul.tar.gz vom Zum Download ist eine kostenlose Registrierung erforderlich 47

48 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Installation des Kernmoduls Voraussetzung für die Installation des Kernmoduls sind der Zugriff auf die zugrundeliegenden HIS-Datenbanken sowie ein Informix-Server, der die SuperX-Datenbank aufnehmen soll. Zusätzlich wird ein Java Runtime Environment der Version 1.3.x oder höher benötigt. Als Webserver kann zunächst der vorkonfigurierte, mitgelieferte Tomcat-Server der Version 3.2 benutzt werden. In einem Produktivsystem sollte dies auf eine aktuelle Version des TOMCAT Servers geändert werden, da Version 3.2 nicht mehr dem aktuellen Sicherheitsstandard entspricht. Die eigentliche Installation des Kernmoduls gestaltet sich einfach und kann nach den Vorgaben aus dem SuperX-Administratorhandbuch 10 durchgeführt werden. Im folgenden werden nur die notwendige Schritte für die Installation unter einem Linux Betriebssystem beschrieben. Es ist aber auch möglich, SuperX auf Rechnern mit anderen Betriebssystemen zu installieren. Die Plattformunabhängigkeit der Programmiersprache Java, mit der SuperX implementiert ist, eröffnet hier alle Möglichkeiten. * Einrichtung von Informix. * Einrichten des users superx auf Betriebssystemebene * Entpacken des.tar Archives * Anpassen der Environment Variablen * Einspielen der SuperX Datenbank * Tomcat Konfiguration * Client Konfiguration * Testen der Installation 10 Vgl.Seite 9ff. [1] 48

49 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Einrichtung von Informix Die Einrichtung eines Informix Servers ist nur dann notwendig, wenn ein von den HIS-Systemen getrenntes System verwendet werden soll, andernfalls kann einfach der bereits verwendete Server um eine weitere Datenbank ergänzt werden. Die Installation eines Informix-Servers wird daher an dieser Stelle vorausgesetzt. Einrichten des Users superx auf Betriebssystemebene Zum Einspielen der SuperX Basisdatenbank ist ein User mit Gruppenzugehörigkeit informix notwendig. Die Gruppenzugehörigkeit wird für den Zugriff auf die Informix Tools (dbimport, dbaccess) im Verzeichnis $(INFORMIX_HOME)/bin benötigt 11. Entpacken des.tar Archives Nachdem der User superx mit Bordmitteln eingerichtet wurde, kann das Kernmodul in dessen HOME Verzeichnis entpackt werden. Alternativ kann auch ein anderes Verzeichnis gewählt werden. Das einmal gewählte Verzeichnis bildet allerdings das root Verzeichnis für weitere Installationen (im Folgenden wird dieses Verzeichnis $(SUPERX_HOME/)/genannt). Der User superx hat keine weiteren Aufgaben, so dass sich das HOME Verzeichnis hier anbietet. Mit dem Befehl: prompt > tar xvzf kernmodul.tar.gz werden die Installationsdateien entpackt. Anpassen der Environment Variablen Danach kann die Datei superx.profile editiert werden, in der einige Environment Variablen gesetzt werden. Dazu sollte diese Datei in die Datei.profile kopiert werden, damit die Variablen nach jedem Login automatisch gesetzt werden. 11 Bei einer Standard Installation eines Informix Servers gehören die zugehörigen Dateien auf Betriebssystem ebene dem User informix der Gruppe informix. Falls dies nicht der Fall ist, muss die Gruppenzugehörigkeit des Users superx entsprechend angepaßt werden. 49

50 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln Einspielen der SuperX Datenbank Das Einspielen der Datenbank muss als User superx erfolgen. Dazu werden die folgenden Befehle ausgeführt: prompt > cd $(SUPERX_HOME/)/db/install prompt > dbimport superx In der Datei dbimport.out können eventuelle Fehlermeldungen nachgesehen werden. Tomcat Konfiguration Für die Datenbankanbindung des Java Servlets werden die Informix JDBC Treiber benötigt. Diese können, falls nicht schon vorhanden, von der IBM-Homepage heruntergeladen werden 12. Sie werden in der Datei setup.class ausgeliefert. Zur Installation wird einfach prompt > java setup ausgeführt. Es folgt eine graphische Installationsroutine, in der die nötigen Einstellungen gemacht werden. Anschließend können die extrahierten ifxjdbc*.jar-files in das Verzeichnis TOMCAT_HOME/lib kopiert werden oder der Java-Classpath muss entsprechend angepaßt werden. Bei Verwendung des Kernmoduls mit TOMCAT wird bereits ein vorkonfigurierter TOMCAT Server bereitgestellt. Sein Basisverzeichnis liegt unter $(SUPERX_HOME/)/webserver/tomcat (im folgenden $(TOMCAT_HOME/)/) 13. In der Datei $(TOMCAT_HOME/)//webapps/superx/WEB INF/db.properties werden die für die Datenbankanbindung benötigten Einstellungen gemacht. Dazu steht im gleichen Verzeichnis das Tool PropAdmin.jar zur Verfügung. Es wird aufgerufen mit dem Befehl: prompt > java -jar PropAdmin.jar Da hierbei das Passwort verschlüsselt wird, ist an dieser Stelle kein Editor Einsatz mög informix 13 Der TOMCAT Server kann natürlich auch auf einem anderen Rechner oder in einem anderen Verzeichnis installiert werden. Das Vorgehen zur Installation muss dann entsprechend angepaßt werden. 50

51 3 Einführung eines Zentralen Verzeichnisdienstes an der FH Köln lich. Abbildung 3.4: Das PropAdmin Tool Die Abbildung zeigt einen Screenshot der Einstellungen für die Tomcat Informix Datenbankanbindung mit dem Tool PropAdmin.. Anmerkung: Bei dem Tool PropAdmin handelt es sich, ebenso wie bei der Installationsroutine der JDBC Treiber, um ein graphisches Frontend. Dies setzt aber unter Linux Systemen den Zugriff auf einen X Server voraus. Falls der X Server unter einer anderen User Kennung als das Tool gestartet wurde, helfen die folgenden Befehle: prompt > xhost # IP-Nummer des Rechners, von dem der X Server Verbindungen zuläßt. Muss von dem User ausgeführt werden, der den X Server gestartet hat. prompt > export DISPLAY= :0 # IP-Adresse des Rechners auf dem der X Server läuft. Wird vom TOMCAT User ausgeführt. prompt > java -jar PropAdmin.jar Nun muss noch in der Datei TOMCAT_HOME/webapps/superx/applet/superx.properties die IP Adresse des Servers eingetragen werden. Danach sollte die Tomcat Konfiguration laut Administrations Handbuch abgeschlossen sein. Beim späteren Starten von SuperX 51