probleme und lösungen der plattform - unabhängigen...

27
Probleme und Lösungen der Plattform - unabhängigen Entwicklung am Beispiel einer Software für Identity - Management Als Vorlesung gehalten an der TU Dresden am 13.4.2007 Im Rahmen der Ringvorlesung „Softwareentwicklung in der industriellen Praxis“ Lehrstuhl Softwaretechnologie Frau Dr. Birgit Demuth Autoren: Dipl.-Ing Ingo Rohner Absolvent 1985 an der TU Dresden, Studienrichtung Informationsverarbeitung. Dipl.-Inf. (FH) Jörg Rosenkranz Absolvent 1998 an der HTW in Dresden, Studienrichtung Informatik Die Firma Völcker Informatik AG (VI) hat ihren Sitz in Berlin. Die Autoren arbeiten in der Niederlassung Dresden als Softwareentwickler und sind hauptsächlich mit dem Produkt ActiveEntry beschäftigt. Alle Angaben im Vortrag beziehen sich auf dieses Produkt. Prämissen: a) Die Firma und das Entwicklerteam sind relativ klein, das Produkt ist relativ groß b) die Kunden haben Freiheiten hinsichtlich - des eingesetzten Betriebssystems - der verwendeten Datenbank - der verwendeten Anzeigetechnologie (Fat-Client / Browser) - der Anpassung der Software auf ihre speziellen Gegebenheiten Um diesen Widerspruch aufzulösen, definieren wir das Prinzip Highlander: "Es kann nur einen (Code) geben"

Upload: vankien

Post on 25-Jul-2018

222 views

Category:

Documents


0 download

TRANSCRIPT

Probleme und Lösungen der Plattform - unabhängigen Entwicklung am Beispiel einer Software für Identity - Management Als Vorlesung gehalten an der TU Dresden am 13.4.2007 Im Rahmen der Ringvorlesung „Softwareentwicklung in der industriellen Praxis“ Lehrstuhl Softwaretechnologie Frau Dr. Birgit Demuth Autoren: Dipl.-Ing Ingo Rohner

Absolvent 1985 an der TU Dresden, Studienrichtung Informationsverarbeitung. Dipl.-Inf. (FH) Jörg Rosenkranz

Absolvent 1998 an der HTW in Dresden, Studienrichtung Informatik Die Firma Völcker Informatik AG (VI) hat ihren Sitz in Berlin. Die Autoren arbeiten in der Niederlassung Dresden als Softwareentwickler und sind hauptsächlich mit dem Produkt ActiveEntry beschäftigt. Alle Angaben im Vortrag beziehen sich auf dieses Produkt. Prämissen: a) Die Firma und das Entwicklerteam sind relativ klein, das Produkt ist relativ groß b) die Kunden haben Freiheiten hinsichtlich - des eingesetzten Betriebssystems - der verwendeten Datenbank - der verwendeten Anzeigetechnologie (Fat-Client / Browser) - der Anpassung der Software auf ihre speziellen Gegebenheiten Um diesen Widerspruch aufzulösen, definieren wir das Prinzip Highlander: "Es kann nur einen (Code) geben"

Inhalt 1) Die Firma................................................................................................................ 3 2) heutiges Arbeitsgebiet von VI................................................................................. 6

2.1 Compliance ....................................................................................................... 6 2.2) Was ist Identity - Management ........................................................................ 7 2.3) Provisioning ..................................................................................................... 8 2.4 Betriebsdatenabbildung .................................................................................... 9

3. Lösungsansätze für IdM, Provisioning und ComplianceCheck ............................. 10 3.1 Lösungsansätze der Marktführer .................................................................... 10 3.2 Lösungsansatz von VI..................................................................................... 11

3.2.1 Vorgehensweise von VI im Projekt ........................................................... 14 4) Plattform- unabhängige Implementierung............................................................. 15

4.1 die Voraussetzungen bei VI ............................................................................ 15 4.2 die Kundenforderungen................................................................................... 16 4.3 die Lösungswege ............................................................................................ 17

5) Konkrete Implementierung der Ebenen............................................................... 17 5.1 Die Businesslogik / Objekt-Ebene................................................................... 17 5.2 ) Datenbank-Ebene......................................................................................... 18

5.2.1. Generierung und Single Source .............................................................. 19 5.2.2. liebevolle Handarbeit ............................................................................... 22 5.2.3. SQL-Formatter......................................................................................... 23

5.3. Frontend – Ebene .......................................................................................... 25

1) Die Firma Mit einem kleinen Rückblick in die Geschichte wollen wir zeigen, wie sich die Firma und das Produkt entwickelt haben und wie wir zu unseren heutigen Themen im Identity - Management kamen, ja eigentlich zwangsläufig kommen mußten. In den Jahren 1992 / 1993 haben die späteren Gründer bei der Krone Netzwerkservice GmbH zusammengearbeitet. 1994 wurde die Firma gegründet, erst als GbR, später als GmbH. Seit 1999 ist Völcker Informatik AG eine Aktiengesellschaft. Zur Gründung der Firma 1994 war der Stand der Technik auf dem Arbeitsplatz Windows 3.11, im Serverbereich Novell Netware in den Versionen 2.x, 3.11, 3.12 und die Herausforderung hieß, 200 PCs in einem Netz zum Laufen zu bringen. 200 PCs – eine Herausforderung? Da lächeln Sie inzwischen drüber, mit den damaligen Mittel war das jedoch nicht trivial zu realisieren. Insbesondere ging es in der Anfangszeit von VI um den Aufgabenbereich Unattended Setup, das heißt um die Fragen:

- Wie bekomme ich Stückzahlen von PCs an die Arbeitsplätze? - Wie bekommen die PCs ihr Betriebssystem? - Wie bekommen die PCs bzw. die Anwender ihre Applikationen?

Insbesondere der letzte Punkt führte uns zum Thema der automatischen Softwareinstallation, d.h. wie bekommt jeder PC genau die Software und die Treiber, die ihm zugedacht sind. Bei Windows 3.11 wurde dies realisiert über liebevolles Patchen der Dateien Win.Ini und System.Ini. Es wurden Skripte gebaut, um die INI-Dateien zu modifizieren, um dann die Netze auszurollen. Im Jahr 1996 haben wir unser erstes Netz auf Basis von NT 3.51 bei den Berliner Verkehrsbetrieben gebaut. Damit erreichten wir erstmal die Größenordnung von 3000 Benutzern. NT 3.51 war die Software der Server, teilweise auch der Clients, meistens hatten wir jedoch Windows 95 Clients. Dort wurde erstmalig ein Verfahren angewendet, die Software anhand von Gruppenmitgliedschaften der Nutzer zu verteilen. Wir hatten ein eigenes Verfahren für Softwareverteilung entwickelt. Das Verfahren beruht auf einem Delta-Abbild und ist eigentlich eine relativ triviale Sache, das machen heutzutage viele. Die Idee war ursprünglich auch nicht ganz von uns. Grob umrissen funktioniert das Verfahren wie folgt: Wir haben am Anfang einen PC, der jungfräulich mit dem Betriebssystem aufgesetzt ist. Von diesem PC merken wir uns alle Eigenschaften, alle Dateien, Registry-Einträge, Ini-File-Einträge, Desktopsymbole und Menüsymbole. Anschließend installieren wir die Applikation oder den Treiber auf dem PC und konfigurieren alle Einstellungen so, wie sie gewünscht werden. Bei Office z.B. betrifft diese Konfiguration die Menüs, die Vorlagenverzeichnisse oder die Rechtschreibkontrolle. Von der so entstandenen PC-Konfiguration merken wir uns wiederum alle Eigenschaften. Aus den gemerkten Zuständen wird ein Delta gebildet, welches wir ein Profil nennen. Völcker Informatik AG hat in diesem Zusammenhang ein Werkzeug entwickelt, welches dieses Profil in eine Maschine schreiben und es auch spurlos wieder löschen kann. Damit hatten wir einen Mechanismus für eine sehr schnelle Softwareinstallation. Die Deltabildung läuft im Allgemeinen um die 90 Sekunden für eine kompletten PC. Bei der eigentlichen Softwareinstallation wird die meiste Zeit dafür benötigt, die Profile durch das Netz zu

