Nächste Seite: Historische Ansätze Aufwärts: Diplomarbeit: Management verteilter Systeme Vorherige Seite: Geschichte des Systems- und Inhalt
In diesem Kapitel sollen die Grundlagen erläutert werden, welche die technischen Voraussetzungen für das Common Information Model bilden, das in Kapitel 5 detailliert besprochen wird. Zunächst soll erläutert werden, welche Tätigkeiten das Systems- und Konfigurationsmanagement umfasst (Kapitel 3.1). Danach werden Grundlagen und aktuelle Ansätze zur Konfiguration von Anwendungen erläutert (Kapitel 3.2). Schließlich werden die Standards vorgestellt, auf denen CIM beruht. Dies sind:
Die Reihenfolge richtet sich dabei nach der zeitlichen Entstehung der Standards.
Wie in der Einleitung bereits angedeutet wurde, fallen unter das Systems Management alle Tätigkeiten im Rahmen des Betriebs eines Informationssystems. Diese sind Aufgaben, die im Anschluss an eine erfolgreiche Inbetriebnahme nötig sind, um ein zufriedenstellendes Funktionieren des Systems sicherzustellen. Dazu sind im Genauen zwei Dinge durchzuführen:
Diese beiden Aufgaben, also Überwachung und Steuerung, stehen in einem ständigen Wechsel zueinander: Wird im Rahmen der Überwachung festgestellt, dass eine Änderung am System nötig ist, muss anschließend im Rahmen der weiteren Überwachung beobachtet werden, ob die Modifikationen wirksam sind.
Die genauen Aufgaben, die beim Betrieb eines IT-Systems durchzuführen sind, wurden in den achtziger Jahren durch die ISO kategorisiert [4]. Damals war man auf der Suche nach einem methodischen Ansatz für das Management von Netzwerken, da viele verschiedene Netzwerkstandards Verbreitung gefunden hatten und eine einheitliche Verwaltung unmöglich war.
Die Kategorien des Systems Management (siehe auch Abbildung 3.1) sind im Einzelnen:
Dabei kommt es darauf an, einen Fehler korrekt einzugrenzen: Beispielsweise könnte ein Überwachungssystem zu dem Schluss kommen, dass ein Netzwerkgerät, das sich aus Sicht des Managers hinter einem anderen Gerät befindet, defekt ist, obwohl es nur nicht erreicht werden kann, da die davorgeschaltete Komponente ausgefallen ist.
Im Rahmen des Performance Managements ist es zusätzlich sinnvoll, Tendenzen zu erkennen, die sich bei den Messungen feststellen lassen, um Maßnahmen zu treffen, bevor sich die Leistung des Systems nicht mehr in den festgelegten Randparametern bewegt.
![[*]](footnote.png)
.
Die Gesamtaufgabe des Sicherheitsmanagement ist in jedem Falle
oder höhere Gewalt.
Unter die Aufgaben des Sicherheitsmanagements fallen beispielsweise (die Liste ließe sich fast beliebig fortsetzen):
In diesem Kapitel soll auf das Konfigurationsmanagement eingegangen werden (Kapitel 3.2.1).
Anschließend werden spezielle vorhandene Schnittstellen behandelt, die Betriebssysteme und Anwendungen mit Konfigurationsdaten versorgen (Kapitel 3.2.2). Solche Schnittstellen sind für das Konfigurationsmanagement von höchster Bedeutung, speziell auch im praktischen Teil dieser Arbeit (Kapitel 8).
Unter das Konfigurationsmanagement als Disziplin des Systems Management fallen gängiger Literatur ([4], [28]) nach zwei völlig verschiedene Begriffe:
Damit verbunden ist auch der Aspekt der Paketierung von Software und seine Verteilung auf einzelne Rechnersysteme. Softwareanwendungen weisen inzwischen oft einen Umfang auf, der nicht einmal mehr auf einer CD-ROM Platz findet. Ein effizientes Konfigurationsmanagement kann zusätzlich dadurch erschwert werden, dass eine Softwareinstallation per Fernwartung nicht möglich ist, sondern ein Servicetechniker diese vor Ort vornehmen muss.
Zur Lösung der Probleme, die im Bereich der Softwareversionierung und -paketierung seit dem Aufkommen hochgradig verteilter Systeme bestehen, konnten sich zwischenzeitlich diverse Lösungen durchsetzen:
Der für diese Arbeit interessante Teil des Konfigurationsmanagement ist aber die eigentliche
Bei jedem Rechner- und Anwendungssystem müssen vor seiner Inbetriebnahme Einstellungen vorgenommen werden. Diese bleiben über den Einsatzzeitraum des Systems hinweg in der Regel nicht unverändert, sondern müssen geänderten Bedürfnissen angepasst werden.
Die einzelnen Anpassungen sind dabei meist die Ergebnisse anderer Bereiche des Systems Management:
Eine treffende und umfassende Definition für das Konfigurationsmanagement[13] liefert die Gesellschaft für Informatik:
| Definition Konfigurationsmanagement (GI)
Identifikation der (Software-) Konfiguration eines Systems zu diskreten Zeitpunkten zum Zwecke der systematischen Steuerung von Konfigurationsänderungen und der Aufrechterhaltung der Vollständigkeit und Verfolgbarkeit der Konfiguration während des gesamten Software-Lebenszyklusses. |
Dem Verständnis der GI zufolge ist also auch die zeitliche Nachvollziehbarkeit in Form einer Versionierung für das Konfigurationsmanagement essentiell.
Konfigurationsdateien sind der älteste und einfachste Ansatz zur System- und Softwarekonfiguration. Dabei werden Konfigurationsdaten einfach in einer Textdatei hinterlegt, die durch den Systemverwalter bearbeitet werden kann.
Dieser Ansatz zur Konfiguration kommt klassischerweise in UNIX-Umgebungen zum Einsatz, wobei hier für jede Systemkomponente eine oder mehrerer Dateien verwendet werden. Das gleiche gilt für frühere DOS- oder Windows-Systeme, bei denen diese Dateien die Endung .ini führten. Damit es bei UNIX dennoch nicht zu einer unübersichtlichen Verteilung der Konfigurationsdaten kommt, befinden sich die Dateien gesammelt im Systemverzeichnis /etc.
Eine Konfigurationsdatei selbst besteht in der Regel aus einer Folge von Schlüssel-Wert-Paaren. Ihre Komplexität erwächst jedoch aus
Dies soll anhand eines Ausschnittes aus der Konfigurationsdatei für den Apache-Webserver erläutert werden:
UseCanonicalName On DefaultType text/plain <Directory "/var/www/icons"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory>
Die Optionen, die sich im Directory-Abschnitt befinden, gelten nur für ein bestimmtes Verzeichnis. Wären die Schlüssel-Wert-Paare an anderer Stelle notiert, würden sie global gelten.
Der Schlüssel Options enthält zwei Werte. Im Falle des Apache werden sie durch Whitespaces getrennt notiert. Die Trennung durch Leerzeichen gilt auch für die Unterscheidung zwischen Schlüssel und Wert. Bei anderen Programmen (z.B. dem Mailserver Postfix) muss hier das Gleichheitszeichen (=) verwendet werden.
Eine maschinelle Verarbeitung solcher Konfigurationsdateien durch Werkzeuge zum Systems Management bringt durch diese hohe Komplexität viele Schwierigkeiten mit sich. So muss das Werkzeug wissen, welche Schlüssel-Wert-Trennung Gültigkeit hat und in welcher Verschachtelungsebene Konfigurationsparameter einzufügen sind.
Die Windows-Registry ist eine zentrale Konfigurationsdatenbank, in der seit Windows 95 die Daten des Betriebssystems und aller installierter Anwendungen an zentraler Stelle gehalten werden. Damit wurden die früher üblichen .ini-Dateien abgelöst.
Der Vorteil der Zentralisierung birgt natürlich auch ein Risiko: Eine Inkonsistenz in dieser zentralen Datenbank kann eine komplette Neuinstallation des System nötig machen.
Die Registry ist eine hierarchisch gegliederte Datenbank (Abbildung 3.2). Sie besteht aus sechs Hauptästen, in denen sich beliebig tief verschachtelt weitere Äste befinden (dies entspricht den verschachtelten Optionen in einer Konfigurationsdatei). Jeder Ast besitzt eine beliebige Menge an Blättern, die einem Schlüssel entsprechen.
Die Bedeutung der sechs Hauptäste ist [20]:
Der Zugriff auf die Registry kann ausschließlich über die API des Betriebssystems erfolgen, bei der die Übergabe von Schlüssel und Werten über Objekte geschieht. Microsoft stellt für den manuellen Eingriff in die Datenbank ein spezielles Programm, den Registierungs-Editor (Abbildung 3.2), zur Verfügung.
Besonders im Java-Umfeld etabliert sich momentan XML (siehe auch Kapitel3.3) als Konfigurationsschnittstelle. Deshalb erfolgt hier ein kurzer Vorgriff auf das nächste Kapitel, das sich speziell mit XML beschäftigt.
Über eine spezielle Document Type Definition (DTD), die nicht nur die Struktur, sondern auch die semantische Bedeutung der Konfigurationsdaten abbildet, können diese in einer Form abgelegt werden, die eine manuelle und eine automatisierte Verarbeitung ermöglichten. Für die automatisierte Verarbeitung von XML-Dateien steht eine große Auswahl an Werkzeugen und APIs zur Verfügung.
Ein Beispiel für eine XML-konfigurierbare Anwendung ist der WebSphere Application Server von IBM, dessen Konfiguration hier ausschnittsweise dargestellt ist:
<virtual-host name="default_host" action="update">
<mime-table>
<mime type="audio/x-wav">
<ext>wav</ext>
</mime>
<mime type="application/x-sv4cpio">
<ext>sv4cpio</ext>
</mime>
...
...
</mime-table>
<alias-list>
<alias>localhost</alias>
<alias>127.0.0.1</alias>
<alias>MY400.MYCOMPANY.COM</alias>
</alias-list>
...
Konfigurationsdateien sind einfach zu implementieren, jedoch für eine automatisierte Bearbeitung in ihrer Struktur zu uneinheitlich.
Die Windows-Registry steht diesem entgegen: Sie ist ein einheitliches zentrales Repository, das eine konsistente API bietet. Außer mit speziellen Werkzeugen ist aber kein Zugriff darauf möglich.
Ein XML-basierter Ansatz vereinigt die Vorteile der beiden Lösungen: Die Konfigurationsdaten können händisch oder maschinell bearbeitet werden. Die Datenhaltung selbst kann je nach Bedarf zentralisiert (in einer XML-Datenbank) oder in einzelnen Dateien erfolgen.
Die Textbeschreibungssprache SGML reicht in ihrer Entstehungsgeschichte bis in die späten 60er Jahre zurück, eine Normierung erfolgte erstmals 1983 als ANSI-Standard GCA 101-1983 [6]. Üblicherweise erfolgte damals eine direkte Formatierung von Dokumenten, so dass beispielsweise Textpassagen, die in der Ausgabe fett erscheinen sollten, mit dem Attribut fett versehen wurden.
Gerade im Verlagswesen führte dies schon bald zu Problemen, da man sich nicht an eine direkte Formatierung binden wollte. So kam das Konzept einer Trennung von Struktur eines Dokuments und Inhalt auf (TUNNICLIFFE, 1967). Die Formalisierung erfolgte kurz danach (GOLDFARB, MOSHER, LORIE) durch die IBM in Form der Generalized Markup Language (GML). Das Konzept sah vor:
SGML ist das Ergebnis der anschließend folgenden Standardisierung durch
ANSI und ISO. Dass sich dieser Standard für allgemeine Anwendungen nie
durchsetzen konnte, lag vermutlich an seiner hohen Universalität und
dadurch bedingten
Komplexität.
Das World Wide Web, das sich seit 1991 als der Standard für verteilten Informationsaustausch im Internet etablierte, benötigte eine zugrunde liegende Technik für die Repräsentation seiner Inhalte. Wesentliches Merkmal des WWW ist die Möglichkeit, einzelne Dokumente durch Querverweise (Links) miteinander zu verknüpfen. Informationen, die auf diese Weise dargestellt werden, werden auch als Hypertext bezeichnet.
Auch für das WWW ist eine Trennung von Struktur und Darstellung der Inhalte sinnvoll, da die Programme zur Darstellung der Inhalte (Browser) verschiedene Darstellungstechniken nutzen -- beispielsweise kann der Browser in einem textbasierten Terminal laufen, so dass grafische Inhalte wegfallen oder über Umwege dargestellt werden müssen.
Somit bot sich SGML als Grundlage für die Hypertext Markup Language (HTML) an. Aufgrund der hohen Komplexität von SGML entschied man sich jedoch zunächst dafür, sich an diesen Standard anzulehnen ohne vollständig konform mit ihm zu sein.
Eine einfache HTML-Seite kann etwa so aussehen:
<html>
<head>
<title>Bestellung von Kartenmaterial</title>
</head>
<body>
<h1>Europakarten</h1>
<p>Herzlich Willkommen! Hier finden Sie durch Anklicken
auf der Karte mehr Informationen zu den jeweiligen
Ländern:</p>
<img src="euro.jpg" border=4 usemap="#euro">
<hr>
<a href="mailto:verlag@karten.de">e-Mail</a> an den
Verlag.
</body>
</html>
Dieser Code führt dazu, dass im Browser in der Titelzeile der Text dargestellt wird, der in den Tags <title> und </title> eingefasst ist. Genauso wird der Text innerhalb der BODY-Anweisungen im Browserfenster angezeigt, wobei die hierin verschachtelten Anweisungen für eine weitere Untergliederung sorgen. Durch Anklicken von Bereichen auf dem Bild euro.jpg gelangt der Nutzer per Hyperlink auf eine Seite, die Informationen zu einem bestimmten Land vorhält.
Das World Wide Web
Consortium (W3C), das HTML standardisiert, hat
HTML in der Version 2.0 dann so überarbeitet, dass es SGML-konform ist.
Dies bedeutet, dass eine SGML-DTD existiert, die dem HTML-Standard
entspricht.
Obwohl HTML standardisiert wurde, kam es durch proprietäre Erweiterungen seitens der Browserhersteller zu einem starken Wildwuchs. Für eine neue Beschreibungssprache, die SGML und HTML vereinigen sollte, ergaben sich so folgende Anforderungen:
Dies führte 1998 zur Definition der Extensible Markup Language (XML) durch das W3C [2].
Nachdem im Rahmen von SGML und HTML bereits einige Andeutungen an XML anklangen, soll sie nun im Detail erläutert werden. Zunächst wird dabei auf die vorhandenen Sprachelemente eingegangen (Kapitel 3.3.3.1), anschließend auf den Einsatz von DTDs (Kapitel 3.3.3.2) und zuletzt auf die Möglichkeiten der Verarbeitung (Kapitel 3.3.3.3).
Zur Erläuterung der Struktur eines XML-Dokuments hier ein kleines Beispiel in Form eines Literaturverzeichnisses:
<?xml version="1.0" standalone="yes" encoding="UTF-8"?> <BOOK> <AUTHOR>Kernighan, B.W.</AUTHOR> <AUTHOR>Ritchie, D.M.</AUTHOR> <TITLE>The C Programming Language</TITLE> <PUBLISHER>Prentice Hall</PUBLISHER> <YEAR>1978</YEAR> </BOOK> <BOOK> <AUTHOR>Kopka, H.</AUTHOR> <TITLE>LaTeX, Eine Einführung</TITLE> <PUBLISHER>Addison-Wesley</PUBLISHER> <YEAR>1992</YEAR> </BOOK>
Zur Ausweisung als XML-Dokument dient die erste Zeile. Bei Anweisungen dieser Form handelt es sich um eine Deklaration.
Die Marken <BOOK>, <AUTHOR> usw. sind Elemente. Ein Element muss immer geschlossen werden, dies geschieht durch die gleiche Marke mit einem vorangestellten / (wie z.B. </BOOK>).
Damit ein XML-Dokument wohlgeformt ist, gilt für die Verschachtelung der Elemente das Stack-Prinzip. Das würde bedeuten, dass eine Struktur wie
<BOOK> <AUTHOR>Kernighan, B.W.</BOOK> </AUTHOR>
bei der zuerst ein äußeres Element geschlossen wird, ungültig ist. Elemente dürfen auch leer sein -- in diesem Fall ist eine abkürzende Darstellung möglich. Dies zeigen die beiden nächsten Zeilen, deren Bedeutung identisch ist:
<BOOK></BOOK> <BOOK/>
Bei der Benennung von Elementen ist zu beachten, dass zwischen Groß- und Kleinschreibung unterschieden wird, das heißt <BOOK> und <book> sind verschiedenartige Elemente.
Elemente können auch um Attribute erweitert werden, wie in diesem Beispiel:
<BOOK> <AUTHOR id="kopka">Kopka, H.</AUTHOR> <TITLE>LaTeX, Eine Einführung</TITLE> <PUBLISHER id="a-w">Addison-Wesley</PUBLISHER> <YEAR>1992</YEAR> </BOOK> <BOOK> <AUTHOR idref="kopka"/> <TITLE>LATEX 2. Ergänzungen</TITLE> <PUBLISHER idref="a-w"/> <YEAR>1994</YEAR> </BOOK>
Dabei wird dem Element AUTHOR das Attribut id als Schlüssel zugewiesen. Dies dient in diesem Fall einer späteren Referenz.
Im obigen Beispiel des Literaturverzeichnisses enthielt die Kopfdeklaration das Attribut standalone=yes. Dies führt bei der Verarbeitung eines XML-Dokuments dazu, dass:
Dies ist aber nicht immer wünschenswert. Um beispielsweise das obige Verzeichnis sinnvoll verarbeiten zu können, sollte nur ein bestimmter Vorrat an Elementen verwendet werden, nämlich solche, die für ein solches Verzeichnis benötigt werden. Außerdem macht es keinen Sinn, innerhalb eines TITLE-Elements weitere BOOK-Elemente einzufügen.
Zur Definition der inhaltlichen Struktur eines XML-Dokuments kommen daher die von SGML bekannten DTDs zum Einsatz, welche von theoretischen Standpunkt einer kontextfreien Grammatik entsprechen.
Wird die DTD des Literaturverzeichnisses in der Datei document.dtd abgelegt, muss in der XML-Datei anfangs mit der Deklaration <!DOCTYPE Document SYSTEM document.dtd> bekannt gemacht werden, welche DTD zum Einsatz kommt. Die DTD selbst könnte so aussehen:
<!DOCTYPE bib [
<!ELEMENT BIB (BOOK+)>
<!ELEMENT BOOK (AUTHOR+, TITLE, PUBLISHER?, YEAR?)>
<!ATTLIST BOOK
isdn CDATA #IMPLIED
nickname CDATA #IMPLIED>
<!ELEMENT AUTHOR (#PCDATA)>
<!ATTRLIST AUTHOR
id ID #IMPLIED
idref IDREF #IMPLIED>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT PUBLISHER (#PCDATA)>
<!ELEMENT YEAR (#PCDATA)>
]>
In diesem Beispiel dürfte leicht zu erkennen sein, worum es geht, wenn man die ELEMENT-Deklarationen als reguläre Ausdrücke versteht:
Die Spezifikation gültiger Attribute eines Elements erfolgt ein wenig anders: Durch die Deklaration ATTLIST wird festgelegt, welches Attribut in welcher Kardinalität ein Element aufweisen kann. Dabei steht #IMPLIED für ein optionales und #required für ein zwingendes Erscheinen. XML sieht für Attribute verschiedene Datentypen vor, wobei CDATA als beliebiger String der häufigste ist.
Ein XML-Dokument, das konform zu einer DTD ist, ist valide bzw. gültig.
Auch wenn XML-Dokumente für den Menschen gut lesbar sind, besteht
deren Sinn primär in einer automatisierten elektronischen
Verarbeitung. Dabei ist XML sowohl für die Datenspeicherung als auch für
den Datenaustausch gut geeignet. Zur Speicherung von XML wurde bereits
spezielle Datenbanksysteme entwickelt.
Der algorithmischen Verarbeitung eines XML-Dokuments dient ein XML-Parser. Dabei haben sich zwei API-Ansätze etabliert:
Dies ermöglicht eine schnelle und speichersparende Verarbeitung von großen Dokumenten, da nur die Elemente geparst werden, die für das Programm interessant sind. Dafür ist aber nur ein sequentieller Zugriff auf das Dokument möglich. Eine Bearbeitung kann nicht erfolgen.
Die erklärte Grundlage von XML wie von SGML ist die Repräsentation von Daten, ohne dabei auf die Darstellung dieser Daten einzugehen. Doch gerade ein Literaturverzeichnis wie das obige soll vielleicht einmal in einem Buch abgedruckt werden.
Genau dazu dienen XML-Stylesheets, die in der Extensible
Stylesheet Language (XSL) formuliert werden. Sie ist auch in der Lage,
XML-Dokumente umzustrukturieren, um verschiedene Darstellungsformen
ineinander umzuwandeln. Der XSL-Code zur Umwandlung der obigen
Bibliografie in ein HTML-Dokument könnte wie folgt aussehen:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<HTML><xsl:apply-templates/></HTML>
</xsl:template>
<xsl:template match="BIB">
<UL><xsl:apply-templates/></UL>
</xsl:template>
<xsl:template match="BOOK">
<LI><xsl:apply-templates/></LI>
</xsl:template>
<xsl:template match="AUTHOR">
<xsl:value-of select="."/>
</xsl:template>
<xsl:template match="TITLE">
<EM><xsl:value-of select="."/></EM>
</xsl:template>
</xsl:stylesheet>
In diesem Beispiel kommen nur zwei einfache Mechanismen zum Einsatz:
Während das Kapitel 3.3.2 die für das World Wide Web verwendete
Seitenbeschreibungssprache behandelte, mit welcher der Inhalt codiert
wird, benötigt das WWW auch einen Standard für den Transport
dieser Daten. Hier kommt das Hypertext Transport Protocol (HTTP)
zum Einsatz, das durch die Internet Engineering Task Force
(IETF) als RFC 2616 normiert wurde.
HTTP soll an dieser Stelle erläutert werden, da es im Rahmen des Common Information Model von Bedeutung ist.
Grundsätzlich basiert HTTP auf einem Frage-Antwort-Dialog zwischen Client und Server, wobei ein Webbrowser die Rolle des Clients übernimmt und ein spezieller Systemdienst -- der Webserver -- die Rolle des Servers [29], wie dies in Grafik 3.4 dargestellt ist. HTTP befindet sich dabei im Sinne des ISO/OSI-Schichtenmodells auf der Anwendungsebene. Auf Transportebene kommt TCP zum Einsatz. Standardmäßig wird für HTTP der Port 80 verwendet.
Die Anfrage eines Clients besteht aus einer Textzeile, die so aussehen kann:
GET /projects/bahn-bilder/
Diese Zeile besteht aus zwei Teilen:
|
Je nachdem, ob die Verarbeitung des Requests durch den HTTP-Server erfolgreich war oder nicht, antwortet dieser mit verschiedenen Statuscodes, denen der Seiteninhalt angehängt wird. Welche Codes die gebräuchlichsten sind, geht aus Tabelle 3.2 hervor.
|
Um innerhalb einer Anfrage weitere Parameter übergeben zu können, kann ein Client seit Version 1.0 des HTTP-Protokolls hinter der Request-Zeile zusätzlich Angaben übermitteln. Genauso können serverseitig Zusatzinformationen im Anschluss an den Statuscode übergeben werden.
Beispielsweise übermittelt ein Browser folgende Header-Zeilen:
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/
jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE
5.01; Windows NT)
Host: kj.uue.org
Connection: Keep-Alive
Damit wird spezifiziert, welche Grafikformate, Sprachen und Datenkompressionsmethoden der Client verarbeiten kann. Außerdem wird über den Host-Header explizit angegeben, auf welchen Webserver zugegriffen wird, womit die Realisierung mehrerer Server auf einer IP-Adresse möglich ist (virtuelle Webserver).
Die Antwort des Webservers kann daraufhin die folgende Gestalt haben:
HTTP/1.1 200 OK Date: Mon, 30 Dec 2002 12:32:26 MET Server: Apache/1.3.27 (Unix) Last-Modified: Mon, 30 Dec 2002 03:06:11 MET Content-length: 327 Connection: close Content-type: text/html <html>...
So teilt der HTTP-Server dem Client mit, wann das Dokument zuletzt bearbeitet wurde (Last-Modified), wie groß es ist (Content-length) und um welchen Typ von Daten es sich handelt (Content-type). Außerdem wird die aktuelle Uhrzeit übertragen (Date), was in Zusammenhang mit dem Modifikationsdatum ein Caching von Dokumenten erlaubt. Im Anschluss an eine Leerzeile folgt der Dokumenteninhalt, in diesem Beispiel ein HTML-Dokument.
Schon in verteilten Informationssystemen kleiner bis mittlerer Größe kommt schnell eine grundlegende Frage auf: Wo befindet sich eine Ressource, und wie kann ich sie erreichen? Um diesem Problem entgegenzutreten, kam es zur Entwicklung von Netzwerkverzeichnisdiensten, in denen zentral Adressdaten gesammelt werden und aus denen diese Daten über eine Abfragesprache selektiv gewonnen werden können.
Bei einem solchen Verzeichnisdienst handelt es sich -- vereinfacht ausgedrückt -- um das elektronische Pendant zu einem Telefonbuch, welches von einem Teilnehmer des Netzwerks ,,Telefonnetz`` verwendet wird um eine spezifische Ressource ,,Telefonnummer`` zu finden.
Ohne einen speziellen Verzeichnisdienst wäre das Internet in seiner heutigen Größe nicht vorstellbar: Der Domain Name Service (DNS) ist ein verteilter Verzeichnisdienst, in dem die Netzwerknamen sowie die zugehörigen numerischen Netzwerkadressen aller erreichbarer Rechnersysteme hierarchisch erfasst sind.
Beispielsweise ist der Rechner twix im studentischen Rechnerpool
der Fachhochschule Heilbronn in Deutschland unter dem DNS-Namen twix.stud.fh-heilbronn.de zu erreichen. Ohne einen DNS-Eintrag müsste
man seine eigentliche IP-Adresse (141.7.11.107)
kennen.
Die folgenden Eigenschaften sind typisch für einen Verzeichnisdienst [16] -- für sie ist ein solcher Dienst entsprechend optimiert:
Im Rahmen von ISO/OSI-Netzwerken wurde bereits ein Dienst für den Zugriff auf beliebige Verzeichnisdaten standardisiert -- dabei handelte es sich um das Directory Access Protocol (DAP). Die Struktur des Verzeichnisses selbst schrieb der Standard X.500 der ITU fest.
Da beide Normen einen hohen Komplexitätsgrad aufwiesen, konnten sie sich allerdings kaum durchsetzen.
Um die Lücke für einen offenen Standard für einen Verzeichnisdienst zu füllen, wurde 1992 das Lightweight Directory Access Protocol (LDAP) als RFC 1487 definiert. Wie im Name angedeutet, handelt es sich bei LDAP um eine ,,abgespeckte``Version von DAP. Als Grundlage wurden nun die Internet-Protokolle gewählt, während die Verzeichnisstruktur, die LDAP ebenfalls spezifiziert, eine Adaption von X.500 ist.
Wie in einem Verzeichnisdienst üblich, sieht X.500 und LDAP eine hierarchische Verzeichnisstruktur vor. X.500 und LDAP gehen hierbei aber so weit, dass eine weltweit eindeutige Identifikation eines Verzeichnisobjekts möglich ist (Abbildung 3.5).
Anhand der Grafik ist zu erkennen, an welcher Position innerhalb des Verzeichnisses der Student Max Muster eingeordnet wurde. Über diese Position kann ein Schlüssel für den Personeneintrag abgeleitet werden. Dabei werden die Schlüssel der darüber stehenden Objekte hierarchisch geordnet und durch Komma getrennt notiert. Zusätzliche wird für jede Hierarchieebene ein Kürzel des Objekttyps angegeben.
Damit bekommt der Student Max Muster innerhalb des Studiengangs Medizinische Informatik an der Fachhochschule Heilbronn in Deutschland den folgenden Schlüssel, unter LDAP auch Distinguished Name (DN) genannt:
cn=Max Muster, ou=Studenten, ou=FB Medizinische Informatik, o=FH Heilbronn, c=DE
Werden in jeder Ebene mehrere Einträge aufgenommen, ergibt sich eine baumförmige Struktur. Daraus leitet sich der Begriff Directory Information Tree (DIT) für die Gesamtmenge aller Verzeichniseinträge ab.
Wie im vorherigen Kapitel bereits angerissen, besitzt jedes Objekt in LDAP einen Objekttyp. Er legt fest, welche Attribute dieses Objekt umfasst. Es gibt dabei
Attribute. Um eine übersichtliche Struktur der Klassen und eigene Erweiterungen innerhalb von LDAP zu ermöglichen, handelt es sich bei den Objektklassen selbst um eine Hierarchie. Erweiterungen am Datenmodell können über Vererbung eingebunden werden.
Abbildung 3.6 zeigt dies anhand einiger Klassen aus dem LDAP-Standard. Insgesamt sind momentan ca. 150 Klassen für verschiedene Anwendungfälle wie Personenverzeichnisse, UNIX-Benutzerverwaltung oder DNS-Abbildung definiert.
Während so die Klasse person über die zwingenden Attribute sn (Nachname) und cn (Name) sowie über die optionalen Attribute userPassword, telephoneNumber, seeAlso und description verfügt, gibt es bei der abgeleiteten Klasse residentialPerson für Privatadressen zusätzlich die Attribute l (Ort), postalCode (PLZ), postalAddress, sowie viele mehr.
Eine Mehrfachvererbung ist ebenfalls möglich, indem ein Objekt die Attribute mehrerer Klassen beinhaltet. Dies ist beispielsweise sinnvoll, wenn ein Angestellter (mit der Objektklasse organizationalPerson) gleichzeitig UNIX-User ist (Objektklasse posixAccount).
Um Einträge aus einer Datenbank selektieren zu können, bedarf es einer Abfragesprache. LDAP stellt dafür einfache Suchfilter zur Verfügung, bei denen sich Attributwerte in Prefix-Notation miteinander verknüpfen lassen.
Der Suchfilter
(&(sn=M*)(givenName=M*))
führt so zu einer Suche nach allen Objekten, deren Vor- und Nachname mit dem Buchstaben M beginnt.
LDAP bietet damit im Vergleich zu einer relationalen Datenbank nur sehr begrenzte Suchfunktionen. Andererseits lässt sich dies durch einen Verzicht auf Normalformen umgehen, was zwar zu einer redundanten Datenhaltung führen kann, was aber leicht zu verkraften ist, da normalerweise keine Schreibzugriffe erfolgen.
Die objektorientierte Softwareentwicklung verspricht gegenüber bisherigen Ansätzen einen übersichtlicheren und somit leichter wartbaren Code. Ohne einen vorherigen Entwurf wird jedoch auch ein objektorientiertes Softwareprojekt scheitern -- je größer, desto eher. Als Sprache und de-facto-Standard für den objektorientierten Softwareentwurf hat sich seit der Mitte der neunziger Jahre die Unified Modeling Language (UML) etabliert.
UML bietet im Rahmen der Softwareentwicklung keine vollständige Entwicklungsmethode, sondern dient als Hilfsmittel für folgende Zwecke [17]:
UML arbeitet weitgehend mit grafischen Hilfsmitteln. Dazu kommen für verschiedene Phasen des Softwareentwurfs jeweils dafür geeignete Diagrammtypen zum Einsatz:
Basis eines jeden objektorientierten Softwareprogramms sind Klassen. Auch das Common Information Model (Kapitel 5) unterliegt einem Klassenmodell, so dass hier soweit auf Klassendiagramme eingegangen werden soll, wie sie in CIM zum Einsatz kommen.
Eine Klasse besitzt einen Namen, Attribute und Operationen, die auf sie angewandt werden können. In UML wird die Klasse wie in Abbildung 3.8 dargestellt.
Ein Rechteck symbolisiert dabei die Klasse, deren Name über einer Querlinie fett notiert ist. Ein Klassenname beginnt immer mit einem Großbuchstaben. Der zweite Teil des Rechtecks beinhaltet die Attribute der Klasse mit ihrem Datentyp, der dritte die Operationen. Bei diesen können auch Parameter und Rückgabewert mit angegeben werden.
Das Beispiel zeigt also die Klasse Bild, die über die beiden Attribute hoehe und breite (beides Fließkommazahlen) verfügen und die Methoden anzeigen, entfernen, getPosition und setPosition zur Verfügung stellen.
Ein wesentliches Konzept der objektorientierten Softwareentwicklung ist die Vererbung, bei der von einer bestehenden Klasse eine neue abgeleitet wird, die über verfeinerte Eigenschaften (Attribute und Operationen) verfügt. Dieses Konzept wird Spezialisierung genannt [23]. In UML wird die Beziehung zwischen der oberen und der abgeleiteten Klasse (bzw. zwischen Ober- und Unterklasse) durch einen Pfeil auf die Oberklasse dargestellt.
In diesem (Abbildung 3.9) und in den folgenden Beispielen wurde der Einfachheit zuliebe auf die Darstellung der Attribute und Operationen verzichtet. Von der Oberklasse Bild wurden hier die spezialisierten Klassen Gemälde, Foto und Lithografie abgeleitet. Foto ist selbst wiederum die Oberklasse für die Unterklassen Farbfoto und Schwarzweissfoto.
Assoziationen dienen dazu, Beziehungen zwischen beliebigen Klassen zu dokumentieren, rekursive Beziehungen innerhalb der gleichen Klasse sind auch möglich.
Abbildung 3.10 zeigt beispielhaft die Beziehung zwischen den Klassen Bild und Bilderrahmen, notiert in UML-Darstellung. In diesem Objektmodell (wie natürlich auch in der Realität) hat diese Beziehung selbst den Namen rahmung, welcher in UML grundsätzlich klein geschrieben wird. Eine Assoziation wird durch eine Verbindungslinie dargestellt.
Zu jeder Assoziation muss auch eine Kardinalität angegeben werden: Sie gibt an, in welchem Zahlenverhältnis die zwei Klassen einer Assoziation miteinander stehen. In diesem Beispiel kann sich ein Bild in einem Rahmen befinden, und in einem Rahmen kann ein Bild enthalten sein. Solch ein Wertebereich wird als 0..1 angegeben.
Eine Aggregation ist eine spezielle Ausprägung der Assoziation: Eine Assoziation wird als Aggregation bezeichnet, wenn das Verhältnis zwischen zwei Klassen darin besteht, dass eine Klasse Teil eines Ganzen ist -- wobei das Ganze die zweite Klasse ist.
Da ein PKW über drei bis vier Räder verfügt und die Räder ein Teil des
Gesamten ,,Kraftfahrzeug``sind, handelt es sich bei der Beziehung
zwischen Rad und Auto um eine Aggregation.
Aggregationen werden in UML als Linie mit einer offenen Raute auf der Seite des Ganzen dargestellt. Auch hier kann die Kardinalität angegeben werden.