transportieren, weswegen wir inzwischen an dieser Stelle einen asynchron arbeitenden Cache verwenden. Für die Zuordnung der Software haben wir nicht die Maschinen sondern die NT-Konten verwendet, die Software also den Nutzern zugeordnet. Der Nutzer ist Mitglied in einer Gruppe, welche als Applikationsgruppe gekennzeichnet ist. Unser Werkzeug schaut nach, welcher Nutzer welchen Gruppen angehört und demzufolge werden die zugehörigen Applikationen installiert oder deinstalliert. Im Projekt bei den Berliner Verkehrsbetrieben haben wir innerhalb von 3 Wochen die 3000 PCs einmal komplett ausgerollt. Dazu kamen ein paar Roadies, welche die Kisten an die Plätze gebracht, ausgepackt, aufgestellt und Kabel angesteckt haben, die MAC-ID per Telefon durchgesagt haben, Knöpfchen gedrückt haben und dann fuhr der PC hoch. Das war für beide Seiten ein sehr erfolgreiches Projekt, welches uns den Weg geebnet hat für viele weitere Entwicklungen. Im den Jahren 1997/1998 haben wir dann das erste NT 4 Projekt realisiert bei der Schering AG. Bei diesem Kunden handelte es sich bereits um 10000 Nutzer. In diesem Projekt haben wir zum ersten Mal das Prinzip der Vererbung über Betriebsdaten angewendet. Der Kundenwunsch war, daß ein Mitarbeiter bzw. sein NT4-Konto über seine Mitgliedschaft in Abteilungen, Kostenstellen oder Standorten Applikationen und Gruppen erben soll. Das klingt erst mal ganz einfach – ist es letztendlich auch, wenn man ein paar unbedingt notwendige Randbedingungen einhält. Wir haben damals auch das erste Mal eine komplette Vollsynchronisation eines Zielsystems implementiert. Es wurden die kompletten Informationen zu den NT4-Domänen vollständig in unsere Datenbank eingelesen, d.h. alle Informationen zu den Konten, Gruppen und Mitgliedschaften. In der Datenbank wurden die Zuweisungen der Nutzer vorgenommen und die Ergebnisse, die aufgrund von Strukturveränderungen oder auch Direktzuweisungen entstanden sind dann wieder in die Umgebung publiziert. Im Jahr 1999 haben wir das Konzept der Betriebsdatenabbildung auf Wunsch eines weiteren Kunden weiter ausgebaut. Dr. Eckhardt Knauer war damals EDV-Leiter bei der AOK in Berlin. Er sagte uns: „Ich als EDV-Mensch bin immer der Letzte in der Firma, der von irgendwelchen Einstellungen oder Entlassungen erfährt. Und ich bin auch der Letzte in der Firma, der erfährt, daß ein PC irgendwo abgebaut und woanders wieder angeschlossen wurde oder daß ein Monitor irgendwo umgesetzt worden ist. Ich weiß eigentlich fast nichts. Das Einzige, was ich weiß, ist, da steht ein Schreibtisch, für den eine Arbeitsaufgabe definiert ist“. Also haben wir den Schreibtisch in unserer Datenbank modelliert. Auf dem Schreibtisch stellen wir einen PC auf und schließen einen Drucker an. So ist das Prinzip der Arbeitsplätze bei uns entstanden. Das hat uns dann in späteren Projekten des Öfteren gerettet. Im Jahr 2001 folgte die Integration von ActiveDirectory-Systemen, auch wieder komplett per Vollsynchronisation. Zu der Zeit hatten wir erstmals das Konzept der Person eingeführt, ein ähnliches Abstraktum wie den Arbeitsplatz. Anfänglich hatten wir nur ein einziges Zielsystem angeschlossen, das war entweder NT 4 mit einer oder mehreren Domänen bzw. Active Directory. Es war von einigen unserer Kunden gewünscht, daß diese einen Überblick bekommen, wenn eine Person 2 Konten besitzt. 99% aller Nutzer haben in einem Zielsystem genau ein Konto. Aber es gibt

ein paar wenige, die haben noch ein Extrakonto für administrative Aufgaben. Diese Abbildung konnten wir vorher noch nicht leisten. Da galt für uns (wie heute immer noch für viele Anbieter): Eine Person = ein Konto. Kurz danach kamen weitere Zielsysteme in unser Produkt, so z.B. Lotus Notes und Novell NDS, damit war die Zusammenführung diverser Konten in verschiedenen Systemen auf Personen dringend geboten. Im Jahr 2003 begannen wir ein Projekt in der Landeshauptstadt München mit 160000 Nutzern im Netz. Bei diesen Nutzer handelt es sich um alle Schüler von der 1. bis zur 13. Klasse, alle Berufsschüler und sämtliches Verwaltungspersonal im Pädagogikbereich der Stadt München. Alle diese Nutzer bekamen ein Konto, ein Postfach, ein Home-Verzeichnis und Ablageverzeichnisse. Die Verwendung bestimmter Betriebssysteme war zu der Zeit in München ein Politikum, das dazu führte, daß ausschließlich NICHT- Microsoft-Produkte zu verwenden waren. Wenn wir uns im Gegensatz dazu die bisherige Geschichte von Völcker Informatik AG dazu ansehen: – Völcker Informatik AG war „deutlich blau gefärbt“, alles war Microsoft-geprägt – Linux – man weiß wie man es schreibt, man hat es schon mal gehört, schon mal

gesehen – aber dafür programmieren? – Oracle – ja, das soll wohl auch eine Datenbank sein. Wir haben bis dahin mit

Microsoft SQL-Server gearbeitet, alle Versionen von der 6.5 an Wir nutzten die gebotene Chance und reimplementierten unsere gesamte Software. 2001 hatte Microsoft .NET vorgestellt, aus unserer Sicht das bessere JAVA. Miguel d Icasa sah das genauso und begründete das Mono-Projekt, eine Plattform-unabhängige Laufzeitumgebung für .NET. Damit hatten wir eine Basis, in der gewohnten Microsoft-Umgebung zu entwickeln und die Software gegen Linux laufen zu lassen. Aus diesem Projekt wurde auch das heute vollständige umgesetzte Konzept der Plattform-Unabhängigkeit geboren. Im Jahr 2003 haben wir angefangen SAP als ein Zielsystem zu integrieren. Bei SAP synchronisieren wir nicht die gesamte Datenbank noch einmal in unsere Datenbank, sondern beschränken uns auf die Informationen zu Konten, Mitgliedschaften und Gruppen (dort Profile und Rollen genannt), wobei letztere nur gelesen werden. 2005 haben wir es dann erstmals geschafft, funktionsidentische Frontends sowohl auf dem PC als EXE-Datei als auch im Browser laufen zu lassen, wobei in beiden Fällen das selbe Compilat verwendet wird. Das war notwendig, da immer mehr Kunden Intranet-Lösungen zu unserem Produkt haben wollten, insbesondere was den Bereich der Selbstbedienung der Anwender betrifft. Die Firma Völcker Informatik AG hat zum heutigen Tag 55 Mitarbeiter, davon arbeiten 12 in Dresden. Dresden ist der Standort der Firma in dem komplett die Bereiche Produktentwicklung, Qualitätssicherung, Dokumentation und Support abgewickelt werden.

2) heutiges Arbeitsgebiet von VI

2.1 Compliance Was ist eigentlich Compliance? Leo.org übersetzt das mit

- in Übereinstimmung mit einer Bedingung - in Erfüllung einer Bedingung

Wozu benötigen wir Compliance? Schauen wir ein paar Jahre zurück, auf das Platzen der großen Internetblase. Kann sich noch jemand an den Enron-Skandal erinnern? Dieses Energie-Unternehmen in den Vereinigten Staaten hat Spekulations- und Scheingeschäfte innerhalb der Firma gemacht. Zum Schluß implodierte das gesamte Spekulationsgebilde mit einem Riesenknall und einigen Milliarden Dollar Verlusten. Als Reaktion darauf wurde in den USA ein Gesetz verabschiedet, der „Sarbance-Oxley-Act“ (SOX). Dieses verpflichtet Unternehmen, Regeln der innerbetrieblichen Sauberkeit zu definieren, einzuhalten und zu überwachen. Solche Regeln sind z.B. daß jemand, der Einkäufe über 1000 $ auslösen darf, nicht gleichzeitig auch zeichnungsberechtigt für die dazugehörigen Überweisungen ist. Wenn eine solche Rechtekonstellation zusammentrifft, dann ist der Versuchung Tür und Tor geöffnet. Das sind Risiken, die in der Unternehmensbilanz benannt und bewertet werden müssen. Die Einhaltung dieser Regeln muß nicht nur auf allgemeiner organisatorischer Ebene, sondern ausdrücklich auch auf der Ebene der EDV-Zugriffsrechte sichergestellt werden. Und was geht uns das in Deutschland an? Die Beantwortung der Frage ist relativ einfach: Jedes Unternehmen, das auch an amerikanischen Börsen gehandelt wird, ist verpflichtet eine Bilanz zu liefern, in der auch die Einhaltung solcher Regeln gesichert ist. Das ist Bestandteil des Wirtschaftsprüfertestats. Es gibt aber auch bei uns gesetzliche Regelungen, die eine Regeldefinition und –Überwachung fordern. In Deutschland haben wir z.B. das Energiewirtschaftsgesetz. Das Energiewirtschaftsgesetz sagt unter anderem sinngemäß aus, daß, wenn eine Firma Energieerzeuger ist, ein eigenes Endkundengeschäft betreibt und auch Endkundengeschäft für Wiederverkäufer organisiert, niemand von diesen 3 Bereichen dem anderen in die Karten schauen darf. Ansonsten könnte ich ja als Endkundenbetreuer eines Energieerzeugers mal eben die Kundenliste der Yello-Kunden nehmen, alle abtelefonieren und versuchen sie zurückzugewinnen. Da muß also eine Wand im Unternehmen existieren, welche auch auf EDV-Ebene repräsentiert wird. Das heißt, daß Leute, die in dem einen Bereich arbeiten nicht auf die Ordner und Applikationen der Leute aus einem anderen Bereich zugreifen können und umgekehrt. Ein ähnliches Gesetz gibt es auch in Deutschland im Bereich Aktien- oder Bankenrecht. Jemand, der im Kundenauftrag mit Aktien handelt, darf sich in seinen Rechten, Befugnissen und Informationen nicht überschneiden mit jemandem, der Firmenfusionen, Firmenverkäufe oder Aufspaltungen im Auftrag der Bank bearbeitet. Im anderen Fall wäre die Gefahr eines Insider-Geschäfts gegeben. Dem Gesetz

muß derart Genüge getan werden, daß eine Trennung auch im EDV-Bereich existiert. Das Thema Compliance befaßt also immer mit Regeldefinitionen der Art

„Es darf nicht sein, daß jemand... “ Z.B. „Es darf nicht sein, daß jemand Zugang zu der Gruppe A und zu der Gruppe B und zu dem Ordner C hat und sowohl die Applikation D als auch die Applikation E verwenden darf.“ Weiterhin gefordert ist beim Thema Compliance eine dauerhafte und lückenlose Aufzeichnung aller Rechtezuweisungen, aller Rechteabweisungen und in dem Fall, daß eine Regelverletzung aufgedeckt wird, auch eine zeitnahe Benachrichtigung desjenigen, der für die Überwachung dieser Regel zuständig ist, erfolgt. „Es darf nicht sein, daß jemand...“ Wer ist dieser „jemand“? Im Sinne der Gesetze ist damit immer eine Person gemeint. Die Rechtsprechung kennt keine Konten, verantwortlich sind immer Personen. Eine Person hat jedoch unter Umständen mehrere Konten in den unterschiedlichsten Zielsystemen. Und für diese Person müssen die Regelverletzungen aufgedeckt bzw. gleich vermieden werden. Denken Sie jetzt mal an die EDV-Landschaften, die Sie bisher kennengelernt haben. Haben Sie da irgendwo schon einmal eine Person als abstraktes Objekt gesehen? Es werden immer nur Konten verwaltet.

2.2) Identity - Management Es existiert Uneinigkeit darüber, was eine Identität ist, manch einer meint die Person, andere meinen damit Konten. Im Sinne von Compliance sind aber immer beide im Zusammenhang zu betrachten. Das Ziel von Identity – Management ist es, zu jeder Zeit die Information über jede Identität und ihre Berechtigung zur Verfügung haben, manipulieren und auswerten zu können. Es nützt nicht, eine Überwachung von 2 Konten zu machen, es geht um die Person – der Bankangestellte, der nicht gleichzeitig zwei sich ausschließende Rechte haben darf, egal mit welchen Konten er sie erreicht. Rechte sind z.B. Access-Control-Lists im ActiceDirectory oder Transaktionen in SAP. Solche Rechte werden im Normalfall an Gruppen gebunden. Es gibt eine einzige Stelle, wo es sinnvoll ist, ein Recht an ein einzelnes Konto zu binden, und das ist das Recht auf dem Home-Verzeichnis eines Nutzers. Gruppen als Träger der Rechteinformationen gibt es heute in jedem Konten verwaltenden System (Betriebssysteme, SAP, Notes, auch Mail-Verteilerlisten sind „nur“ Gruppen ) Für die Überprüfung von Compliance reicht es also im Normalfall aus, die Gruppenmitgliedschaften zu überwachen, sofern die Rechte der Gruppen ordentlich dokumentiert sind.

Zusammenfassung: Identity - Management ist das Verwalten von Informationen über Person, ihre Konten und deren Gruppenmitgliedschaften, das Aufzeichnen von Veränderungen und das Anbieten von Auswerte-Möglichkeiten.

2.3) Provisioning Das letzte Schlagwort in der Sammlung lautet Provisioning – frei übersetzt die „Versorgung“. Das meint die Versorgung einer Person mit Konten in einem bestimmten Zielsystem und die Versorgung eines Kontos mit Gruppenmitgliedschaften. Im erweiterten Sinne bedeutet das auch die Versorgung einer Person mit materiellen Gütern wie z.B. einem PC oder Telefon oder allem Sonstigen, was die Person für ihre Tätigkeit benötigt. Die Zielstellung, welche hinter dem Schlagwort Provisioning steht, lautet: Betritt jemand ein Unternehmen, so soll er innerhalb kürzester Zeit arbeitsfähig gemacht werden, auch EDV-technisch, d.h. er muß ein Konto bekommen z.B. im Active Directory, er muß ein Postfach erhalten, muß in bestimmte Rechtegruppen aufgenommen werden, muß ein Portfolio an Applikationen zugeteilt bekommen und einen PC auf den Schreibtisch bekommen, der ein passendes Betriebssystem und eine korrekte Netzanbindung hat. Wer etwas vertraut ist mit der Materie weiß, es gibt Unternehmen, in denen dauert es wirklich vom Eintritt des Mitarbeiters bis zu dem Zeitpunkt, an dem er EDV-mäßig arbeitsfähig ist, 2-4 Wochen. Es kann sich solange hinziehen, weil viel Papierkram von vielen Leuten ausgefüllt und unterschrieben werden muß bis sich dann jemand hinsetzt und wirklich das Konto anlegt. Das Gegenstück dazu ist, jemand verläßt das Unternehmen. Da mögen aber bitte innerhalb weniger Minuten sämtliche Konten nicht mehr verwertbar sein – egal ob sie nun gelöscht oder gesperrt werden, oder nur aus allen Gruppen entfernt werden. Hauptsache, man kann mit den Konten nicht mehr arbeiten. In der Praxis dauert es allerdings oftmals mehrere Jahre, bis auch wirklich das letzte Konto gesperrt oder gelöscht ist. Gesamt-Zielstellung Identity - Management, Provisioning und Compliance Eine Person soll genau über die Konten und Berechtigungen verfügen, die für ihre Tätigkeit notwendig sind, genau für den Zeitraum in dem das erforderlich ist. Sämtliche Arbeitsschritte, die Änderungen an diesen Daten vornehmen, sind zu dokumentieren. Das Berechtigungsportfolio darf keine der definierten Regeln verletzen bzw. sind diese Regelverletzungen aufzuzeichnen und kurzfristig den Verantwortlichen zu melden. Wie gelangt man nun eigentlich zur Mitgliedschaft in einer Gruppe, sei es nun Applikations- oder Rechtegruppe? Wir haben 3 mögliche Herangehensweisen:

- Der erste Weg ist der Klassiker: Ich nehme das Management-Werkzeug des Betriebssystems nehme meinen Account, füge ihn in die Gruppe ein und speichere ihn. So hat keiner einen Überblick oder eine Benachrichtigung und somit weiß auch keiner, wer dies wann getan hat.

- Die bessere Wahl ist ein Ablauf von Bestellung, Genehmigung und Zuweisung. Eigentlich wird hier lediglich das Verfahren abgebildet, welches in

den meisten Unternehmen papiermäßig abläuft und am Ende mit den technischen Mitteln der Direktzuweisung (s.o.) realisiert wird.

- Die 3. Variante ist die Erbschaft aus Strukturmitgliedschaften bzw. aus Rollen. Egal, welches der beiden letztgenannten Verfahren wir benutzen, wir haben es an diesen Stellen jetzt immer mit Betriebsdatenabbildungen zu tun, da die Erbschaft aus einer Strukturzugehörigkeit erfolgt bzw. der Besteller und der Genehmiger in einer betrieblichen Korrelation zueinander stehen. Oftmals ist z.B. der Genehmiger der Kostenstellenverantwortliche, da dieser später auch die zugehörige Rechnung bekommt. Bei der Deutschen Telekom Immobilien GmbH haben wir es so implementiert, daß jeder Kostenstellenverantwortliche am Monatsende per E-Mail ein PDF zugestellt bekommt mit dem Titel „Ihre EDV-Kosten für diesen Monat für ihre Mitarbeiter“. Aufgeführt sind dort alle Kosten für PC-Abschreibung oder Leasingraten, Applikationsnutzung oder Speicherverbrauch auf den Servern. All diese Informationen sind letztlich in der Datenbank vorhanden und müssen nur noch per Report strukturiert werden. Die EDV-Kostenstellen werden in der Kostenrechnung als Verrechnungskostenstelle umgelegt, d.h. die EDV-Abteilung ist an jedem Monatsende als interner Firmendienstleister kostenmäßig auf +/- Null gestellt. Wir haben also immer eine gewisse Betriebsdatenabbildung durchzuführen. Wie diese aussieht, soll unser letzter Punkt sein bevor wir uns der konkreten Implementierung zuwenden.

2.4 Betriebsdatenabbildung Bei der Betriebsdatenabbildung gibt es mehrere Ansätze. Ich habe mit Herrn Professor Koch von der HTW herzliche Streitgespräche durchgeführt. Prof. Koch ist einer der X-500 Gurus und ebenso ein Motor der Unix-Gemeinde. X-500, ist vereinfacht gesagt, ein Modell zur hierarchischen Strukturierung von Organisationsdaten als Container und der Zuordnung von Konten in diese Container. Das ist das Modell mit dem viele Vertriebsleute Erfolg haben, weil es genauso aussieht, wie sich mancher Vorstand seine Firma vorstellt. Ganz oben ist der Chef, darunter bauen wir ein paar Container an, welche die Hauptabteilungen darstellen. Darunter werden erneut Container aufgebaut, die dann Unterabteilungen verkörpern. Schließlich folgen die Kleinstabteilungen. Es ist also ein richtig schönes hierarchisches System, in dem ich auch etwas durchvererben kann. Es gibt allerdings ein paar Probleme z.B. das Thema Standorte. Die IP-Konfiguration der Rechner ist standortabhängig. Gut, lösen wir das Problem, indem wir auf der ersten Ebene unserer Hierarchie Container für die Standorte einfügen und darunter spannen sich dann die Abteilungen auf. Das ist immer noch optimal aus der Sicht eines Vorstandsvorsitzenden. Dann gibt es aber noch die Kostenstellen. Nun wird es langsam unübersichtlich, da man sie nicht mehr in eine einzelne Hierarchie hineinbekommt und außerdem im X-500 jedes Konto nur in genau einem Container Mitglied sein kann.

Vor ca. 6 Jahren hatten wir die dankbare Aufgabe bei der Wirtschaftsprüfungsfirma KPMG eine Analyse zur Modellierung der Verteilerlisten zu erstellen. KPMG ist ein Unternehmen, welches andere Unternehmen berät wie diese ihre Betriebsabläufe aufzubauen und wie sie sich zu strukturieren haben. Im E-Mail - System gab es eine Menge definierter Verteilerlisten und KPMG wollte einen Automatismus haben, mit dem jemand aufgrund seiner Zugehörigkeit zu einem Standort, zu einer Abteilung usw. automatisch Mitglied in einer Verteilerliste wird und die entsprechenden Informationen, die an diese Verteilerliste gesendet werden, auch erhält. Die 3 Klassiker in der Betriebsstrukturierung hatten wir sofort identifiziert: Abteilung, Kostenstelle und Standort – alles kein Problem. Die Kostenstellen ergaben sich aus Sicht der Controller. Die Mitgliedschaft im Beratungsprojekt X oder Y ist die nächste Ebene. Dann kamen noch die Fachgebiete hinzu z.B. Beratung in Land- und Forstwirtschaft, dazu die Interessengebiete „Ja, ich interessiere mich auch für die Nahrungsgüterwirtschaft“. Weiterhin gibt es die Partnerschaften. KPMG ist keinesfalls ein homogenes Unternehmen, sondern viel mehr eine Vereinigung mehrerer Sozietäten mit gemischten Eigentümerschaften. Und dann gibt es noch Spezialisierungsrichtungen: Der eine Mitarbeiter ist verantwortlich für Prüfung und Testierung, der andere ist für die Betriebsorganisation zuständig und der Dritte für die Finanzplanung. Das sind also insgesamt 8 Dimensionen, in denen KPMG strukturiert ist. Wir können davon ausgehen, daß jede Firma eine n-dimensionale Abbildung benötigt, wobei n beliebig groß sein kann. Wir haben also eine n-dimensionale Matrix-Sicht. Jede dieser Sichten ist bei uns letztendlich auch implementiert als ein Baum, jedoch gegenüber X-500 mit einigen entscheidenden Unterschieden:

- Jeder Nutzer kann Mitglied in beliebig vielen Containern auch innerhalb eines einzigen Baumes sein

- Mitglied sind die Personen, nicht die Konten - An jeden Container kann man Rechte aus allen Zielsystemen zuweisen,

weiterhin auch Konstrukte für die Zuweisung für z.B. PCs

3. Lösungsansätze für IdM, Provisioning und ComplianceCheck

3.1 Lösungsansätze der Marktführer MetaDirectory - Projekte In den letzten Jahren gab es den Hype der Meta-Directory-Projekte. Die Anbieter am Markt hatten inzwischen alle erkannt, daß eine n-dimensionale Matrix und eine X-500 Abbildung nicht so recht zueinander passen. Also definierten sie ein neues Directory, legten dieses über das vorhandene und nannten das Ganze ein Meta-Directory. Wenn man die Dimensionen vergleicht, kommt man schnell zu dem Schluß: „Das kann nicht funktionieren.“ Die Meta-Directory-Projekte sind auch alle hinsichtlich einer sauberen Betriebsdaten-Abbildung gescheitert. Identity Management – Systeme (IdM)

Die meisten Anbieter von IdM führen mit Kunstgriffen die Person als Objekt ein, legen jedoch nur die Referenzen zu den verwalteten Konten ab. Es erfolgt also keine komplette Abbildung des Zielsystems (Bsp. Nur Ablage des DistinguishedName). Dabei treten jedoch einige Probleme auf:

- Wird ein Objekt umbenannt oder geändert, stimmt die Referenz nicht mehr, das System ist inkonsistent.

- Die Zuordnung der Eigenschaften als auch Zuordnung von Personen zu Konten erfolgt über Mapping – Regeln z.B. zwischen Accountname oder Email-Addresse zu Eigenschaften der Person wie Vorname und/oder Nachname Das klappt im besten Fall für 98 % aller Objekte, meist jedoch nur im Bereich zwischen 60 und 80 % aller Objekte. Aber selbst 2 % Restmenge bedeuten das Scheitern des Projektes, weil damit

a) automatisches Management über die Meta-Ebene nicht mehr zu definiert richtigen Ergebnissen führt.

b) schon ein einziger Verstoß gegen Compliance - Regeln zur Verweigerung eines Testats führen kann.

- Sollen Objekte betrachtet oder geändert werden, ist ein Zugriff auf das Zielsystem notwendig, es muß also am Standort der Management – Software verfügbar sein.

- Sollen Listen von Objekten gezogen werden, so benötigt man viel Zeit. Wir haben Anwendungsfälle, bei denen wir die Mitglieder in einem Container (2500 Konten), als eine Liste im Frontend produzieren müssen. Als Reaktionszeit eines Frontends werden nur Zeiträume bis 3 Sekunden akzeptiert. Mit Direktzugriffen auf die Zielsysteme schafft man das nicht annähernd.

Es gibt also auf diesem Gebiet einen Glaubenskrieg – machen wir ein Store-By-Reference (was u.a. in den Meta-Directory-Projekten verwendet wird) oder mache ich ein Store-By-Value (unser Weg) d.h. alle Daten liegen komplett in der Datenbank. Warum haben wir uns für die Datenbank entschieden? Zum einen ist das das einzige wirklich transaktionssichere System. Für diesen Zweck sind relationale Datenbanken entwickelt worden. Und es ist auch die einzige Technologie, die gut geeignet ist für Massendatenverarbeitung.

3.2 Lösungsansatz von VI 3-Ebenen Architektur Letztendlich gesehen, haben wir in unserem Produkt eine klassische 3-Ebenen-Struktur, bestehend aus einer Datenbank, darüber die Objektschicht und einer Präsentationsschicht. Auch die automatische Verarbeitung auf den Servern funktioniert wie eine Präsentationsschicht, da auch sie immer durch die Objektschicht hindurch geht.

Die Datenbank haben wir logisch in zwei Bereiche eingeteilt. Zum einen haben wir die Nutzdaten, welche die konkreten Informationen über Personen, Betriebsdaten, Konten, Mitgliedschaften, Gruppen beinhalten (pay-load). Zum anderen gibt es die Metadaten, welche die gesamte Dialogsteuerung, Queues für asynchrone Verarbeitung sowie die komplette Systemkonfiguration umfassen. Das Nutzdaten- Modell enthält Tabellen für:

- Die Person und ihre 1:n Abbildung zu Konten - Beliebige Betriebsdaten-Strukturen mit beliebigen Mitgliedschaften als

Fremdschlüssel oder auch als m:n-Abbildung, um die n-dimesionale Matrix des Unternehmens darstellen zu können.

- Die vollständige Abbildung der zu verwaltenden Zielsysteme. Über der Datenbank liegt eine Objektschicht. In der Objektschicht ist eigentlich vom Objekt selbst oder von Klassendefinition her nichts programmiert. Die „leere Hülle“ der Objekte wird zur Laufzeit aus dem datenbankschema erzeugt. Die Funktionsweise der Klassen ergibt sich erst im Zusammenspiel mit den Meta-daten aus der Datenbank. Wir haben je Tabelle eine Objektklasse. Davon abgeleitet gibt es je nach Bedarf weitere Teilklassen. Je Spalte ist ein Property definiert. Zur Verfügung steht ein Satz von Datenbank-orientierten Methoden (Load, Save, GetValue, PutValue) und Events (Insert, Update, Delete). Wir stellen Ausdrucksmittel für die Quernavigation (Objectwalker) zur Verfügung, mit denen sich auf der Ebene C# Fremdschlüsselbeziehungen verfolgen lassen. Es gibt die sogenannten Customizer in der Objektebene. Diese enthalten nicht änderbare Nebenwirkungen der Objekte. Ein Beispiel dafür ist das Wechselspiel der Flag UserCanNotChangePassword UseMustChangePasswordAtNextLogon im Objekte ADSAccount.

DatenbankNutzdaten Metadaten

ObjectLayerObjectLayer

Über die Metadaten der Datenbank können weitere konfigurierbare Nebenwirkungen geladen werden, die dem Kunden offen gelassen wurden. Beispiel dafür sind Bildungsregeln für Postfächer. Über Serverkomponenten, die auch gegen die Objektschicht arbeiten, erfolgt die vollständige bidirektionale Synchronisation mit den Zielsystemen. Das Management über Frontends erfolgt immer durch die Objektschicht hindurch. Als Ergebnis gibt es eine Veränderung von Nutzdaten. Parallel dazu werden auch Metadaten verändert, vorzugsweise in Queues für asynchrone Verarbeitungen. Von den Queues holen sich Server die Informationen ab und verarbeiten diese. Gleichzeitig befinden sich Server aber auch in der Rolle, daß sie Informationen und Aktionen (wie ein normales Frontend) wieder einstellen können. In den einschlägigen Studien zum Thema Identity Management und Provisioning (z.B. Burton und Gartner) tauchen immer wieder zwei Begriffe auf, über die sich die Gelehrten allzu gern streiten: Local Agent und Remote Agent. Ein Agent ist in dem Sinne ein Stück Software, welches Manipulationen an Konten im Zielsystem vornehmen kann. Der lokale Agent: Ich mache etwas über eine Remote-Konsole auf einem Server und lasse dort alles ausführen. Der Remote Agent: Ich sitze an meinem Arbeitsplatz und habe einen Durchgriff durchs Netz und mache meine Änderungen aus der Entfernung. Nach diesen Definitionen ist unser Produkt etwas, was man konsequenterweise als Distributed Agent bezeichnen muß. Betrachten wir zum besseren Verständnis den Vorgang „Anlegen eines Kontos in der ADS“. Im Frontend hat das Konto seine Eigenschaften bekommen und soll nun in das Zielsystem publiziert werden. Die erste Aktion hierfür ist das Anlegen des Kontos selbst. Manch einer glaubt, das wäre schon alles gewesen, doch die eigentliche Arbeit beginnt jetzt erst. Nach dem Anlegen auf dem Domain-Controller folgt ein weiterer Bearbeitungsschritt, denn der Nutzer benötigt ein Home-Verzeichnis. Dazu muß ich einen geeigneten Home-Server aus den Betriebsdaten auswählen, im Normalfall wird das standortabhängig sein. Auf dem Homeserver muß ich ein Verzeichnis anlegen, dieses sharen und Rechte für den Nutzer vergeben. Des Weiteren benötigt der Nutzer ein Postfach, welches ich sinnvollerweise auf dem Exchange-Server anlege. Aber sowohl bei der Rechtevergabe auf dem Home-Server als auch beim Anlegen des Postfaches auf dem Exchange-Server muß ich warten bis die ADS eigene Replikationen mir das Konto auf dem aktuellen Server zur Verfügung stellt. Dann muß das Konto in Rechtegruppen und Verteilerlisten aufgenommen werden, was sinnvollerweise wieder auf dem Domain-Controller passiert. Wir bevorzugen diese Vorgehensweise aufgrund der Installierbarkeit, der Lastverteilung und der Sicherheit der Daten. Wenn ich einen Dienst auf einer Maschine installiere, dessen Aktionsgebiet auf die Maschine selber beschränkt ist, bekomme ich Rechtesituation und Betriebsstabilität viel einfacher konfiguriert, als wenn ich Aktionen ausübe, bei denen man durchs Netz durchgreifen muß.

Dazu müßte ich einem Konto Rechte auf entfernte Ressourcen erteilen. Sobald sich aber an Kontensituationen oder Netztopologie irgend etwas verändert, ist solch eine Zuordnung von Rechten immer problembehaftet. Deswegen liegt unsere Konzentration auf lokaler Ausführung. Jeder Server holt sich aus der Queue in der Datenbank die Aufgaben ab, die durch ihn zu bearbeiten sind und meldet sein Verarbeitungsergebnis zurück. Darauf basierend besitzen wir einen Schalt-Mechanismus für Prozeßabläufe, durch die im Anschluß der möglichen Folgeschritt freigeschalten wird.

3.2.1 Vorgehensweise von VI im Projekt Die schwierigste Phase in IdM-Projekten ist die die Inbetriebnahme und hierbei wiederum das Thema Datenkonsolidierung. Im Laufe der Jahre hat sich bei uns ein Standard-Vorgehen etabliert. Die Daten zu den Betriebsstrukturen werden durch Importe oder durch manuelles Anlegen erzeugt. Die Personen werden aus einem HR-System importiert, das klappt zumindest für alle die, die auf der Lohnliste stehen. Jetzt fehlen noch externe Mitarbeiter von Dienstleistern bzw. Leiharbeiter. Weitere Personendaten oder auch weitere Eigenschaften von Personen werden durch Import aus Telefonbuch-Applikationen, Telefonanlagen-Speichern oder später direkt aus Konten gewonnen. Danach werden alle relevanten Zielsysteme mit Konten, Gruppen und Mitgliedschaften eingelesen. Auf Basis dieser Daten machen wir eine erste Zuordnung der Personen zu den Konten. Diese Zuordnung erfolgt durch einmaliges Anwenden von Mapping – Regeln in den Fällen, bei denen die Regel ein eineindeutiges Ziel ermittelt. Mit dieser Methode erreicht man ca. 60-80 % Datenqualität. Die so erzeugten Daten gehen als Korrekturlisten an die Abteilungen, da auf dieser Ebene die Personen durch direkten Kontakt bekannt sind und die Informationen oft wesentlich aktueller vorhanden sind. Den Abteilungsleitern wird ein Frontend im Intranet zur Verfügung gestellt, mit dem sie ihren Änderungen vornehmen können. Bis hierher kommen wir auf über 95 % Datenqualität. Alle Konten, die sich bis zu diesem Stand nicht zuordnen lassen, werden gesperrt. Wir gehen aus Erfahrung davon aus, daß sich der Inhaber des Kontos in der EDV-Abteilung melden wird, sofern er noch Bedarf hat. Die ausgelesenen Gruppen-Zuordnungen der Konten werden soweit möglich umgesetzt auf Erbschaften über Betriebsdaten, sofern die Beziehung zwischen z.B. einer Abteilung und einer Gruppenmitgliedschaft eindeutig ist und der Kunde dies wünscht. Ein anderer oder manchmal auch zusätzlicher Weg ist die Umsetzung der Gruppenzuordnungen auf Bestellungen im IT-Shop. Die Zuordnungen werden so aufbereitet, als ob sie im Intranet bestellt, genehmigt und zugeordnet wären. Das gibt dem Kunden die Möglichkeit, solche Zuordnungen einfach abbestellen zu können. Die Zuordnung der Konten zu Personen kann ebenfalls wie eine ITShop-Bestellung aufbereitet werden, so daß z.B. ein Abteilungsleiter für seinen Mitarbeiter ein Konto wieder abbestellen kann, wenn er dies nicht mehr benötigt.

4) Plattform - unabhängige Implementierung

4.1 Die Voraussetzungen bei VI Die Wurzeln von Völcker Informatik liegen ganz eindeutig im Microsoft-Umfeld Alles was bisher beschrieben wurde, hatten wir über die Jahre schon Stück für Stück in C++ und COM - Technologie (für die Zugriffs- und Objektebene) bzw. in Visual Basic für die Frontends implementiert. Als Datenbank diente MSSQL in den Versionen 6.5, 7 und auch 2000. Alle Mitarbeiter haben mit Microsoft DevStudio 5 und 6 gearbeitet, VI-Editor und Arbeit ohne einen Schritttest-Debugger hat niemand mehr akzeptiert. Die Niederlassung Dresden setzt sich nach Aufgaben heute wie folgt zusammen (Teilzeitverträge und Aufgabenteilungen sind anteilig umgerechnet auf ganze Stellen) Objektschicht 1 Zielsystem –Abgleich 1 Standard-Frontends (Fat + Web) 2 QS 1,5 Standard-Prozesse 0,75 Kundenspezifische Frontends 1 Dokumentation 1 Entwicklung primäre Datenbank 1 Umsetzung Oracle 0,3 Support 1,5 Das bedeutete, je nach Zählweise ca. 7 Leute für alle Entwicklungen Für alle Software-Ebenen mußte eine Entscheidung fallen für ein System unter dem primär entwickelt wurde. Alle anderen Plattformen müssen dann per Anpassen / „Abschreiben“ nachgezogen werden. Bei der Entwicklung auf der jeweiligen Primärplattform müssen die Einschränkungen durch die anderen Plattformen immer schon berücksichtigt werden. Alles was gebaut wird, muß Unit-Tests erhalten, die identisch auch in der Sekundär - Implementierung ablaufen.

4.2 Die Kundenforderungen Die Kundenwünsche beinhalten Plattformunabhängigkeit hinsichtlich

- Datenbank - Zugrunde liegendes Betriebssystem, Programmiersprache und

Laufzeitumgebung - Frontend-Technologie als Exe bzw. als Browser-Frontend

wobei der Webserver und der Browser selbst auch wieder Plattform- unabhängig sein sollen.

Insgesamt ergibt das die nachfolgend skizzierte Vielfalt an Möglichkeiten

4.3 Die Lösungswege Das Ergebnis soll hier schon einmal vorweggenommen werden. Aus unserer Sicht hat man genau 3 Lösungsmöglichkeiten, um eine Software plattformunabhängig zu entwickeln. Nr. 1 die schöne heile Welt: Wir haben identischen Schnittstellen auf allen Plattformen. Dazu entwickelt man einen Quelltext, compiliert diesen und läßt das Ergebnis auf alle Plattformen laufen. Nr. 2 die ähnliche Welt: Die Zielumgebungen sind sich zumindest weitgehend ähnlich, haben eine ausreichend großen Durchschnittsmenge, so daß sich eine Entwicklung auf einer Meta-Ebene lohnt. Das bedeutet, daß man auf einer abstrahierten Ebene entwickelt und dann entweder zur Laufzeit oder zur Generierungszeit aus dieser Meta-Ebene ein Programm erzeugt, das auf den jeweiligen Plattformen läuft. Nr. 3 die Unterwelt: Die Zielumgebungen sind so unterschiedlich, daß getrennte Implementierungen notwendig sind. Üblicherweise wird für ein Primärsystem entwickelt und nach erfolgten Tests der Code anschließend durch Abschreiben in eine oder mehrere Sekundärimplementierungen übertragen. In Reinform trifft man diese Möglichkeiten in der Realität fast nie an. Meistens treten Mischformen auf.

5) Konkrete Implementierung der Ebenen

5.1 Die Businesslogik / Objekt-Ebene Für die Implementierung einer plattformunabhängigen Objekt - Ebene standen im Jahr 2002 zwei relevante Systeme zur Auswahl: Die zuerst untersuchte und damals auch bekanntere Grundlage war Java. Es war damals schon weit verbreitet und hatte vor allem serverseitig eine große Akzeptanz erreicht. Die Fat - Clients waren jedoch recht langsam und instabil. Für die Zukunftssicherheit der Entscheidung kam erschwerend hinzu, daß Java kein offener Standard ist, sondern unter Hoheit der Firma SUN steht. Als technisches Problem stellte sich die Einbindung von nativem Code heraus, welcher jedoch bei der Ansteuerung z.B. einer ADS oder eines Notes-API benötigt wird. Die Alternative hieß .NET Framework mit C# als Entwicklungssprache. Das war für uns aufgrund unserer Vergangenheit eine vertraute Entwicklungsumgebung mit der auch native Windows-Frontends möglich waren. .NET war eingereicht als ECMA-Standard und eine Portierung auf andere Betriebssysteme war mit dem quelloffenen Mono im Entstehen. Mono war zwar

anfangs noch nicht ausgereift, Probleme konnten von uns aufgrund der Quelloffenheit gefixt und an die Mono-Community eingereicht werden. Die Einbindung von bestehendem Code war für eine Übergangszeit bzw. für die direkte Betriebssystemansteuerung möglich. Letztendlich trafen wir also unsere Entscheidung zugunsten .NET. Eine totale Plattformunabhängigkeit läßt sich nicht erreichen, es gibt immer Fallstricke zu beachten. Einige Beispiele dafür sollen nachfolgend kurz benannt werden.

- Pfade im Dateisystem Linux ist in diesem Bereich Case Sensitiv, Windows ist Case Insensitiv. Beide Betriebssysteme haben andere Trennzeichen und andere Verzeichnisstrukturen (Laufwerksbuchstaben)

- Fehlende Features Linux kennt keine Registry und keine COM-Interfaces

- Unterstützung für Oberflächenbibliotheken Es gibt erhebliche Unterschiede zwischen WinForms und GTK#

- externen Bibliotheken In den Anfangszeiten gab es für MONO keine vollständige VB.NET-Umsetzung

- Verwendung von nicht portablen externen Bibliotheken Zugekaufte Controls oder Bibliotheken enthalten oftmals native Betriebssystem-Aufrufe, das ist z.B. bei fast alle Reporting-Werkzeugen der Fall

- Nutzung von Tools, die nur auf einem der Systeme zur Verfügung stehen (z.B. Robocopy vs. Rsync)

Die Grundregel lautet hier: Soweit wie möglich abstakt implementieren und z.B. Path.Combine statt String.concat verwenden. Wenn es wirklich massive Unterschiede gibt, greift Methode 3: Man verwende einen Case-Block, der nach Betriebssystemen differenziert. Zu diesem Zweck kann man ein zentrales Property unserer Klassenbibliothek zur Unterscheidung abfragen.

5.2 ) Datenbank-Ebene Was ist das Schöne an Standards? Daß es so viele davon gibt! Es gibt einen ANSI-SQL-Standard. Man kann sich daran orientieren und es ist als Lehrbeispiel auch gut zu verstehen. Daneben gibt es die Implementierung von Microsoft mit dem Namen Transact-SQL, meist abgekürzt mit T-SQL. Weiterhin gibt es eine Implementierung von Oracle, die sich PL/SQL nennt. Die nachfolgenden Aussagen sind nicht wissenschaftlich, sondern eher im Gefühlsbereich angesiedelt. Es gibt Überschneidungen und Differenzmengen zwischen MSSQL, Oracle und dem ANSI-Standard. ANSI-SQL ist von Haus aus, was Abläufe und prozentuale Elemente betrifft, etwas schwach auf der Brust – Da ist eigentlich gar nichts definiert.

Unser Ziel war immer offen zu bleiben für die spätere Integration weiterer Datenbanksysteme. Deshalb wurde vor Grundsatzentscheidungen auch immer die Machbarkeit gegen PostgreSQL abgetestet. DB2 haben wir außen vor gelassen, da es bei unseren Kunden so gut wie nicht vorkommt und MySQL mußten wir ignorieren, da es mit Triggern und SPs noch nicht so weit war.

5.2.1. Generierung und Single Source Die Datenbank ist der Kern unseres Produktes, die Stelle, wo alle Informationen zusammenlaufen. In der Codestatistik im Anhang kann man erkennen, wie sich dieser Sachverhalt auch auf die Code-Menge auswirkt. Das konnten wir natürlich nicht alles zweimal machen. Deswegen ist es nötig zu differenzieren. Soweit wie möglich nutzen wir Meta-Entwicklung aus einer einzigen Quelle. Das Datenbankschema wird mit einem schönen, alten Werkzeug gepflegt, das inzwischen schon 10 Jahre alt ist und ERWin heißt. Wir nehmen unsere Entity-Relationship-Modelle um das Schema zu definieren und daraus einen Report zu erstellen. Weiterhin haben wir ein kleines Generierungstool und generieren uns aus dem Report des Modells das eigentliche Schema. Die Generierung erzeugt das Schema mit allen Tabellen, Indizes, allen Anweisungen für referentielle Integrität (teilweise als Trigger, teilweise als Constraint).

PL/SQL T-SQL

ANSI-SQL

Im nachfolgenden Beispiel sehen wir die generierten Quelltexte für die Tabellendefinition für Betriebssystem-Informationen. Die beiden Texte sehen sich noch recht ähnlich, haben aber schon ein paar Unterschiede, die rot gekennzeichnet wurden. Bsp.: Create Table

Der Name von Tabellen darf bei Oracle aus historischen Gründen nur 30 Zeichen betragen, Microsoft hingegen erlaubt bis zu 260 Zeichen. Will man beide Systeme verwenden, muß man praktisch alles auf die kleine Variante reduzieren – also 30 Zeichen. Die Gültigkeit von Namen ist bei Oracle prinzipiell schemaweit. Bei Microsoft muß Indexname nur unikal sein im Zusammenhang mit dem Tabellennamen. Die Wertarten sind ein Thema für sich. Varchar ist Standard für alle variablen Zeichenketten. Oracle besitzt außerdem ein Varchar2. Oracle kennt zwar auch ein varchar, das ist aber kaum in Verwendung. Varchar2 wurde wahrscheinlich deshalb so genannt, weil es ein bißchen anders ist. Microsoft trennt strikt: eine leere Zeichenkette (’’) ist etwas anderes als ein Null-Wert. Oracle sagt, es ist dasselbe. Das kann einem ganz böse auf die Füße fallen, wenn man für beide Plattformen etwas entwickelt. Microsoft kennt für logische Informationen die Wertart Bit. Sie kann die Werte 0,1 und null annehmen und benimmt sich ansonsten wie andere numerische Werte. Oracle hingegen kennt einen richtigen boolean mit true und false. Damit wir aber wieder kompatibel in der ganzen darüber liegenden Umgebung sind, haben wir bei Oracle logische Werte generiert als Numeric (1,0) und interpretieren das auf der Objektebene als logischen Wert mit 0 und 1. Nach außen aus der Objektschicht kommt es als boolean mit true und false wieder an. Ein ganz böses Thema ist der ANSI-Join. Diese Notation kann Oracle überhaupt erst seit Version 9. Leider ist die Implementierung so instabil, da man bei Verwendung der ANSI-Notation Fehler in der Zugriffsschicht provozieren kann, wenn mehr als 5 (Version 9) oder 7 Tabellen (Version 10) beteiligt sind.

Create Table OS ( Ident_OS varchar(32) NOT NULL, UID_Licence char(38) NULL, Name varchar(64) NULL, Version varchar(64) NULL, IsServerOS bit default 0 NULL , IsClientOS bit default 0 NULL , XDateInserted datetime NULL, XDateUpdated datetime NULL, XUserInserted varchar(64) NULL, XUserUpdated varchar(64) NULL, XTouched char(1) NULL Primary Key (Ident_OS) ) go Create Index XIF1126OS on OS ( UID_Licence ) go

Create Table OS ( Ident_OS Varchar2(32 ) NOT NULL, UID_Licence Varchar2(38 ) NULL, Name Varchar2(64 )

NULL, Version Varchar2(64 )

NULL, IsServerOS Number(1,0 ) default 0 , IsClientOS Number(1,0 ) default 0 , XDateInserted Date NULL , XDateUpdated Date NULL , XUserInserted Varchar2(64 ) NULL, XUserUpdated Varchar2(64 ) NULL, XTouched Varchar2(1 ) NULL , Primary Key (Ident_OS) ) go Create Index XIF1126OS on OS ( UID_Licence ) go

Es gab im Jahr 2003 eine Vorstellungskonferenz für Yukon, was dann der Microsoft SQL-Server 2005 wurde. Steve Ballmer ist ja bekannt für seine oftmals humorigen Auftritte. Er hatte sich auf die Bühne gestellt und gesagt: „Microsoft is a Database – Company.“ Kichern, Lachen und Stöhnen im Saal. Aber er ließ sich nicht davon beirren und sagte den Spruch noch einmal. Seit ich den ANSI-Join von Oracle kenne, glaube ich Mr. Ballmer. Weitere Unterschiede, die in schon in der Generierung berücksichtigt werden müssen, sollen nachfolgend nur kurz benannt werden: Standard - Funktionen haben zum Teil unterschiedliche Name und Parametrierungen.

Substring <-> substr left <-> substring(x,1) dateadd, datediiff <-> keine direkte Entsprechung

Diese Funktionen haben wir in Oracle alle nachimplementiert, um sie in der gleichen Notation wie in MSSQL nutzen zu können. DDL-Anweisungen sind bei MSSQL innerhalb einer Transaktionen möglich, bei Oracle beenden sie die Transaktion. Bei MSSQL arbeiten wir aus historischen Gründen Case - Insensitiv, da das in Windows (Konten, Filename) auch so ist. Oracle kennt keine case-insensitiven Daten. Bei Vergleichen muß man also darauf Rücksicht nehmen. Bsp.: MSSQL: Lastname = @Lastname Oracle: upper(Lastname) = upper(v_Lastname) Besonders dramatisch ist das bei Fremdschlüssel - Beziehungen. Bisher war es uninteressant ob ein Wert in der Childrelation groß oder klein geschrieben war, jetzt haben wir auch in MSSQL dafür gesorgt, daß beide den gleichen Case haben. Der 2. Teil der Generierung, umfaßt die referentielle Integrität, was man als Trigger oder als Constraint bauen kann. Wir haben in manchen Fällen das eine, in manchen Fällen das andere gemacht. Nachfolgend sehen wir einen generierten Trigger, einmal die Microsoft-Implementierung und einmal die Oracle-Implementierung. Blau markiert sind die Bereiche, welche noch gleich sind, denn es sind einfach zu viele Sachen, die unterschiedlich sind. Es kommt aber aus derselben Source, aus demselben Schema - Entwurf.

Und dann gibt es noch das Thema:

5.2.2. liebevolle Handarbeit Stellen Sie sich folgenden Fall vor: Eine Person wird Mitglied in einer Abteilung. Es könnte sein, daß sich die Rechtesituation dieser Person ändert, indem die Konten der Person eine Gruppenmitgliedschaft oder irgendwelche Software erben. Demzufolge ist für die Zuweisung der Person zur Abteilung ein Trigger nötig, der einen asynchronen Berechnungsauftrag einstellt. Die Verarbeitung muß asynchron sein, da jede Antwortzeit des Systems über 3 Sekunden vom Anwender nicht akzeptiert wird. Wenn Sie sich mit einem Menschen unterhalten und dieser sie über 3 Sekunden lang starr ohne jede Regung ansieht, dann werden sie unsicher. Man wird skeptisch. Versteht er mich jetzt noch oder muß ich es noch mal sagen oder wie? Genauso gehen wir auch mit dem Computer um. Bei jeder Reaktionszeit unseres Frontends über 3 wird der Anwender unsicher. Die Trigger werden von Hand geschrieben, da wir bisher keinen gescheiten Weg zur Meta-Programmierung gefunden haben. Die Primärimplementierung ist MSSQL. Nachfolgend ein Beispiel für manuell doppelt implementierte SQL-Texte:

exec vidroptrigger 'vi_2LicencePurchase' go create trigger vi_2LicencePurchase on LicencePurchase for Update as begin declare @numrows int, @errno int, @errmsg varchar(255) if 0 = (select count(*) from inserted) + (select count(*) from

deleted) return if (select count(*) from deleted, inserted where deleted.UID_LicencePurchase =

inserted.UID_LicencePurchase ) <> (select count(*) from inserted) begin select @errno = 30002, @errmsg = '#LDS#Änderung des

Primärschlüssels in Tabelle {0} ist nicht zulässig|LicencePurchase'

goto error end end return error:

create or replace trigger vi_8LicencePurchase before update on LicencePurchase

for each row declare numrows int; errmsg varchar2(255); begin select count(*) into numrows from dual where ( :old.UID_LicencePurchase =

:new.UID_LicencePurchase or (:old.UID_LicencePurchase is null and :new.UID_LicencePurchase is null));

if numrows = 0 then errmsg := '#LDS#Änderung des Primärschlüssels in

Tabelle {0} ist nicht zulässig|LicencePurchase'; goto error; end if; return;

Es gibt von der Grundstruktur noch ein paar Ähnlichkeiten, aber es läuft soweit auseinander, daß es nicht mehr automatisch umsetzbar ist. Wir haben uns allerdings die Arbeit des Abschreibens an einer Stelle ein bißchen erleichtert. Wir haben ein Word-Makro gebaut welches ein paar bedingte Ersetzungen enthält. Der MSSQL-Text wird in das Word-Dokument gepackt, das Makro läuft und wir haben die Rohübersetzung für Oracle. Das mag jetzt etwas laienhaft anmuten, hat aber einen sehr praktischen Hintergrund. Wir haben einige Tools ausprobiert, die versprachen, eine SQL-Notation in eine andere umzusetzen. Keines von denen hat Code produziert, der verwendbar gewesen wäre. Entweder gab es Fehler beim Parsen oder der erzeugte Zielcode hat das 10-fache Volumen des primären Codes oder der Zielcode war einfach nur syntaktisch oder inhaltlich falsch. Die größte Erfolgsquote hatten wir letztendlich bei Verwendung des Word-Makros. Die Nacharbeit hält sich in Grenzen und die Struktur der beiden Texte ist immer noch so ähnlich, daß man Änderungen, die sich ja immer im Laufe einer Weiterentwicklung ergeben, in der Sekundär - Implementierung schnell nachziehen kann.

5.2.3. SQL-Formatter Zur Verwendung in den Softwareschichten oberhalb der Datenbank gibt es eine Klasse, die wir SQL-Formatter genannt haben. In diesen Softwareschichten werden die Queries nicht von Hand ausformuliert, sondern der Formatter erzeugt die Einzelteile, die sich unter den eingesetzten Datenbanksystemen unterscheiden. Dies lohnt auch schon bei einfachen String-Vergleichen, da der Formatter auch die Maskierung übernimmt.

create procedure viDropProcedure (@name varchar(64)) as begin declare @cmd varchar(255) declare @owner varchar(255) DECLARE viDropProcedureSchritt SCROLL CURSOR for select rtrim(ROUTINE_SCHEMA) from information_schema.routines where ROUTINE_NAME = @name and ROUTINE_type = 'procedure' for read only OPEN viDropProcedureSchritt FETCH FIRST FROM viDropProcedureSchritt into @owner WHILE (@@fetch_status <> -1) BEGIN select @cmd = 'drop procedure ' + @owner + '.' + @name exec (@cmd) FETCH NEXT FROM viDropProcedureSchritt INTO @owner END close viDropProcedureSchritt deallocate viDropProcedureSchritt end go

create or replace procedure viDropProcedure (in_name IN VARCHAR2 DEFAULT NULL) as cursor schritt_VIDROPPROCEDURE is SELECT object_name FROM user_objects WHERE upper(object_name) = upper(in_name ) and upper(object_name) not like 'VIDROP%' and upper(object_type) = upper('procedure'); v_object_name varchar2(255); cmd varchar2(255); BEGIN open schritt_VIDROPPROCEDURE; loop fetch schritt_VIDROPPROCEDURE into v_object_name; exit when schritt_VIDROPPROCEDURE%notfound; cmd := 'drop procedure ' || v_object_name; EXEC_sql (VIDROPPROCEDURE.cmd); END LOOP; END VIDROPPROCEDURE; go

Beispiel: "Lastname = 'Meier'" Mit Formatter: Connection.SqlFormatter.Comparison("Lastname", "Meier", ValType.String) using System; using System.Collections; using VI.Base; using VI.DB; using VI.DB.Implementation; using VI.DB.Oracle; public class MyClass { public static void Main() { ISqlFormatter mssql = new MicrosoftSqlFormatter(); ISqlFormatter oracle = new OracleSqlFormatter(); // Beispiel für ein Statement WL("Plain", "select * from Person where Lastname = 'Meier'"); // Formatiert für MS SQL WL("1. MS SQL", "select * from Person where " + mssql.Comparison("Lastname", "Meier", ValType.String)); // Und Oracle WL("1. Oracle", "select * from Person where " + oracle.Comparison("Lastname", "Meier", ValType.String)); // Mit Hochkommas WL("2. MS SQL", "select * from Person where " + mssql.Comparison("Lastname", "O'Donnell", ValType.String)); WL("2. Oracle", "select * from Person where " + oracle.Comparison("Lastname", "O'Donnell", ValType.String)); // Unicode WL("3. MS SQL", "select * from Person where " + mssql.Comparison("Lastname", "\u0425\u0440\u0443\u0449\u0451\u0432", ValType.String)); WL("3. Oracle", "select * from Person where " + oracle.Comparison("Lastname", "\u0425\u0440\u0443\u0449\u0451\u0432", ValType.String)); // Aufruf einer Stored Procedure WL("4. MS SQL", mssql.StoredProcedure( "TestProc", mssql.FormatValue("Test", ValType.String, true), mssql.FormatValue(42, ValType.Int, true))); WL("4. Oracle", oracle.StoredProcedure(

"TestProc", oracle.FormatValue("Test", ValType.String, true), oracle.FormatValue(42, ValType.Int, true))); } public static void WL(string prefix, string mssql, string oracle) { Console.WriteLine("{0}:", prefix); Console.WriteLine("MS SQL:\t" + mssql); Console.WriteLine("Oracle:\t" + oracle); Console.WriteLine(); } } Da der Formatter nur Teile von Statements formatiert, kann man komplexe Statements nach Systemen getrennt in einer Resource-Datei hinterlegen und nur Vergleiche gegen dynamische Werte per Formatter einfügen.

5.3. Frontend – Ebene Das Frontend soll sowohl als Fat-Client laufen als auch als Thin-Client im Web. Wir haben insgesamt über 500 Tabellen im Datenmodell, zu jeder Tabelle muß es Formulare geben, mit denen die Daten bearbeitbar werden. Dazu kommt noch eine Menge an Zuordnungs- und Übersichtsformularen. Diese Formulare in zwei verschiedenen Systemen zu bauen, hätte unsere Kapazitäten gesprengt. Unser Ziel war demzufolge ein Compilat für alle zu erhalten. Wir haben diese Zielstellung so erreicht, indem wir Layout und Funktionen strikt getrennt haben. Ein Frontend besteht immer aus 2 Bestandteilen, der Darstellung und dem dahinter liegenden Code. Die Darstellung ist z.B. die Definition eines Buttons, der Code der dazugehörige Click-Eventhandler. Die Darstellung wird durch eine bei uns entwickelte Engine aus einer in XML hinterlegten Beschreibung gerendert. Der Code liegt als DLL bei und spricht die jeweiligen Frontend-Controls über Schnittstellen an. Für jedes Control gibt es eine Fat- und eine Web-Client-Implementierung. Der Fat-Client basiert auf Windows-Forms, d.h. wir haben die bestmögliche Integration in die Windows-Umgebung. Er läuft derzeit nicht unter Mono, da nicht portable Fremdcontrols verwendet wurden. Der Web-Client besitzt ein eigenes Control-Set, welches dieselben Interfaces wie der Fat-Client implementiert. Die Kommunikation mit dem Server erfolgt über Javascript. Das ermöglicht eine Aktualisierung der Control-Inhalte ohne eine kompletten Roundtrip für die angezeigte Seite. Einen ersten Prototyp dieser Lösung hatten wir 2001 gebaut. Heute ist diese Art der Kommunikation allgemein als “Ajax“ bekannt. Damit ist das Problem der Nutzer-Interaktion gelöst. Wenn ein Wert geändert wird (z.B. der Nachname einer Person) so ändert sich direkt ein anderer davon abhängiger Wert (z.B. die EMail-Adresse). Diese Änderung soll dem Nutzer immer sofort angezeigt werden.

Die Navigation ist in der Datenbank hinterlegt und wird durch die jeweilige Engine interpretiert. Für den jeweiligen Kunden an seine Bedürfnisse anpaßbar. Zum Schluß noch einen kurzen Blick auf die Statistik. Der gesamte Quelltext von ActiveEntry ohne Dokumentation und ohne kundenspezifische Anpassungen umfaßt 162 MB. Die einzelnen Bestandteile wurden klassifiziert nach den 3 Bereichen

- allgemein gültig - Meta-Programmierung - Doppelimplementierung

Die beste Nachnutzung haben wir auf der Objektebene, da handelt es sich nur um ein paar Prozent, die doppelt implementiert werden mußten und deswegen keiner weiteren Beachtung benötigen. Viele Quellen sind hier allgemein gültig, zumal die Objektebene auch vom Gesamtvolumen her das Größte ist. Im Frontend ist uns das nicht ganz so gut gelungen. Wir haben 7 MB Quelltext im Frontendbereich als Doppelimplementierung, das sind vor allem die Controls für Fat-Client und die Controls für Thin-Client.

Softwareebene Doppelt implementiert Allgemeingültig

Auf Meta-Ebene Gesamtergebnis

DBLayer 11.280.750 9.352.411 5.663.247 26.296.408

Object 4.601 74.243.447 74.248.048

Frontend 7.782.746 20.984.713 20.469.139 49.236.598

Tools 1.115.490 1.115.490

Unit 17.362 11.522.995 11.540.357 Gesamt: Summe von Byte 19.085.459 117.219.056 26.132.386 162.436.901 Lines of Code ist die Meßgröße, mit der üblicherweise hantiert wird. Insgesamt haben wir inzwischen 3,4 Millionen Zeilen erstellt. Mit Dokumentation und kundenspezifischen Projekten, die wir im Laufe der Jahre gebaut haben, sind es noch einmal so viel, also insgesamt fast 7 Millionen Quelltextzeilen.

Softwareebene

Doppelt implementiert Allgemeingültig

Auf Meta-Ebene Gesamtergebnis

DBLayer 320.673 215.765 171.775 708.213

Object 171 1.215.790 1.215.961

Frontend 247.561 593.827 462.788 1.304.176

Tools 34.110 34.110

Unit 516 209.805 210.321 Gesamt: Summe von Lines 568.921 2.269.297 634.563 3.472.781 Am spannendsten scheint jedoch die Zusammenstellung nach Prozenten zu sein. Die Datenbankschicht hat 16 % Anteil am Gesamtprodukt. In diesem Bereich haben wir aufgrund der SQL-Unterschiede die schlechteste Quote der Allgemeingültigkeit erreicht, aber immerhin mit Meta-Ebene und Allgemeingültigkeit trotz der großen Differenzen zwischen den SQL-Dialekten nur 42 % doppelt entwickelt. Bei den Frontends haben wir mit 80 % Allgemeingültigkeit eine passable Quote erreicht. Spezielle Buildtools, welche im Daily-Build-Prozess gebraucht werden, haben wir vollständig allgemeingültig und bei den Unit-Tests sind es auch nahezu 100%

Softwareebene Doppelt implementiert Allgemeingültig

Auf Meta-Ebene

Anteil am Gesamtprodukt

DBLayer 42,9% 35,6% 21,5% 16,2%

Object 0,0% 100,0% 45,7%

Frontend 15,8% 42,6% 41,6% 30,3%

Tools 100,0% 0,7%

Unit 0,2% 99,8% 7,1%

Gesamtprodukt 11,7% 72,2% 16,1% 100,0%