Die Instrumentierung einer Kaffeemaschine mit CIM/WBEMEnumerateInstances Mit dieser Methode können...

Die Instrumentierung einer Kaffeemaschine

mit CIM/WBEM

Kai Beckmann

06.02.2006

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 1

2.1 WBEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.2 CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 CIM-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 CIMOM Repository . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 CIM-Provider . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.3 CMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 sblim-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6 Die Kaffeemaschine . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Projekt 16

3.1 Beschreibung/Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Problemanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Design/Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 LDAP auf CIM abbilden . . . . . . . . . . . . . . . . . . . 20

3.3.2 Providerentwurf . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.1 Installation des sfcb . . . . . . . . . . . . . . . . . . . . . 29

3.4.2 sblim-Provider / Entwicklungsumgebung . . . . . . . . . . 30

3.4.3 Aufbau der sblim-Provider . . . . . . . . . . . . . . . . . . 33

3.4.4 Instrumentierung der Kaffeemaschine . . . . . . . . . . . 34

3.4.5 Untersuchung des sfcb . . . . . . . . . . . . . . . . . . . 38

1

4 Zusammenfassung 40

A Abbildungsverzeichnis 41

B LDAP-Schemata 42

C CIM 44

D Literaturverzeichnis 48

2

Zusammenfassung

Diese Ausarbeitung behandelt ein Verteilte-Systeme Projekt. Ziel dieses Pro-

jektes ist es eine Kaffeemaschine, die für die automatische Verwaltung und Ab-

rechnung des Kaffeeverbrauches modifiziert wurde, basierend auf der CIM/W-

BEM Management-Architektur mit einer Management-Schnittstelle auszustat-

ten.

Die Daten die zu Verwalten sind, werden zum Teil in einem LDAP-Verzeichnis

gespeichert. Basierend auf dem dort zu Grunde liegenden LDAP-Schema wird

das Kaffeemaschinen-System, bestehend aus den Benutzern und den Kaffee-

maschinen, auf CIM-Klassen abgebildet. Diese werden um weitere Attribute

für den aktuellen System-Zustand der Kaffeemaschine erweitert, die nicht im

LDAP-Verzeichnis gespeichert werden.

Für diese Klassen werden jeweils CIM-Provider implementiert, die die Instru-

mentierung durchführen. Diese Provider werden den CMPI-Standard unterstüt-

zen und sind somit in einer Reihe vom CIM-Servern einsetzbar.

Als CIM-Server wird der sfcb des sblim-Projektes eingesetzt. Dieser wird im

laufe des Projektes darauf untersucht werden inwieweit er für den Einsatz in

einer Embedded-Umgebung geeignet ist.

1 Einleitung

Mit der Zunahme der Komplexität der heutigen IT-Systeme wird es immer schwie-

riger diese Verwalten zu können. Es wird deswegen eine einheitliche Management-

Architektur benötigt, in der auch die Komponenten verschiedener Hersteller

einheitlich verwaltet werden können. Diese IT-Systeme besitzen in der Regel

ein unterlagertes Netzwerk, welche die Komponenten mit einander verbindet.

Man spricht in diesem Fall auch von einem Verteilten-System.

Ein weitverbreiteter Standard für das Management von Komponenten, die an

einem Netzwerk angebunden sind, ist das Simple Network Management Pro-

tocol (SNMP). Dieses ist aber sehr primitiv gehalten und hat neben einigen

Sicherheitslücken (jedenfalls die älteren weit verbreiteten Versionen) auch ein

Problem in großen Umgebungen richtig zu skalieren.

Ein noch ”relativ” neuer Standard, der für das Management von Verteilen-

System weitaus besser geeignet ist, ist der WBEM.

Auf dieser Basis soll eine Kaffeemaschine, die im Rahmen einer Embedded-

Systems Vertiefungs-Veranstaltung für die automatische Abrechnung und Ver-

waltung des Kaffeeverbrauchs modifiziert worden ist, eine Management-Lösung

erarbeitet werden.

2 Grundlagen

2.1 WBEM

Die heutige IT-Infrastruktur ist sehr komplex und weitestgehend heterogen. In

einer solchen ’Landschaft’ fällt das Management eines Gesamt-Sytems, das

aus verschiedenen Heterogenen Teilsystemen besteht, zunehmend schwer.

Um hier eine einheitliche Management-Architektur bereitzustellen, die sehr fle-

xibel und Herstellerunabhängig ist, wurde von der DMTF (Desktop Manage-

ment Task Force), einer Industrie-Organisation, WBEM (Web-Based Enter-

prise Management) entwickelt. WBEM stellt eine Reihe von Standards und

Technologien für das Management von verteilen IT-Systemen bereit. Um diese

1

große Flexibilität und Unabhängigkeit zu erreichen, setzt WBEM, wie so vie-

le aktuelle Entwicklungen, auf HTTP, XML und ein objektorientiertes Design.

[wikb] [dmt]

2.2 CIM

Das Common Information Model (CIM) ist der wichtigste Standard aus der

WBEM-Architektur. Es realisiert das Informationsmodell, welches die Eigen-

schaften der Komponenten eines Systems und ihre Beziehungen und Relatio-

nen untereinander beschreibt. CIM basiert auf einem objektorientierten Modell

für die formale Beschreibung des zu managenden Systems.

Für die Entwicklung und Darstellung der Klassen und ihren Beziehungen unter-

einander wird UML verwendet. Allgemein lassen sich alle wichtigen Konzepte

der Objektorientierung beim Design der CIM-Repräsentierung verwenden. Ins-

besondere Vererbung wird eingesetzt, um das Modell zu entwickeln und die

Struktur zu beschreiben.

CIM besteht aus einer Spezifikation und verschiedenen Schemata. Die Spe-

zifikation definiert die grundlegenden Sprachelemente sowie eine Namens-

konvention. Die für die Objektorientierung notwendigen Elemente werden im

Meta-Schema festgelegt. Als Basiselement dient die Klasse ’named Element’,

sie besitzt lediglich das Attribut ’Name’. Von dieser Klasse werden die anderen

Elemente wie ’Class’, ’Method’, ’Attribut’ und so weiter abgeleitet. Eine UML-

Darstellung dieses Schemas ist in Abbildung 1 gegeben. Wie daraus zu erse-

hen ist, sind die Assoziationen eigenständige Klassen.

Die weiteren Schemata bieten abstrakte Klassen, die der Modellierung der zu

managenden Systeme dienen. Die Schemata bauen aufeinander auf und wer-

den jeweils erweitert. Abbildung 2 zeigt, wie die verschiedenen Schemata auf

einander aufbauen.

Das Core-Schema stellt die Basis-Klassen, -Methoden und -Assoziationen für

die Entwicklung von Management-Klassen bereit. Es wird garantiert, dass die-

se Klassen nicht mehr verändert werden, was eine stabile und langfristige Ent-

wicklung ermöglicht. Ausgangspunkt für praktisch alle weiteren abgeleiteten

2

Abbildung 1: CIM Meta Schema (UML) [www.dmtf.org]

Klassen ist das CIM_ManagedElement. Diese Klasse enthält als Attribut ledig-

lich einen Namen für die jeweilige Instanz. Diese abstrakte Klasse wird von

CIM_ManagedSystemElement und weiteren Gruppen von Klassen abgeleitet.

Diese Gruppen beschäftigen sich mit dem managen von Softwareprodukten,

dem Verwalten von Einstellungen und der Konfiguration, sowie mit Klassen, die

als Basis für das Sammeln und Darstellen von statistischen Informationen die-

nen. Zusätzlich gibt es noch weitere Untergruppen, so dass eine ausreichend

breite Basis für die weitere Modellierung eines IT-Systems gelegt ist. Eine UML-

Darstellung dieser Gruppen und ihrer Ableitung von CIM_ManagedElement ist

in Abbildung 3 dargestellt.

Das Core-Schema stellt damit einen Grundstock bereit, der durch das darauf

aufbauende Common-Schema erweitert wird. Dieses definiert bereits gene-

rische Grundbestandteile eines IT-Systems mit den jeweiligen Eigenschaften.

Dennoch ist es sehr allgemein gehalten und kann so an reale Systeme ange-

passt werden. Beispielsweise gibt es die Klasse CIM_OperatingSystem, wel-

che die allgemeinen Merkmale eines Betriebssystems definiert. Diese Klasse

ist in Abbildung 4 dargestellt.

Das Common-Schema wird von der DMTF entwickelt und liegt zur Zeit der Ab-

fassung dieser Ausarbeit ung in Version 2.11 vor. Für einige Anwendungen wird

3

Abbildung 2: CIM Schemata Vererbungshierarchie

diese Funktionalität sicher bereits genügen und kann direkt verwendet werden.

Ist das nicht der Fall, können die Klassen modifiziert und an das zu managende

System angepasst werden; dann werden diese einem neuen Schema zugeord-

net, dem Extension-Schema . Da das Common-Schema sehr allgemein ge-

halten ist, ist dies in der Regel auch notwendig. Einige große IT-Hersteller und

Softwarehäuser haben dies bereits für ihre Produkte gemacht. So gibt es von

der Firma Sun für das Betriebssystem Solaris eine komplette WBEM Imple-

mentierung mit den dazugehörigen angepassten CIM-Schemata. Des weiteren

hat Microsoft für seine Betriebssysteme ab Windows 95 ein entsprechendes

Schema definiert [HGH99] und ab Windows 2000 ist eine modifizierte WBEM

Implementierung in alle Systeme eingebaut. Der Zugriff auf die Informationen

geschieht allerdings mit DCOM und nicht über HTTP/XML, wie es der WBEM-

Standard vorsieht. Das ganze hat einen eigenen Namen und heißt Windows

Management Instrumentation (WMI).

Das später noch genauer beschriebene sblim-Projekt entwickelt eine entspre-

4

Abbildung 3: CIM Core Model [www.dmtf.org]

5

Abbildung 4: UML Darstellung der CIM-Klasse CIM OperatingSystem

chende Management-Instrumentierung für Linux. Diese allerdings entspricht

dem WBEM Standard.

Beispiel für einige CIM-Klassen

Als Beispiel für die Modelierung eines IT-Systems soll nun eine einfaches

Beispiel gegeben werden, das die Merkmale und Möglichkeiten von CIM de-

monstriert.

Ein Drucker-Pool besteht aus Laser und Tintenstrahldrucker. Die Laserdrucker

sind von HP, die Tintenstrahldrucker von Canon. Dieses Beispiel ist nur sehr

primitiv gehalten um die grundsätzlichen Möglichkeiten aufzuzeigen. In Abbil-

dung 5 ist die UML-Darstellung dieses Beispiels dargestellt.

Managed Object Format

Neben UML gibt es eine weitere Möglichkeit CIM-Klassen zu beschreiben

und darzustellen. Dazu wird eine textuelle Darstellung verwendet, die für eine

elektronische Verarbeitung geeignet ist. Dieses Format heißt Managed Object

Format (MOF) und basiert auf einer IDL von Microsoft (Microsoft Interface

Definition Language (MIDL)) [www]. Unser Beispiel von oben sieht in dieser

6

Abbildung 5: CIM Klassen: Beispiel für CIM_Printer

Darstellungsform so aus:

[ Description("Der Canon_Printer ist eine Beispielklasse ...")

]

class Canon_Printer : CIM_Printer

{

[Description("Sorte der Tinte")

]

uint16 PhotoInk;

}

[Description("Der HP_Printer ist eine Beispielklasse")

]

class HP_Printer : CIM_Printer

{

[Description("Die HP interne Seriennummer")

]

uint32 HP_SerialNo;

}

7

[Association, Description("Die Assoziation die die Drucker in einem"

"Pool" zusammenfasst")

]

class printer_im_Pool

{

}

Zusammenfassung - CIM

Mit CIM lässt sich also das Informationsmodell eines IT-Systems beschrei-

ben. Es definiert die Typen und die Struktur der Informationen, die für das Ma-

nagement benötigt werden, sowie ihren Zusammenhang. Durch den offenen

von einigen standardisierten Klassen abgeleiteten Aufbau ist es möglich, die

Systeme verschiedener Hersteller damit abzubilden. Dabei kann entweder auf

mitgelieferte Schemata zurückgegriffen werden oder es ist möglich eigende

Schemata zu entwickeln. Eine Interoperabilität zwischen Lösungen verschie-

dener Hersteller ist damit gegeben.

CIM-XML

Als nächstes ist das Kommunikationsmodell zu betrachten. Dieses defi-

niert die Art wie, wann und welche Management-Informationen ausgetauscht

werden sowie die Syntax und Semantik der Protokoll-Datenstrukturen. [Hege-

ring, Buch] Es gibt dabei verschiedene Möglichkeiten, die Daten zu kommuni-

zieren. Microsoft benutzt bei seinem WMI DCOM, die DMTF stellt bei WBEM

dafür das Kommunikationsprotokoll CIM-XML bereit. Dieses bildet die CIM-

Daten und Operationen auf XML ab. Der Nachrichten-Austausch erfolgt dabei

über XML Nachrichten, die über HTTP bzw. HTTPS übertragen werden. Für

den Zugriff und die Manipulation der CIM-Klassen, Methoden und Instanzen

stehen verschiedene CIM-Operationen bereit. Im Folgenden werden die wich-

tigsten kurz mit ihrer Funktion dargestellt. [www]

GetClass Diese Funktion dient zum Abfragen einer einzelnen Klasse vom CI-

8

MOM.

GetInstance Diese Methode ermöglicht dem Klienten die Abfrage einer kon-

kreten Instanz einer CIM-Klasse.

DeleteInstance Löscht eine Instanz.

CreateInstance Erzeugt eine neue Instanz.

EnumerateClasses Gibt die Klassenbeschreibungen aller Klassen zurück.

EnumerateClassNames Gibt alle Klassennamen die bekannt zurück.

EnumerateInstances Mit dieser Methode können die kompletten Instanzen

abgerufen werden.

EnumerateInstanceNames Diese Methode gibt die Namen der Instanzen zu-

rück.

GetProperty Gibt den Wert eines Attributs zurück.

SetProperty Setzt den Wert eines Attributs.

2.3 CIM-Server

Der CIM-Server empfängt und verarbeitet die von außen kommenden CIM-

Operationen und gibt nach Durchführung der Operation das Ergebnis an den

aufrufenden Client zurück. Ein CIM-Server ist aus verschiedenen Schichten

aufgebaut, die im folgenden nach und nach genauer betrachtet werden sollen.

Als Basis soll Abbildung 6 dienen, diese zeigt den schematischen Aufbau ei-

nes CIM-Servers [Eck03]. Es wird nun ein Aufbau beschrieben, wie er von dem

Standard WBEM vorgesehen ist. Andere Implementierungen benutzen ggf. ab-

weichende Schichten und Schnittstellen.

Die ankommenden XML-Nachrichten werden über das HTTP-Protokoll über-

tragen und vom Server empfangen. Der Protokoll-Adapter decodiert daraus

die auszuführenden CIM-Operationen für die weitere Verarbeitung. Diese bei-

den Schichten werden bei Microsofts WMI durch DCOM ersetzt. Die CIM-

Operationen werden danach an den CIM Object Manager (CIMOM) weiter-

9

Abbildung 6: Aufbau eines CIM-Servers

gegeben. Dieser Verwaltet die CIM-Objekte und ihre Instanzen. Des Weiteren

werden die CIM-Operationen durch den CIMOM durchgeführt bzw. delegiert.

Es gibt verschiedene CIMOM Implementierungen, wobei für einige bereits die

Entwicklung wieder eingestellt wurde. Meist enthalten die jeweiligen WBEM-

Umgebungen einen CIMOM. Diese CIMOMs sind oft fest mit den CIM-Servern

verbunden und unterscheiden sich im Aufbau und den Funktionen voneinander.

Der CIMOM des openwbem-Projektes 1 ist in C++ geschrieben und eine voll-

ständige Implementierung des WBEM-Standards. Ein weiterer weit verbreiteter

1http://openwbem.sourceforge.net/

10

CIMOM ist der Pegasus 2 von The Open Group . Das sblim-Projekt hat eben-

falls einen CIMOM entwickelt, auf den später noch genauer eingegangen wird.

In der Literatur wird häufig die Bezeichnung eines CIM-Servers und eines CI-

MOM synunym verwendet. Im Folgenden wird die Bezeichnung wie durch das

OpenPegasus Projekt verwendet:

CIM-Server CIMON + Providerschnittstelle + HTTP-Server

2.3.1 CIMOM Repository

Die Speicherung der statischen Informationen wie etwa die Schemata der CIM-

Klassen oder statische Instanzen, werden im so genannten CIM Object Ma-

nager Repository durchgeführt. Es ist bei einigen CIMOM Implementierun-

gen auch möglich, dass dynamische Daten im Repository zwischengespei-

chert werden. Das ist aber die Ausnahme und eigentlich nicht vom WBEM-

Standard vorgesehen. Da das Repository statische Daten enthält, wird es bei

der Installation bzw. Konfiguration des CIM-Servers angelegt. Dazu werden

die MOF-Dateien, die die Definitionen und Schemata der eingesetzten CIM-

Klassen enthalten, durch einen MOF-Compiler in ein für den CIMON lesbares

Format umgewandelt. Es ist auch möglich, statische Instanzen von Klassen

in diesen MOF-Daten zu definieren und mit den dazugehörigen Attributwerten

auszustatten.

2.3.2 CIM-Provider

Der Zugriff auf die dynamischen Daten der CIM-Instanzen erfolgt aber nicht

über den eigentlichen CIMOM oder dessen Repository. Die CIM-Operationen,

die nicht mit den Informationen im Repository ausgeführt werden können, wer-

den durch den CIMOM an spezielle Provider weitergeleitet. Diese haben direk-

ten Zugriff auf die Ressourcen der zu managenden Systeme und können dort

die notwendigen Informationen extrahieren oder durch CIM-Operationen aus-

gelöste Modifikationen durchführen. Es ist in der Regel so, dass eine Instanz

2http://www.openpegasus.org/

11

von einem sich in Ausführung befindlichen Provider dargestellt wird, oder ein

Provider eine vielzahl von Instanzen verwaltet. Da die Provider meist dyna-

misch ladbare Bibliotheken, also Plugins, für die CIM-Server sind, werden bei

der Erzeugung oder Zugriff auf eine Instanz der zu ladende Provider, aus den

Daten des Repository’s ermittelt, und dynamisch in den Arbeitsspeicher gela-

den. Dieser führt dann die CIM-Operation aus, und übermittelt dem CIMOM

das Ergebnis. CIM-Operationen erfolgen immer auf den Attributen und mit den

Methoden der jeweiligen CIM-Klasse. Die Daten, die diese Elemente repräsen-

tieren, liegen in irgendeiner Form im System, auf das der Provider Zugriff hat,

vor. Oft sind diese Informationen aber nicht in der Weise aufbereitet, wie die

Klasse das vorsieht. Der Provider holt nun aus dem System die notwendigen

Informationen und bereitet sie so auf, dass sie den Datentypen der CIM-Klasse

entsprechen.

Die Schnittstelle zwischen Provider und dem CIMOM ist von WBEM nicht defi-

niert worden. Das hat am Anfang der Entwicklung von WBEM-Implementierun-

gen dazu geführt, dass jeder CIMOM seine eigene Schnittstelle besaß. So-

mit mussten für jeden CIMOM eigene Provider geschrieben werden, was die

Interoperabilität zwischen den verschiedenen CIMOM-Herstellern unmöglich

machte. Es war nicht möglich, einen Provider, der für einen CIMOM geschrie-

ben wurde, bei Umstellung auf einen anderen CIMOM wiederzuverwenden.

Wenn nun verschiedene CIMOMs eingesetzt werden sollten, musste für jeden

CIMOM der Provider neu implementiert werden. Aus diesem Grund wurde von

The Open Group 3 eine Provider-Schnittstelle definiert.

2.3.3 CMPI

Das Common Manageability Programming Interface (CMPI) ist ein C-Inter-

face für CIM-Provider. Provider und CIMOMs, die dieses unterstützen, sind be-

liebig untereinander austauschbar, auch als fertig kompilierte Objekt-Dateien.

Die Schnittstelle zwischen Provider und CIMOM sind einige vorgegebene C-

Funktionen, wobei der Zugriff auf diese durch den CIMOM, mit Hilfe einer

Funktionstabelle, in der die Funktionszeiger der Funkionen festgelegt sind, ge-

3http://www.opengroup.org/

12

schieht. Damit ist der Funktionsaufruf auch möglich, ohne dass Provider und

CIMOM gegeneinander gelinkt werden. Die ganze Provider-Entwicklung wird

durch die Bereitstellung von Datentypen und Hilfsfunktionen unterstützt. Die

CIM-Datentypen werden durch entsprechende Strukturen abgebildet, für das

Ausführen von CIM-Operationen stehen entsprechende Funktionsaufrufe be-

reit. Dadurch reduziert sich die Arbeit auf die Instrumentierung des zu mana-

genden Systems und die Übergabe der gewonnen Informationen an die ent-

sprechenden Funktionen.

Eine weitere Eigenschaft, die allerdings noch nicht von allen CIMOMs unter-

stützt wird, ist das so genannte Remote-CMPI . Damit soll es ermöglicht wer-

den, dass ein CMPI-Provider, um Informationen zu beziehen, selber wieder

andere Provider aufruft. Dadurch wird eine bessere Skalierung erreicht, und

es ist möglich, den CIM-Server auf einigen Maschinen klein zu halten, um so

den Ressourcen-Verbrauch zu begrenzen [Sch05].

2.4 sblim-Projekt

Das sblim-Projekt ist eine Open-Source Implementierung von WBEM für Li-

nux. Entwickelt wird dieses Projekt durch IBM und Intel und soll in noch nicht

näher spezifizierten Produkten dieser Firmen eingesetzt werden 4. Ziel ist es

Linux eine einheitliche Management-Architektur zu geben und es in eine ent-

sprechend ausgestattete IT-Landschaft zu integrieren. Dafür wurden, neben

verschiedener Teile des WBEM Standards, auch eine Reihe von weiteren prak-

tischen Tools entwickelt. Als Grundlage wurde ein CIM-Schema für ein gene-

risches Linux-System entworfen, welches für die meisten Linux-Systeme ein-

gesetzt werden kann. In der Regel ist dafür keine weitere Anpassung mehr

notwendig. Neben einem CIM-Schema für Linux werden auch eine Reihe von

Providern angeboten, die die notwendige Instrumentierung durchführen, um

die durch das Schema vorgegebene Funktionalität zu ermöglichen. Diese Pro-

vider sind nach dem CMPI-Standard entwickelt worden, was ihren Einsatz mit

beliebigen Providern, die dies unterstützen, ermöglicht. Das wichtigste Provi-

derpaket ist das sblim-cmpi-base, dieses stellt neben den Basis-Informationen

4http://sblim.sourceforge.net/

13

eines Linux-Systems auch eine Reihe von Hilfsfunktionen bereit, die für die

eigene Provider-Entwicklung eingesetzt werden können / sollten. Da CMPI-

Provider immer gleich aufgebaut sind und ein Großteil generisch ist, gibt es

von dem sblim-Projekt einen Generator für Provider-Skelette. Damit verringert

sich der Implementierungsaufwand für die CMPI abhängigen Teile. Daneben

wird noch eine Testsuite für automatische Tests und ein CIM-Client-Interface

angeboten.

Ein weiterer Teil des sblim-Projekt widmet sich der Entwicklung eines CIM-

Servers. Der Small Footprint CIM Broker (sfcb) wird nach den Gesichtspunk-

ten eines möglichst geringen Ressourcen-Verbrauchs entwickelt. Damit soll er

auch für den Einsatz in Embedded-Linux-Systemen geeignet sein.

Der sfcb ist komplett in C geschrieben und somit relativ portabel. Als Schnitt-

stelle zu den Providern wird CMPI verwendet, wobei auch Remote-CMPI Auf-

rufe unterstützt werden. Das Hauptaugenmerk bei der Entwicklung liegt neben

einem geringen Ressourcen-Verbrauch auch auf der Stabilität des Servers.

Der Main-Prozess ist sehr simpel gehalten und sollte immer stabil laufen. Um

die Komplexität gering zu halten, wurde die WBEM-Spezifikation für CIMOMs

nicht komplett implementiert. So ist es z.B. nicht möglich, neue CIM-Klassen

dynamisch im Betrieb hinzuzufügen, zu verändern oder zu löschen. Dies muss

extern geschehen und der sfcb danach neu gestartet werden. [Sch05]

2.5 LDAP

Bei dem Lightweight Directory Access Protocol (LDAP) handelt es sich um

ein Protokoll für den Zugriff auf einen Verzeichnisdienst. Als Grundlage diente

der vollständig spezifizierte, aber niemals vollständig implementierte Verzeich-

nisdienst X.500 [wika], der für die meisten Anwendungen allerdings zu komplex

ist. Deswegen wurde LDAP als leichtgewichtige Untermenge von X.500 konzi-

piert. Die aktuelle Version 3 von LDAP ist mit der RFC3377 spezifiziert. Aller-

dings wird, wie der Name schon sagt, nur ein Protokoll für den Zugriff definiert.

Wie die Daten in dem jeweiligen Server vorgehalten werden, ist applikations-

abhängig.

14

Ein Verzeichnisdienst ist ein Dienst, der Informationen speichert und Cli-

ents diese zur Verfügung stellt. Damit ist er vergleichbar mit einer normalen

Datenbank, allerdings gibt es einige Besonderheiten. Die Daten sind streng

hierarchisch strukturiert. Zu jedem Eintrag existiert ein weltweit eindeutiger

Pfad, womit auf das jeweilige Attribut zugegriffen werden kann. Verzeichnis-

Dienste stellen hauptsächlich Informationen bereit, das bedeutet, dass primär

lesende Operationen durchgeführt werden. Deswegen sind diese Operationen

auch optimiert. Schreibende Zugriffe hingegen sind seltener und auf Grund

der Optimierungen auf der Lesenden Seite auch nicht sehr performant. Eine

Möglichkeit, die unterstützt wird, um sowohl die Verfügbarkeit, als auch den le-

senden Zugriff zu beschleunigen, ist Replikate der Verzeichnisse zu erzeugen

und im Netzwerk bereitzustellen.

Die Struktur der Informationen, auf die mit LDAP zugegriffen werden soll, wer-

den durch Schemata definiert. Ein Schema beschreibt einen Unterbaum des

Verzeichnisses und enthält verschiedene Objekt-Klassen , welche wiederum

Attribute oder weitere Objekte enthalten. Die Attribute können keinen, einen

oder mehrere Einträge/Werte enthalten. Auf die Objekt-Klassen wird mit Hilfe

eines eindeutigen Namens, dem Distinguished Name (DN), zugegriffen. Der

DN besteht aus dem Objektnamen und einer Basis, die den Pfad von der Wur-

zel des hierarchischen Baumes zu dem Objekt beschreibt. Der DN ist in der

Regel so aufgebaut, dass er weltweit eindeutig ist, in dem in den Pfad die URL

der Webseite der Benutzer/der Instutition eingebaut wird.

2.6 Die Kaffeemaschine

Im Rahmen einer Embedded-Systeme Vertiefung wurde ein Kaffeevollautomat

mit einem RFID-Reader und einem Webserver ausgestattet. Dadurch wird die

automatische Verwaltung und Abrechnung des Kaffeeverbrauchs ermöglicht.

Dazu werden die Kaffeetassen mit RFID-Tags versehen, die bei der Entnah-

me von Kaffee durch die Kaffeemaschine ausgelesen werden. In einer LDAP-

Benutzerverwaltung wird dann der Verbrauch dem entsprechenden Benutzer

zugeordnet und gespeichert. Dardurch können die Benutzer verschiedene Kaf-

feemaschinen dieser Art in einem System benutzen und der Kaffeeverbrauch

15

einheitlich in ihrem Benutzeraccount gespeichert werden. Neben den Benut-

zerdaten werden in dem LDAP-Verzeichnis auch die Einstellungen und Kon-

figurationsparameter der Kaffeemaschine gespeichert. Dardurch können die

eingesetzten Kaffeemaschinen zentral verwaltet werden. Neben dem LDAP-

Zugang besitzt jede Kaffeemaschine eine eigene Webschnittstelle, auf dem

sich Benutzer und Administrator einloggen und Informationen über den eige-

nen Account oder den Status der jeweiligen Kaffeemaschine abrufen können.

Alternativ zu der Speicherung der Daten in dem LDAP-Verzeichnisdienst kön-

nen die Daten auch lokal in der Kaffeemaschine vorgehalten werden, sollte

eine entsprechende Infrastruktur nicht vorhanden sein.

3 Projekt

3.1 Beschreibung/Aufgabe

Aufgabe des Projektes ist es, das Kaffeemaschinen-Projekt (Kaffeemaschine

mit LDAP-Anbindung) um eine Management-Instrumentierung, basierend auf

WBEM/CIM, zu erweitern. Dafür soll das bisher verwendete LDAP-Schema

auf ein CIM-Schema abgebildet und gegebenenfalls erweitert werden. Danach

sollen für dieses Schema Provider entwickelt werden, die die CMPI Schnitt-

stelle unterstützen und die Instrumentierung der Kaffeemaschine durchführen.

Als CIM-Server soll der sfcb des sblim-Projektes benutzt werden. Des weite-

ren soll seine Tauglichkeit hinsichtlich Ressourcenverbrauch für den Einsatz in

einer Embedded-Umgebung untersucht werden.

3.2 Problemanalyse

Bei diesem Projekt sind zu Anfang verschiedene und teils recht unterschied-

liche Bereiche zu untersuchen. Der WBEM Standard hat sich bisher in eini-

gen Bereichen durchgesetzt, wenn auch manchmal, in abgewandelter Form.

Dennoch ist bei einigen in diesem Bereich angesiedelten Projekten noch eine

große Dynamik festzustellen. So wurde zum Beispiel die Entwicklung eines der

ältesten Projekte, der SNIA CIMOM, inzwischen eingestellt. Andere Projekte,

16

wie das zu verwendende sblim-Projekt unterliegen einem schnellen Version-

wechsel mit häufigen Fehlerbehebungen und neuen Features.

Es ist davon auszugehen, dass diese Software noch nicht vollkommen ausge-

reift ist, und bei ihrer Verwendung vielfältige Probleme auftauchen werden.

Da bei dem eingesetzten sfcb die Daten als XML-Nachrichten kodiert und über

HTTP übertragen werden, ist genauer zu untersuchen, inwieweit diese Eigen-

schaften für den Embedded-Bereich Probleme aufwerfen können. Die Extration

der Daten aus den XML-Nachrichten durch entsprechende Parser und die Um-

wandlung der Datentypen benötigen sowohl zusätzlichen Speicher, als auch

Rechenleistung. Je nach eingesetzter Hardware und Umgebung kann dies zu

einem Engpass führen.

Das Common Information Model wurde für die Abbildung und Abstrahierung

von Computer- und Netzwerk-Geräten und -Eigenschaften entwickelt. Dieses

wurde sehr generisch gehalten, so dass eine einfache Anpassung an möglichst

jede Gegebenheit in diesem Bereich möglich ist. Es wird sich nun im Laufe des

Projektes die Frage stellen, wie man eine Kaffeemaschine und deren Verwal-

tungsdaten, die durch den Konsum von Kaffee entstehen, durch CIM darstellen

kann.

Die Kaffeemaschine enthält zum einen Eigenschaften und Komponenten, die

der IT-Welt entstammen. Diese in ein CIM-Schema zu gießen, wird sicherlich

keine Probleme bereiten. Gegebenenfalls wird es sogar möglich sein, für ein-

zelne Bereiche vordefinierte Lösungen zu verwenden. Das auf der Maschine

laufende Linux-System ist sicherlich ein Kandidat, für den eine solche Lösung

in Frage kommt. Anders sieht es sowohl für die Kaffeemaschine als Ganzes,

wie auch für die spezifische Verwaltung der Kaffeeverbrauchsdaten aus.

Die Aufgabenstellung sieht vor, dass das vorhandene LDAP-Schema benutzt

werden soll, um ein CIM-Schema zu erstellen. Es ist also notwendig, LDAP-

Schemata auf CIM-Schemata abzubilden. Da diese beiden Systeme relativ

häufig gemeinsam verwendet werden ist dies ein häufig anzutreffendes Pro-

blem.

Bei der Instrumentierung eines IT-Systems durch CIM/WBEM wird in der Doku-

mentation / Literatur [WBEM White Paper] häufig die Verwendung von LDAP für

17

die Speicherung von Informationen vorgeschlagen. Da LDAP primär für den le-

senden Zugriff ausgelegt ist, sollten dies allerdings nur Informationen sein, die

sich nicht oder nur sehr selten ändern. LDAP ist nicht für Zustandsdaten geeig-

net. Für die Abbildung von CIM-Klassen und Schemata, wo dies Sinn macht,

gibt es daher vordefinierte und ausgearbeitete LDAP-Schemata. Es werden

beginnend bei dem Core-Schema für jede CIM-Klasse LDAP-Klassen definiert

und entsprechend strukturiert. Dieser Weg von CIM zu LDAP ist gut dokumen-

tiert und bereitet keine Mühe.

Eine andere Sache ist der umgekehrte Weg. Dieser wird in der Literatur nicht

beschrieben. Es ist also notwendig dies selbst zu erarbeiten. Die Beschrei-

bungen der CIM auf LDAP-Abbildungen kann dafür als eine Basis verwendet

werden.

Ein weiteres Problem wird sich wieder daraus ergeben, dass CIM für IT-Systeme

entworfen wurde. Es wird ggf. notwendig sein, die Teile, die sich nicht einfach

konvertieren lassen, von Grund neu aufzubauen,

Nach der Aufgabenstellung soll der CIM-Server auf einem externen PC laufen

und die Provider ihre Daten über das Netzwerk beziehen. Die Daten sind aller-

dings nicht an einem zentralen Ort gespeichert, sondern im System verteilt. Ein

Teil der Daten befindet sich in einem zentralen LDAP-Verzeichnis, der andere

Teil jeweils auf den Kaffeemaschinen selber. Auch ist die Verteilung inhaltlich

nicht zusammenhängend. So werden die Konfiguration sowohl im LDAP als

auch in der Maschine gespeichert. Auf der Maschine selber sind die Informa-

tionen auch wieder über das ganze Interne System verteilt. Je nach Ort und

Art werden die Daten unterschiedlich zugegriffen werden müssen.

In dem LDAP-Verzeichnis werden alle Benutzerdaten sowie die Konfigurations-

Parameter gespeichert, die nicht essentiell sind, um auf das Netzwerk und LD-

AP zuzugreifen . Für den Zugriff auf dieses Verzeichnis durch die Provider wird

eine C-API verwendet werden müssen, da die Provider selber auch in C imple-

mentiert werden. Da die in Frage kommende openldap 5 C-API sehr komplex

und nicht einfach zu benutzten ist, wird eine entsprechende Funktions-Schicht

dies kapseln müssen. Dies wurde schon für das Kaffeemaschinen Projekt ge-

5http://www.openldap.org/

18

macht, das heißt, es existiert von dort eine Grundlage, die verwendet wer-

den kann. Da dies allerdings für den Einsatz auf der Maschine, also in einem

Embedded-System, entwickelt wurde, sind dort sicherlich Einschränkungen zu

erwarten.

Bei den Daten, die auf der Kaffeemaschine selber gespeichert werden, gibt

es zwei Unterscheidungen. Zum einem die Einstellungen, die das laufende

Linux-System betreffen. Diese liegen an verschiedenen Stellen und ein einfa-

cher Zugriff wird nicht möglich sein. Der einfachste Weg wird sein, bestehende

Provider für diesen Zweck zu portieren und auf der Maschine laufen zu lassen.

Da dies seitens der Aufgabenstellung nicht vorgesehen ist, wird ein Manage-

ment dieses Teils nicht möglich sein.

Der andere Teil der interessanten Informationen über die Kaffeemaschine be-

trifft die Zustands und Fehler-Informationen. Diese werden durch einen Dienst,

der auf der Maschine läuft, ermittelt und in einer Datei im Dateisystem gespei-

chert und aktualisiert. Auf diese Datei greifen die anderen Dienste und Pro-

zesse zu, die die Informationen benötigen. Der zu entwickelnde Provider wird

also ebenfalls einen wie auch immer gearteten Zugriff auf diese Status-Datei

benötigen. Eine der Daten Verteilung über das Netzwerk wird benötigt werden.

Der einzusetzende CIM-Server sfcb soll für seine Eignung eines eventuellen

Einsatzes auf der Kaffeemaschine selber untersucht werden. Wie die meis-

ten Embedded-Systeme ist auch das der Kaffeemaschine nicht mit übermä-

ßig vielen Ressourcen und Rechenleitung ausgestattet. Das macht es notwen-

dig möglichst nur sehr leichtgewichtige Programme und Dienste darauf lau-

fen zu lassen. Dahingegend wird der sfcb zu untersuchen sein. Insbesondere

der Overhead, der durch den XML-Nachrichtenaustausch entsteht, steht einer

großen Effizienz entgegen.

Ein weiteres oft aufkommendes und dennoch unterschätztes Problem ist die

Fähigkeit der einfachen Portierung auf andere Hardware-Architekturen. Der

sfcb wurde ursprünglich für die x86-Architektur entwickelt. Für den Einsatz auf

der Kaffeemaschine ist es notwendig, dass er auf einem ARM-System läuft.

19

3.3 Design/Entwurf

Im Folgenden soll das Konzept für die Realisierung der Aufgabenstellung vor-

gestellt werden. Als erstes wird die Abbildung und Erweiterung der beste-

henden LDAP-Klassen auf CIM dargestellt, danach wird auf dieser Basis der

Aufbau der Provider dargestellt. Zum Schluss wird der CIM-Server des sblim-

Projektes auf seine Tauglichkeit für den Einsatz in einer Embedded-Umgebung

untersucht. Es wird beabsichtigt, CIM zu nutzen, um die Kaffeemaschinen und

ihre Benutzer in bestehende gemanagte IT-Systeme zu integrieren. Sofern die-

se Systeme ebenfalls durch CIM modelliert werden und WBEM unterstützen,

sieht die Philosophie von WBEM/CIM vor, dass dies ohne großen Aufwand

möglich ist.

3.3.1 LDAP auf CIM abbilden

Die Daten der Kaffeemaschine und ihrer Benutzer werden durch zwei Sche-

mata dargestellt. Das Schema für die Beschreibung der Benutzergruppe ist

von der Klasse inetOrgPerson6 abgeleitet und wird mit den Attributen Tasse-

nID, Zapferlaubnis, Strichliste und Detailvorgang erweitert. Im Anhang ist das

vollständige Schema des Kaffeetrinkers als Listing 1 dargestellt. Das zweite

Schema beschreibt die Kaffeemaschine. Dieses ist direkt von der Oberklasse

top abgeleitet und erbt somit keine Attribute. Dieses Schema ist als Listing 2

im Anhang ebenfalls dargestellt.

Die Gruppe Kaffeetrinker

Um von CIM auf LDAP Klassen abzubilden, gibt es in [Woo00] fertig definier-

te LDAP-Klassen. Dabei wird die CIM-Klasse CIM_Person auf inetOrgPerson

abgebildet. Es bietet sich also an, für das Schema Kaffeetrinker andersherum

vorzugehen. CIM_Person ist eine abstrakte Klasse des Common-Schemas, die

nun entsprechend für unsere Bedürfnisse abgeleitet werden kann. Die abgelei-

tete CIM-Klasse wird entsprechend FHW_Kaffeetrinker benannt. Als nächstes

sind die zusätzlichen Attribute der Gruppe Kaffeetrinker zu untersuchen. Bei

6Definiert in der RFC 2798

20

Strichliste und Zapferlaubnis ergeben sich keine Probleme, sie werden einfach

als zusätzliche Attribute in FHW_Kaffeetrinker hinzugefügt.

Anders sieht es bei TassenID und Detailvorgang aus. TassenID speichert die

TassenIDs die einem Benutzer zugeordnet werden. Dies können allerdings

mehrere sein, was unter LDAP kein Problem ist, da dort in einem Attribut meh-

rere Werte gespeichert werden können. Das selbe gilt für die Detailvorgänge,

in diesen Werten werden die Daten, die eine durch die Entnahme von Kaffee

aus der Maschine entstehen, gespeichert. Für jeden Vorgang gibt es einen

eigenden Eintrag, ebenfalls als eine Menge von Werten in einem Attribut.

Mit CIM gibt es nun zwei Möglichkeiten dies darzustellen. Zum einem kön-

nen die Wertemengen aus der FHW_Kaffeemaschine ausgelagert und durch

eine eigene Klasse dargestellt werden. Die jeweiligen Instanzen repräsentie-

ren dabei dann die entsprechende TassenID bzw. den Detailvorgang. Durch

eine Komposition werden dann die Verbindungen wieder hergestellt. Im LDAP-

Schema werden die Detailvorgänge als ein Test-String gespeichert, in dem

weitere verschiedene Informationen kodiert sind. Bei Verwendung einer eigen-

den Klasse ist es nur möglich diese Informationen wieder zu dekodieren und

in eigenen Attributen zu speichern. In Abbildung 7 ist diese Klasse als UML-

Diagramm dargestellt.

Da die Assoziationen im CIM durch eigene Klassen dargestellt werden, ist der

Aufwand für eine Realisierung dieser Lösung durch Provider recht komplex.

Diese Daten sind sehr eng an den jeweiligen Benutzer gekoppelt und ein Zugriff

auf einzelne Instanzen dieser Art sind schwierig zu adressieren. Entsprechend

ist eine Lösung, die diese Werte in der Klasse FHW_Kaffeetrinker belässt,

vorzuziehen.

CIM unterstützt Arrays von alle CIM-Datentypen als Attribute. Damit ist es mög-

lich die Daten in der Klasse FHW_Kaffeetrinker zu belassen. Allerdings wird es

nicht möglich sein, für die Detailvorgänge die einzelnen Komponenten aufzu-

spalten. Diese werden wie im LDAP-Schema als ein zusammenhängeder Text-

String gespeichert werden müssen. Für die spätere Implementierung der Pro-

vider ist diese Lösung besser, da zum einem weniger Provider benötigt werden

(eine Klasse wird durch einen eigenen Provider dargestellt) und zum anderen

21

Abbildung 7: CIM-Klasse: FHW_Kaffeetrinker Version 1

die Zuordnung der Daten zu den Benutzern einfacher und mit weniger Auf-

wand möglich ist. In Abbildung 8 ist die veränderte Klasse FHW_Kaffeetrinker

als UML-Diagramm dargestellt. Da alle Daten aus der Benutzer- und Kaffee-

verbrauchsverwaltung durch das angegebenen LDAP-Schema dargestellt wer-

den, ist dieser Teil mit der Abbildung auf CIM abgeschlossen.

Die Kaffeemaschine

Das nächste LDAP-Schema, das auf CIM abgebildet werden soll ist das der

Kaffeemaschine. Dieses Schema enthält die folgenden Attribute mit ihrer Be-

deutung:

MaschinenID Die eindeutige Identifikationsnummer der Kaffeemaschine.

detaillierteDatenSpeicherung Boolischer Wert, der angibt, ob für jeden Zapf-

vorgang ein detalierter, das heißt mit Datum, Zeit, Menge usw., Datensatz

oder nur das Ereignis selber gespeichert werden soll.

Kaffeepreis Der für die Kaffeemaschine veranschlagte Kaffeepreis pro Tasse

in e-Cent.

22

Abbildung 8: CIM-Klasse: FHW_Kaffeetrinker Version 2

Abrechnungsperiode Die Periode die ein Abrechnungszeitraum in Tagen um-

fast.

Abrechnungsdatum Das Datum wann die nächste Abrechnung durchgeführt

wird.

Timeserver Der Zeit-Server von dem die Kaffeemaschine die aktuelle Zeit be-

zieht.

Smtpserver Der Mail-Server über den die Kaffeemaschine Mails mit Rech-

nungen, Meldungen usw. verschickt.

Diese Attribute lassen sich in zwei Gruppen aufteilen. Zum einem sind Time-

server und Smtpserver eher dem unterliegenden Linux-System zuzuordnen

und die anderen Attribute sehr spezifisch für die Kaffeemaschine. Eine Zu-

sammenfassung dieser verschiedenen Gruppen in einem Schema ist von der

inhaltlischen Trennung eher ungünstig gelöst. Für das neu zu erstellende CIM-

Schema ist es deswegen angebracht diese Teile von einander zu trennen und

in eigenen Schemata abzulegen. Somit bleiben für die CIM-Klasse, die die Kaf-

feemaschine repräsentieren soll vorerst die Attributte: MaschinenID, detaillier-

teDatenSpeicherung, Kaffeepreis, Abrechnungsperiode und Abrechnungsda-

tum. Dies repräsentiert allerdings nur die Daten, die durch das LDAP-Schema

definiert sind. Daneben gibt es weitere Informationen, die die Kaffeemaschine

repräsentieren aber in der Maschine selber vorgehalten werden.

23

Die Informationen, die den aktuellen Zusand der Kaffeemaschine darstellen,

werden auf der Machine gehalten. Da diese Daten sich schnell ändern können

und nicht langfristig stabil sind, sind sie nicht in dem Verzeichnisdienst gespei-

chert und somit auch nicht im LDAP-Schema dargestellt. Eine CIM-Klasse die

eine Kaffeemaschine repräsentiert sollte allerdings auch diese Daten enthal-

ten. Somit ist es notwendig, das bisherige Schema zu erweitern. Im folgenden

sind die Status auf der Kaffeemaschine dargestellt:

treser_voll Der Treserbehälter ist voll und muss entleert werden.

maschine_an Die Kaffeemaschine ist angeschaltet und betriebsbereit (Boo-

lean).

aufheizen Die Kaffeemaschine heizt sich auf Betriebstemperatur auf (Boo-

lean).

wasser_leer Der Wasserbehälter enthält nicht mehr genügend Wasser (Boo-

lean).

reinigen Entweder die Maschine muss gereinigt werden oder der Reinigungs-

vorgang läuft gerade (String).

entkalken Entweder die Machine muss entkalkt werden oder der Prozess läuft

gerade (String).

tassenID_imFeld Ein Integer der die ID der Tasse angibt, die sich zur Zeit in

der Maschine befindet (Integer).

Diese Status werden als weitere Attribute dem CIM-Schema Kaffeemaschine

hinzugefügt. Danach ist die Frage zu klären wo sich das Kaffeemaschinen-

Schema unter den bestehenden CIM-Schemata einordnen soll. Das LDAP-

Schema hat direkt von der Oberklasse top geerbt. Dies wäre auch mit CIM

möglich. Die entsprechende Klasse wäre dann CIM_ManagedElement. Die

bisherige Abstraktion sah allerdings ein System von Kaffeemaschinen vor, das

ggf. auch in bestehende, durch CIM modellierte IT-Systeme, integriert werden

soll. Deswegen ist es ratsam eine Struktur zu wählen die dies unterstützt. Wenn

die Kaffeemaschinen und ihre Benutzer als eigenständiges System betrach-

tet werden, ist die einzelne Maschine ein Teil des Systems. Daher wurde die

24

Abbildung 9: CIM-Klassen: Darstellung des KaffeemaschineSystems

Klasse CIM_System nach FHW_KaffeemaschineSystem abgeleitet, um diesen

Aufbau zu repräsentieren. Die Kaffeemaschine erbt als FHW_Kaffeemaschine

von CIM_SystemComponent und ist damit durch eine entsprechende Kompo-

sition Teil des gesamten Kaffeemaschinen-Systems. Da die Benutzer der Grup-

pe Kaffeetrinker ebenfalls Teil dieses Systems sind werden sie auf dem selben

Wege mit dem System verbunden. Das Kaffeemaschinen-Schema FHW_Kaffee-

maschine ist in Abbildung 9 zusammen mit dem Gesamt-System, also Kaffee-

maschine und Kaffeetrinker, dargestellt.

Das Linux-System

Aus dem LDAP-Schema FHWKaffeetrinker wurden die Attribute Timerserver

und Smtpserver noch nicht in eigenen CIM-Klassen abgebildet. Wie bereits an-

gedeutet sind dies Eigenschaften, die eher einem allgemeinen Linux-System

zuzuordnen sind. Das unterlagerte Linux, auf das die Kaffeemaschinen rele-

vanten Prozesse laufen, bietet ebenfalls vielfälltige Möglichkeiten des Manage-

ment. Allerdings trifft dies generisch auf alle Linux-Systeme zu. So ist es nicht

verwunderlich, dass es bereits fertige CIM-Lösungen für die Instrumentierung

25

Abbildung 10: CIM-Klassee: FHW_Kaffeemaschine_conf

von Linux gibt. Um das Rad nicht neu erfinden zu müssen, kann auf diesen

Lösungen aufgesetzt werden. Aufbauend auf das sblim-Projekt kann die dort

definierte Klasse Linux_ComputerSystem an die Gegebenheiten der Kaffee-

maschine angepasst werden. Eine mögliche Erweiterung ist in Abbildung 10

aufgezeigt. Dieses ist aber nur eine unvollständige und vor allem unbefriedi-

gende Lösung. Allerdings würde eine richtige Anpassung den Rahmen des

Projektes sprengen, so dass dies nur angedeutet werden kann.

Das gesamte System mit allen CIM-Klassen ist im Anhang in Abbildung 11

gegeben. Ebenso befindet sich im Anhang als Listing 3 die MOF-Darstellung.

3.3.2 Providerentwurf

Die CIM-Klassen stellen die Repräsentierung des Systems der Kaffeemaschi-

nen dar. Sie sind lediglich ein abstraktes Modell. Diese Provider stellen den

plattformabhängigen Ressourcen Zugriff bereit und stellen damit die jeweiligen

realen Instanzen des Systems dar. Bei der Abbildung der CIM-Klassen auf die

Provider wird so verfahren, dass eine Klasse von genau einem Provider darge-

stellt wird [toc04].

Die zu entwickelnden Provider werden als Schnittstelle für die CIMOMs den

Standard CMPI unterstützen. Damit wird es möglich sein, dass diese durch

eine Vielzahl von CIM-Servern unterstützt werden. Der grundsätzliche Aufbau

der Provider ist damit vorgegeben.

Das bisherige Design sieht 3 normale CIM-Klassen und 2 Assoziationsklassen

26

vor. Es müssen 5 Provider entwickelt werden.

Die Assoziationsprovider stellen die Verbindung zwischen zwei Klassen

dar. Dazu benötigen sie Informationen über die Klassen auf die sie Referenzen

besitzen. Bei Anfragen werden diese angesprochen und deren Informationen

in eine Antwort verpackt. Diese Funktionalität ist sehr beschränkt und für alle

möglichen Assoziationen immer gleich. Aus diesem Grund gibt es dafür auch

eine generische Lösung, die auf alle Assoziations-Provider angewandt werden

kann. Diese generische Lösung wird durch das sblim-Projekt zur Verfügung

gestellt und auch hier verwandt.

Der Kaffeemaschinen-Provider benötigt Zugang zu den Informationen der

realen Kaffeemaschine die er repräsentiert. Diese Informationen liegen an zwei

verschiedenen Stellen. Zum einem in einem zentralen LDAP-Verzeichnisdienst

und zu anderen auf der lokalen Kaffeemaschine selbst. Der plattformabhän-

gige Teil des Providers wird auf beide Quellen einen Zugang benötigen. Auf

die Daten in LDAP-Verzeichnis kann direkt durch den Provider mit Hilfe ent-

sprechender Hilfsfunktionen zugegriffen werden. Damit kann dieser Teil des

Providers auch ausserhalb der Kaffeemachinen, zentral auf einem Rechner für

alle Machinen im System laufen.

Ein Problem ist der Abruf der Statusinformationen. Diese liegen ausschliesslich

lokal auf den Kaffeemaschinen. Diese Ressourcen sind somit nur lokal zugäng-

lich. Ein Zugang kann duch einen lokal auf der Machine laufenden CIM-Server

mit entsprechenden Provider ermöglicht werden. Der Zugang zu dem LDAP-

Verzeichnis ist auch von dort ohne weiteres möglich. Da die Kaffeemaschine

allerdings nur über begrenzte Ressourcen verfügt, sollte die auf ihr laufende

Funktionalität beschrängt sein. Es bietet sich daher an nur den unbedingt not-

wendigen Teil dort zur Ausführung zu bringen.

Die Verwendung vom Remote-CMPI [präsentation sfcb] wäre dafür eine Lö-

sung. Ein kleiner CIM-Server in dem nur der Provider für die Statusinformatio-

nen läuft wird auf der Kaffeemaschine installiert. Einem ausserhalb der Kaffee-

maschine laufenden Provider wird somit ein Zugriff ermöglicht. Dies ist zwar

27

die optimale Lösung, aber auf Grund der Einschränkungen der Aufgabenstel-

lung nicht möglich. Dieses oder eine ähnliches Verfahren soll in einem späte-

ren Projekt durchgeführt werden. Dieses Projekt benötigt daher lediglich einen

provisorischen Zugang.

Da die Zustands-Daten der Kaffeemaschine komplett in einer einzgen lokalen

Datei vorgehalten werden, ist es lediglich notwendig diese Datei im Netzwerk

zur Verfügung zu stellen. Dies kann durch einen einfachen UDP-Server realie-

siert werden, der auf Anfrage den Inhalt der Zustands-Datei an den Provider

überträgt. Damit hat der Kaffeemaschinen-Provider nun Zugriff auf alle notwen-

digen Ressourcen um eine CIM-Instanz einer Kaffeemaschine zu repräsentie-

ren.

Der Kaffeetrinker-Provider ist sehr viel einfacher aufgebaut. Er benötigt le-

diglich Informationen, die durch das LDAP-Verzeichnis bereitgestellt werden.

Da die Benutzer der Kaffeemaschinen in gesamten System nur einmal vor-

kommen ist es sinnvoll diesen Provider nur in einem CIM-Server zu installieren.

Somit ist sichergestellt das eine Instanz eines Benutzers auch nur einmal im

gesamten System vorkommt.

Der KaffeemaschinenSystem-Provider ist überflüssig. Es wird immer nur

eine Instanz dieses Providers in einem System geben. Auch die Informationen

die durch ihn bereitgestellt werden sind zu einem eher wenig und zum anderen

werden sie sich nie ändern. Somit ist ein eigener Provider überflüssig und es

ist effizienter diesen durch eine statische Instanz im CIMOM Repository darzu-

stellen.

3.4 Implementierung

Für die Implementierung des im vorherigen Abschnitttes aufgezeigten Konzep-

tes für die Instrumentierung der Kaffeemaschine mit LDAP-Anbindung sind ver-

schiedene Schritte notwendig. Zunächst muss der zu verwendene CIM-Server,

der sfcb, installiert und eingerichtet werden. Danach werden einige vorge-

bene Provider aus dem sblim-Projekt eingerichtet, um die Funktionalität des

28

sfcb zu testen und zu demostrieren. Das sblim-Projekt stellt eine Anzahl an

Hilfsmitteln und Bibliotheken, für die Entwicklung eigener Provider zu Verfü-

gung. Diese werden ebenfalls installiert und später genutzt. Die Haupaufgabe

wird in der Implementierung der beiden Provider für die beiden CIM-Klassen

FHW_Kaffeemaschine und FHW_Kaffeetrinker liegen. Als Abschluss wird ei-

ne Untersuchng über die Verwertbarkeit des sfcb in Embedded-Anwendungen

durchgeführt.

3.4.1 Installation des sfcb

Obwohl das sfcb-Projekt von IBM und Intel für den produktiven Einsatz entwi-

ckelt wird, ist die Software dieses Projektes teilweise sehr unausgereift. Insbe-

sondere die Dokumentation lässt an einigen Stellen sehr zu wünschen übrig.

Fast die gesamte Dokumentation für den sfcb befindet sich in einer README-

Datei, die mit dem Quell-Code mitgeliefert wird. Allerdings ist diese an einigen

Stellen verwaltet und noch nicht aktuallisiert worden.

Der Quell-Code für den sfcb kann von der Webseite des sblim-Projektes7 her-

untergeladen werden. Das benötigte Paket heißt: sblim-sfcb. Neben einem

”Tarball” gibt es auch die Möglichkeit eine aktuelle Entwicklerversion über CVS

zu beziehen. Diese ist allerdings meist sehr unstabil.

Es ist darauf zu achten, dass die folgenden Abhängigkeiten bestehen, die für

eine erfolgreiche Erzeugung des CIM-Servers notwendig sind.automake >= 1.8

autoconf >= 2.5.8

libtool >= 1.5.8

bison >= 1.85

curl >= 7.11.1-1

curl-devel >= 7.11.1-1

für SSL Support:

openssl > 0.9.7

openssl-devel > 0.9.7

Die Erzeugung erfolgt dann durch den Aufruf von ./configure, mit dem Pa-

rameter --prefix=<Verzeichnispfad> kann der Pfad, in dem der sfcb später

installiert wird, angepasst werden. make und make install erzeugen dann den

sfcb und die notwendigen Bibilioteken und installieren alles im System. Der

7http://sblim.sourceforge.net/

29

Aufruf von make postinstall lädt von der Webseite der DMTF die aktuellen

CIM-Schemata herunter und installiert diese.

Ein Cross-Compile des sfcb sollte in den meisten Fällen möglich sein. Für

das Kaffeemaschinen-Projekt ist eine Embedded-ARM-Umgebung notwendig.

Um schnell und zuverlässig für diese Architektur Programme erzeugen zu kön-

nen, ist das scratchbox-Projekt 8 zu empfehlen. Die scratchbox emuliert mit

Hilfe von QEMU9 das komplette Traget-System. Somit wird die Portierung der

Software sehr erleichtert, da auf dem Target selber entwickelt und kompiliert

werden kann. Für die Installation und Einrichtung dieses Systems wird auf die

Dokumentation dieses Projektes verwiesen. Es ist auch schon für die Entwick-

lung der Kaffeemaschine eingesetzt worden. Ist die scratchbox eingerichtet,

verläuft die Erzeugung und Installation des sfcb analog zu der bisher beschrie-

benen.

3.4.2 Installation von Providern / Provider-Entwicklungsumgebung

Das sblim-Projekt liefert alles, was für die Entwicklung von eigenden Providern

notwendig ist. Daneben sind auch eine Vielzahl an fertigen Providern für ein

Linux-System vorhanden. Die folgenden Bereiche sind bereits durch das sblim-

Projekt abgedeckt:

• Dateisystem-Verwaltung

• Netzwerk

• nfs

• perl

• rpm Paketmanagement

• samba

• sysfs

• syslog8http://www.scratchbox.org/9http://fabrice.bellard.free.fr/qemu/

30

Das sblim-dev Paket stellt die Header bereit, die benötigt werden um die

Provider zu kompilieren. Somit wird dieses Paket sowohl für die eingene Provider-

Entwicklung benötigt, als auch um fertige Provider-Pakete zu kompilieren, so-

fern sie nicht als fertige Module ausgeliefert werden. Des Weiteren bietet die-

ses Paket C++ Wrapper-Klassen an. Damit ist es möglich Provider in C++ zu

entwickeln.

Der Name dieses Paketes beginnt mit sblim-cmpi-devel, gefolgt von der Versi-

onsnummer. Dieses kann von der sblim-Projekt Seite bezogen werden. Nach

dem entpacken wird das ./configure Script aufgeführt. Mit

--prefix=<Verzeichnispfad> ist ggf. der Verzeichnispfad an das jeweilige

System anzupassen. make und make install erledigen dann den Rest. Wird

kein individueller Pfad angegeben, werden die Header in /usr/include/cmpi oder

/usr/local/include/cmpi kopiert.

Das sblim-base Providerpaket stellt Provider für eine Basis-Instrumentierung

von Linux bereit. Es werden die Klassen: Linux_ComputerSystem, Linux_Base-

Board, Linux_OperatingSystem, Linux_UnixProcess und Linux_Processor so-

wie weitere Assoziations-Klassen abgedeckt. Das Configure-Script der Version

1.5.4 enthält einen Fehler, den man manuell beheben muss, bevor eine Instal-

lation möglich ist. Für die Kompilierung der Provider werden die Header aus

dem sblim-dev Paket benötigt. Die Pfade, in denen das Script sucht, sind aller-

dings fest eingetragen, und so werden die Header nie gefunden. Am einfachs-

ten findet man die richtige Stelle, wenn man nach dem String ”tog-pegasus”

sucht. Dort wird dann der Pfad wo die Header installiert wurden manuell ein-

geragen. Danach ist ein ./configure, make und make install möglich. Mit

make postinstall können die fertigen Provider gleich in den jeweiligen CI-

MON registriert und die MOF-Dateien kompiliert und im CIM-Repository abge-

legt werden.

Der Provider-Skelettgenerator psg ist eines der Tools für die Provider--

Entwicklung, die das sblim-Projekt zur Verfügung stellt. Dieses Script generiert

Provider-Skelette, welche dann mit der jeweiligen Funktionalität ausgestattet

werden können. Es gibt 3 Arten von Skeletten die generiert werden können.

31

Zu einem für das veraltete Native Provider Interface (NPI), dieses sollte aller-

dings nicht mehr benutzt werden. Besser ist das CMPI, welches bereits in den

Grundlagen beschrieben wurde. Für diese Schnittstelle gibt es zwei Arten von

Aufbau für die Provider. Zu einem, wo alles notwendige in einem File enthal-

ten ist. Diese Möglichkeit ist die einfachste, allerdings ist sie nicht allzu gut zu

warten und zu modifizieren. Die andere Möglichkeit ist die vom sblim-Projekt

empfohlene. Hierbei wird die Implementierung des Providers in eine Reihe von

Dateien aufgespalten. Diese Unterteilung richtet sich nach der Schicht, der die

jeweilige Funktionalität zugeordnet ist. Diese wird im nächsten Abschnitt ge-

nauer vorgestellt.

Die Erzeugung der Provider geschieht wie folgt:

./createCmpiOSBaseProvider.sh <className> <libraryName> [inst|-]

[assoc|-] [method|-] [event|-]|

className Der Name der CIM-Klasse, die durch den Provider implementiert

werden soll.

libraryName Der Name für die Bibiliothek meist ähnlich dem Klassennamen.

inst Wenn angegeben wird ein Instanz-Provider erzeugt.

assoc Wenn angegeben wird eine Assoziations-Provider erzeugt.

method Wenn angeben wird der Provider mit Funktionen für die Behandlung

vom Methoden-Aufrufen ausgestattet.

event Wenn angegeben wird der Provider für die Behandlung von asynchro-

nen Events ausgestattet.

Bei dem mitgelieferten Makefile ist unbedingt darauf zu achten, das dieses

bei dem Aufruf von make clean auch die generierten Dateien gelöscht wer-

den! Dieses sollte als erstes angepasst werden, sonst sind schnell die bisher

gemachten Arbeiten gelöscht.

32

3.4.3 Aufbau der sblim-Provider

Um die Entwicklung der CIM-Provider zu vereinfachen und die Wiederver-

wendung von Code zu verbessern wird, seitens des sblim-Projekts eine Drei-

Schichten-Architektur für Provider befürwortet. In dieser Architektur wird die

Funktionalität der Provider aufgeteilt, so dass CMPI, CIM und Ressourcen-

Zugriff getrennt sind. Eine weitere optionale Möglichkeit ist es Funktionen, die

von mehreren Providern benutzt werden in entsprechende Bibliotheken zu pa-

cken.

Für diese Teilung gibt es auch bestimmte Namenskonventionen. Siehe auch

[Neu03].

cmpiOSBase_<Klassen Name>Provider.c Die CMPI abhängige Provider--

Schnittstelle. Hier sind die CMPI-Funktionen enthalten, die durch den

Provider aufgerufen werden.

cmpiOSBase_<Klassen Name>.c / .h Der CIM abhängige Teil des Providers.

OSBase_<Klassen Name>.c / .h Der Teil der den Zugriff auf die Resourcen

durchführt.

Der CMPI-abhängige Teil der Provider bieten die vom CMPI-Standard vor-

gegebenen Funktionen. Diese sollen un im folgenden kurz mit ihrer Funktion

beschrieben werden.

OSBase_<Klassen Name>ProviderCleanup() Bei Aufruf dieser Funktion soll

der Provider ”aufgeräumt” werden, also Speicher wieder freigegeben usw.

OSBase_<Klassen Name>ProviderEnumInstanceNames() Diese Funktion

gibt eine ”Aufzählung” ”Namen” der Instanzen die dieser Provider reprä-

sentiert. Diese ”Namen” werden Object Path gennant und mit ihnen kann

die Instanz identifiziert und angesprochen werden.

OSBase_<Klassen Name>ProviderEnumInstances() Diese Funktion zählt die

Instanzen die der Provider repräesentiert auf. Dies enthält auch alle ak-

tuellen Werte der Attribute.

33

OSBase_<Klassen Name>ProviderGetInstance() Die Funktion gibt die ak-

tuellen Daten einer Instanz zurück. Um Sie zu identifizieren wird ihr der

”Object Path” der Instanz übergeben.

OSBase_<Klassen Name>ProviderCreateInstance() Diese Funktion erzeugt

eine neue Instanz.

OSBase_<Klassen Name>ProviderModifyInstance() Diese Funktion ersetzt

eine Instanz.

OSBase_<Klassen Name>ProviderDeleteInstance() Diese Funktion vernich-

tet eine Instanz.

OSBasw_<Klassen Name>ProviderExecQuery() Diese Funktion macht ein

”Query”.

OSBase_<Klassen Name>ProviderInvokeMethod() Diese Funktion ruft ei-

ne Methode der von dem Provider repräsentieten Klasse auf.

Weiterhin von Interesse sind die Funktionen die für die Behandlung von Asso-

ziationen benötigt werden. Da diese Behandlung bei den Provider des sblim-

Projekt allerdings generisch gelöst ist, wird sie nicht mehr im besonderen Be-

trachtet. Diese Funktionen finden die verbundenen Instanzen und liefern ent-

weder eine Liste der Namen, der beteiligten Instanzen oder alle Instanzen mit-

samt ihrer aktuellen Werte.

3.4.4 Instrumentierung der Kaffeemaschine

Für die Kaffeemaschine müssen zwei Provider entwickelt werden, diese sind

den beiden entworfen CIM-Klassen zugeordnet. Jeder Provider implementiert

eine Klasse. Die Provider werden im ersten Schritt mit dem Provider Skelett-

Generator des sblim-Projekts erzeugt. Dabei wird das vom sblim-Projekt emp-

fohlene Schema, mit der Aufteilung der Funktionalität in drei Scichten benutzt.

Die Provider werden auch CMPI unterstützen und somit in einer vielzahl an

CIM-Servern laufen können. Für die Entwicklung wird der sfcb benutzt.

34

Für den Zugriff auf das LDAP-Verzeichniss werden die LDAP-Wrapper Funk-

tionen aus dem Kaffeemaschinen-Projekt als Basis genommen, und an die Be-

lange der CIM-Provider angepasst. Da zuerst nur ein lesender Zugeriff auf das

LDAP-Verzeichnis erfolgt, können alle Funktionen, die Daten erzeugen oder

modifizieren außer Acht gelassen werden. Da diese Wrapper-Funktionen ei-

ne vielzahl an Konfigurations-Dateinen benötigen, die in einer vorgegebenen

Verzeichnisstruktur liegen müssen, ist es notwendig diese Umgebung auch auf

dem Entwicklungsrechner aufzubauen.

Der Kaffeetrinker-Provider ist der erste Provider, der implementiert wird.

Wie sich im Konzept gezeigt hat, ist der Zugriff auf die dynamischen Daten

relativ einfach. Alles was benötigt wird liegt im LDAP-Verzeichniss und kann

von dort bezogen werden.

Bei der Entwicklung wurde der CIM_UnixProcess-Provider des sblim-Projekts

als Vorbild genommen. Nach diesem Beispiel werden nur die CMPI-Funktionen

EnumInstanceNames() , EnumInstances() und GetInstance() implementiert.

Da keine Informationen über einen Zeitraum zwischen mehrern Abfragen vor-

gehalten werden, ist die Funktionen Cleanup() nicht notwendig. Es können

auch keine Instanzen erzeugt oder vernichtet werden, da die Kaffeetrinker re-

präsentiert werden, und so vorgegeben ist welche Instanzen es gibt. Also jeder

Benutzer wird durch eine Instanz dargestellt.

Für den CIM-Abhängigen Teil gibt es zwei Funktionen die _makePath() und die

_makeInst(). Diese erzeugen die CIM-Antworten für die CMPI-Abhängigen

Funktionen. Die _makePath() Funktion erzeugt den bereits genannten ”Object

Path” einer Instanz. Zum anderen die _makeInst() Funktion, diese erzeugt die

CIM-Darstellung einer Instanz mit ihren aktuellen Werten.

Für den Ressourcen-Zugriff müssen drei Funktionen implementiert werden:

enum_all_Kaffeetrinker_ID(), get_Kaffeetrinker_detail() und

enum_all_Kaffeetrinker_detail().

Als erstes muss durch die Funktion enum_all_Kaffeetrinker_ID() eine Lis-

te der Namen von den Benutzern im System erzeugt werden. Diese wird zum

einem für die EnumInstanceNames()-Funktion benötigt, und zum anderen als

35

Basis um auf die Werte der Instanzen zuzugreifen. Diese Liste wird durch eine

LDAP-Wrapper-Funktion aus dem LDAP-Verzeichniss erstellt. Für jeden Na-

men einer Instanz wird durch die _makePath() Funktion ein ”Object Path” er-

zeugt.

Mit der get_Kaffeetrinker_detail() wird eine Struktur mit den aktuellen

Werten des jeweiligen, als Parameter angegebenen Benutzers erzeugt. Diese

Funktion wird dann von zwei CMPI-Funktionen verwendet. Die CMPI-Funktion

GetInstance() übergibt die erzeugte Struktur der CIM-Funktion _makeInst(),

die daraus eine CIM-Darstellung der Instanz erzeugt. Diese wird an den CI-

MOM, für den aufrufenden Client zurückgegeben.

Für die CMPI-Funktion EnumInstances() wird durch die Funktion

enum_all_Kaffeetrinker_detail() eine verkettete Liste mit den Strukturen,

die die Funktion get_Kaffeetrinker_detail() erzeugt, erstellt. Für jeden Struk-

tur wird in einer Schleife die CIM-Funktion _makeInst() aufgerufen.

Damit ist die gesammte Funktionalität des Kaffeetrinker-Provider erreicht. Da

ledigtlich Lesender-Zugriff notwendig ist, sind keine weiteren CMPI-Funktionen

zu implementieren.

Der Kaffeemaschinene-Provider wird grundsätzlich ähnlich implementiert

wie der Kaffeetirnker-Provider. Der einzige wirkliche Unterschied besteht im

Zugriff auf die Ressourcen. So werden die selben CMPI-Funktionen imple-

mentiert bzw. nicht implementiert. Auch die CIM-Funktionen _makePath() und

_makeInst() sind quasi identisch, natürlich entsprechen die erzeugten CIM-

Strukturen der CIM-Klasse FHW_Kaffeemaschine.

Die Funktionen für den Ressourcen-Zugriff sind von der Anwendung und der

übergebenen Parameter ähnlich denen des Kaffeetrinker. Allderdings tritt ier

das Problem mit den verteilten Daten auf. Ein Teil der Daten liegen im LDAP-

Verzeichniss, auf diese wird wieder mit den modifizierten LDAP-Wrapper Funk-

tionen des Kaffeemaschinen-Projektes zugegriffen. Für die Gennerierung einer

Liste der Kaffeemaschinen im System mit der Funktion

enum_all_Kaffeemaschine_ID() wird wieder eine LDAP-Wrapper Funktion be-

nutzt.

36

Um eine Struktur mit den aktellen Werte einer Kaffemaschine zu erstellen wird

analog zu den Kaffeetrinkern die Funktion get_Kaffeemaschine_detail() be-

nutzt. Diese ist dann allerdings in zwei Teile unterteilt. Zum einem der LDAP-

Teil, welcher keine Probleme beinhaltet. Für die Zustandsdaten die auf der

jeweiligen Kaffeemaschine selber gehalten werden, wird eine eigende proviso-

rische Schnittstelle aufgebaut.

Der Kaffeemaschinen-Zustands-Server ist die Schnittstelle zwischen den

Zustands-Informationen auf der Kaffeemaschine und dem Kaffeemaschinen-

Provider. Die aktuellen Zustände werden auf der Kaffeemaschine von einem

Daemon ermittelt und in einer Datei im Dateisystem aktualliesiert.

Der Zustands-Server ist ein einfacher UDP-Server, der als Standard auf Port

4223 läuft. Wenn ein Client den Befehl: get_zustand schickt wird die Zustands-

datei ausgelesen und der String mit den kodierten Zuständen an den Client zu-

rückgeliefert. Der Client, in unserem Fall die get_Kaffeemaschine_detail()

Funktion des Kaffeemaschinen-Providers, dekodiert daraus die Zustände der

Kaffeemaschine und befüllt entsprechend das Struct, das zurückgegeben wird.

Die Assoziations-Provider sind durch das sblim-Projekt generisch gelöst

worden. Da die Aufgabe eines Assoziazions-Provider darin besteht die beiden

Komponenten die miteinander in Beziehung stehen zuverbinden. Dabei ist es

unerheblich Was die Klassen genau repräsesentieren. Somit ist es möglich

diese Aufgabe generisch für alle Assoziationen zu lösen.

Die Verwendung dieser generischen Lösung wurde am Beispiel des Provders

für die CIM-Klasse Linux_OSProcess des sblim-Projektes untersucht. Nach

diesem Beispiel wurde dann der laufendeKaffeemaschinen-Provider implemen-

tiert.

Seitens des sblim-Projekts werden die Funktionen _assoc_create_inst_1toN(),

_assoc_get_inst() und _assoc_create_refs_1toN() bereitgestellt. Die erste

Funktion wird in den CMPI-Funktionen für die Behandlung der Instanz-Operationen

benutzt. Die zweite für die CMPI-Funktion getInstance().

37

Die _assoc_create_refs_1toN() Funktion deckt alle notwendigen Operatio-

nen für die Behandung der Assoziations-Operationen ab. Die Steuerung wel-

che Funktionalität nun angewand werden soll, wird über Parameter gesteu-

ert. Da diese Funktionen seitens des sblim-Projektes vorgegeben sind, wird

für die genaue Beschreibung auf die entsprechende Dokumentation verwiesen

[Neu03].

3.4.5 Untersuchung des sfcb auf seine Verwendbarkeit in Embedded-

Anwendungen

Wie bereits aufgeführt, soll der sfcb in späteren Projekten in Embedded-Um-

gebungen eingesetzt werden. Daher ist nun zu untersuchen, inwieweit er dafür

geeignet ist.

Bei der Arbeit mit dem sfcb hat sich schnell gezeigt, dass dieser zur Zeit noch

nicht für den produktiven Einsatz geeignet ist. Allgemein ist das ganze noch et-

was instabil, so produziert zum Beispiel eine Komponente des sfcb, der ”Class

Provider” immer dann einen Speicherzugriffsfehler, wenn versucht wird mit ei-

nem grafischen CIM-Browser auf die Klassen und Instanzen des sfcb zuzugrei-

fen.

Als erstes wird untersucht ob der sfcb überhaupt für eine andere Hardwa-

re kompiliert werden kann. Da die spätere Zielplattform wahrscheinlich die

der Kaffeemaschine sein wird, wird sich bei der Untersuchung auf diese be-

schränkt. Wie bei der Entwicklung der Kaffeemaschine wird hierfür das scratch-

box -Projekt eingesezt. Neben dem vereinfachten Kompilierungsvorgang ist es

auch möglich die erzeugten Programme direkt in einem Emulator auszuführen.

In dieser Umgebung ist es möglich den CIM-Server und die Provider genau wie

im HOST-System zu erzeugen. Allerdings bestehen einige Abhängigkeiten, die

manuell aufgelöst werden müssen. Im untersuchen Fall waren das die Pakete

curl und zlib.

Mit den unter einem x86-System und ARM-System erzeugten Objekt-Dateien

können nun auf ihren Speicherverbrauch auf dem Festspeicher untersucht wer-

den. Dafür werden der sfcb und seine von ihm benötigeten Bibiliotheken ”ge-

stript”, also alle nicht notwendigen Symbole aus den Objekt-Dateinen entfernt.

38

In der folgenden Tabelle werden auch die Werte für die nicht ”gestripen” Datei-

en angegeben.

x86 ARM

sfcb 28 KiB 83 KiB

sfcb (strip) 14 KiB 12 KiB

libs 8,5 MiB 5,3 MIB

libs (strip) 1,4 MiB 1,4 MiB

gesamt 11 MiB 9,5 MiB

gesamt (strip) 5,1 MiB 5,5 MiB

Es zeigt sich, dass sich die Werte zwischen ARM und x86 wenig unterschei-

den. Der sfcb alleine ist sehr kompakt, und auch die Größe der benötigten Bibi-

liotheken hält sich in Grenzen. Vieleicht ist es möglich die Bibiliothken die nicht

unbedingt benötigt werden zu ermitteln und zu entfernen. Allgemein kann man

sagen, dass die 1,4MiB für ein ”größers” Embedded-System akzeptabel sind.

In diesem Teil-Bereich ist der sfcb also für den Einsatz in der Kaffeemaschine

geeignet.

Neben dem Speicherbedarf auf dem Festspeicher ist auch der Ressourcenver-

brauch im Arbeitsspeicher interessant. Bei dieser Untersuchung ist allerdings

die scratchbox nicht zu gebrauchen. Da hier jeder Prozess in einem eigendem

Emulator auf dem Host-System läuft, ist der eigendliche Speicherverbrauch

des CIM-Servers nicht zu ermitteln. So muss von dem x86-System auf das

ARM-System geschlossen werden.

Leerlauf 5700 KiB

Enumerate Instances 6320 KiB

Hier wird die Bewertung schon etwas problematisch. Da auf einem Embedded-

System auch noch andere Prozesse laufen, die ebenfalls Speicher benötigen

ist hier schnell eine Grenze erreicht. Hier ist bei jedem System genau zu unter-

suchen, ob dies zu verkraften ist. Möglicherweise gibt es da auch noch weitere

Optimierungen.

Sofern das Embedded-System genügend Arbeitsspeicher vorhanden ist, oder

39

eine Lösung für eine Reduzierung des Verbrauchs durch den sfcb gefunden

wird, ist der sfcb in Zukunft für den Einsatz in der Kaffeemaschine geeignet.

4 Zusammenfassung

Dieses Projekt hat zum einem einen guten Einblick in das Management von

Verteilten-Systemen mit CIM/WBEM gegeben und zum anderen wurde das

Kaffeemaschinen-Projekt um eine Management-Schnittstelle für eben diese

Standards ausgestattet. Nun ist eine Überwachung der Kaffeemaschinen und

ihrer Benutzer möglich. Als nächster Schritt kann nun eine Teil der Funktiona-

lität auf die Maschine selber portiert werden. In der Untersuchung des sfcb

hat sich gezeigt, dass dieser für eine Einsatz in einer solcher Embedded-

Umgebung geeignet ist.

Im Laufe des Projektes haben sich eine vielzahl an Problemen offenbart. Zum

einem ist das verwendete sblim-Projekt noch nicht in einem Stadium, das man

als stabil und ausgereift, nennen kann. Insbesondere die dürftige Dokumenta-

tion, liegt an vielen Punkten hinter den aktuellen Entwicklung zurück. Daher ist

es an einigen Stellen sehr problematisch, die Umgebung aufzusetzen und in

dieser die Provider zu implementieren.

Die Entwicklung der Provider ist auch eine Sache für sich. Seitens des sblim-

Projekt gibt es eine Art ”Howto” für die Entwicklung von Provider. Dieses ist

allerdings sehr kurz gehalten und vermittelt fast keine Hintergründe. So ist die

Entwicklung von Providern mit den mitgelieferten Tools zwar relativ einfach,

aber bis zu dieser Erkenntnis und dem nötigen Wissen, ist es ein sehr langer

Weg.

Ausgelöst durch diese Schwierigkeiten war der Zeitaufwand zur Lösung der

Aufgabenstellung relativ hoch. Allerding wurden auch interessante Einblicke

in das Management von verteilen Embedded-Systemen gegeben. Dies wird

sicherlich ein Bereich sein, dem in Zukunft besondere Bedeutung zukommen

wird.

40

A Abbildungsverzeichnis

Abbildungsverzeichnis

1 CIM Meta Schema (UML) [www.dmtf.org] . . . . . . . . . . . . . 3

2 CIM Schemata Vererbungshierarchie . . . . . . . . . . . . . . . . 4

3 CIM Core Model [www.dmtf.org] . . . . . . . . . . . . . . . . . . 5

4 UML Darstellung der CIM-Klasse CIM OperatingSystem . . . . . 6

5 CIM Klassen: Beispiel für CIM_Printer . . . . . . . . . . . . . . . 7

6 Aufbau eines CIM-Servers . . . . . . . . . . . . . . . . . . . . . . 10

7 CIM-Klasse: FHW_Kaffeetrinker Version 1 . . . . . . . . . . . . . 22

8 CIM-Klasse: FHW_Kaffeetrinker Version 2 . . . . . . . . . . . . . 23

9 CIM-Klassen: Darstellung des KaffeemaschineSystems . . . . . 25

10 CIM-Klassee: FHW_Kaffeemaschine_conf . . . . . . . . . . . . . 26

11 CIM-Klassen: Alle CIM-Schema für die Instrumentierung der Kaffeemaschine 44

41

B LDAP-Schemata

Quellcode 1: LDAP Kaffeetrinker-Schema

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 1 NAME ’ TassenID ’

DESC ’ In tege r Tag e ine r Kaffeetasse ’

EQUALITY integerMatch

SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .27

)

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 2 NAME ’ Zapfer laubn is ’

DESC ’ d ieser User da r f Kaffee zapfen ’

EQUALITY booleanMatch

SYNTAX 1 .3 .6 . 1 .4 .1 . 146 6 .1 15 . 121 .1 . 7

SINGLE−VALUE )

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 5 NAME ’ S t r i c h l i s t e ’

DESC ’ S t r i c h l i s t e des gezapften Kaffees ’


SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .27

SINGLE−VALUE )

a t t r i b u t e t y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 7 NAME ’ Deta i lvorgang ’

DESC ’ S t r i n g mi t Daten eines Zapfvorgangs ’

EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstr ingsMatch

SYNTAX 1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .15 {1024 } )

ob jec t c l ass ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 0 . 1 NAME ’ FHWKaffeetr inker ’

DESC ’ gener ic i n f o rma t i on f o r a l l fb member ( students , s t a f f , . . . ) ’

SUP inetOrgPerson

MUST ( Zapfe r laubn is )

MAY ( S t r i c h l i s t e $ Deta i lvorgang $ TassenID ) )

)

42

Quellcode 2: LDAP Kaffeemaschine-Schema

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 3 NAME ’ MaschinenID ’

DESC ’Nummer e ine r Kaffeemaschine ’


SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .27

SINGLE−VALUE )

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 4 NAME ’ Kaf feepre is ’

DESC ’Nummer e ine r Kaffeemaschine ’


SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .27

)

a t t r i b u t e T y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 6 NAME ’ Abrechnungsperiode ’

DESC ’ In tege r ü f r Dauer e ine r Abrechnungsperiode ’


SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .27

SINGLE−VALUE )

a t t r i b u t e t y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 8 NAME ’ Timeserver ’

DESC ’FQDN des Time−Servers der Kaffeemaschine ’



SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .15 {256 } )

a t t r i b u t e t y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 1 . 9 NAME ’ Smtpserver ’

DESC ’FQDN des SMTP−Servers der Kaffeemaschine ’



SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .15 {256 } )

a t t r i b u t e t y p e ( 1 . 3 . 6 . 1 . 4 . 1 . 14 66 0 .6 .1 1 . 10 NAME ’ Abrechnungsdatum ’

DESC ’Datum der Abrechnung im ISO 8601 format ’


SYNTAX 1 .3 .6 .1 .4 .1 .1466 .115 .121 .1 .15 {10 }

SINGLE−VALUE )

a t t r i b u t e T y p e ( 1 .3 .6 .1 .4 .1 .1 4 66 0 . 6 . 11 .1 1 NAME ’ de ta i l l i e r t eDa tenSpe iche rung ’

DESC ’ werden Daten d e t a i l l i e r t gespe icher t ? ’

EQUALITY booleanMatch

SYNTAX 1 .3 .6 . 1 .4 .1 . 146 6 .1 15 . 121 .1 . 7

SINGLE−VALUE )

ob jec t c l ass ( 1 . 3 . 6 . 1 . 4 . 1 . 1 4 6 6 0 . 6 . 1 0 . 2 NAME ’ Kaffeemaschine ’

DESC ’ In fo rmat ionen und E ins te l l ungen e ine r Kaffeemaschine ’

SUP top

MUST ( MaschinenID )

MAY ( Ka f feepre is $ S t r i c h l i s t e $ Abrechnungsperiode $ Deta i lvorgang $ Timeserver

$ Smtpserver $Abrechnungsdatum $ de ta i l l i e r t eDa tenSpe i che rung ) )

43

Abbildung 11: CIM-Klassen: Alle CIM-Schema für die Instrumentierung der

Kaffeemaschine

C CIM

Quellcode 3: MOF-Darstellung aller CIM-Kaffeemaschine-Schemata

#pragma l o c a l e ( " en_US " )

[ Prov ider ( " cmpi : cmpiOSBase_KaffeemaschinenSystem " ) ,

Desc r i p t i on ( " Das System der Kaffeemaschinen wi rd h i e r beschrieben . "

"Es f a s s t a l l e Kaffeemaschinen i n einem Verwaltungssystem "

"zusammen . " )

]

c lass FHW_KaffeemaschinenSystem : CIM_System

{

} ;

ins tance of FHW_KaffeemaschinenSystem {

Name = " dopsy_KaffeemaschinenSystem " ;

Handle = " dopsy_KaffeemaschinenSystem " ;

} ;

[ Prov ider ( " cmpi : cmpiOSBase_Kaffeetr inker " ) ,

Desc r i p t i on ( " Die Klasse ä r e p r s e n t i e r t d ie Benutzer des "

" Kaffeemaschinen−Systems "

" Diese Benutzer l e i t e n s ich von den StandarD−Benutzern ab und "

" haben s p e z i e l l e A t t r i b u t e , d ie d ie notwendigen In format ionen "

" vo rha l ten . " )

]

c lass FHW_Kaffeetr inker : CIM_Person

{

[ Desc r i p t i on ( " Boo l i scher Wert , der ang ib t ob d ieser Benutz ter das "

44

" Recht "

" / Die Er laubn is hat , Kaffee von den Kaffeemaschinen zu "

" entnehmen . " )

]

boolean Zapfe r laubn is ;

[ Desc r i p t i on ( " Das A t t r i b u t S r i c h l i s t e ä e n t h l t d ie Anzahl a l l e r

" verbrauchten Kaffees durch den Benutzer . Dieses A t t r i b u t "

" wi rd zur Z e i t n i c h t benutz t . " )

]

u in t32 S t r i c h l i s t e ;

[ Desc r i p t i on ( " Array mi t den dem User zugeordenten TassenID ’ s " )

]

u in t32 TassenID [ ] ;

[ Desc r i p t i on ( " Array mi t den äDeta i lvorgngen . Jeder Vorgang "

" e n t s p r i c h t einem verbrauchten Kaffee " )

]

s t r i n g Deta i lvorgang ;

} ;

[ Prov ider ( " cmpi : cmpiOSBase_Kaffeemaschine " ) ,

Desc r i p t i on ( " Diese Klasse r e p r a s e n t i e r t d ie Kaffeemaschinen . Sie "

"ä e n t h l t a l l e notwendigen In format ionen d ie d ie "

" Kaffeemaschine b e s i t z t und d ie ü f r das Management "

" i n t e r e s s a n t s ind . " )

]

c lass FHW_Kaffeemaschine : CIM_ManagedSystemElement

{

[ Desc r i p t i on ( " Die ID der Kaffeemaschine i s t uniqe im System und mi t i h r "

" kann diese Angesprochen und i d e n t i f i z i e r t werden . " )

]

u in t32 maschinenID ;

[ Desc r i p t i on ( " Der Kaf feepre is , g i b t den Pre is ü f r eine Tasse Kaffee an "

" d ieser Maschine an . " )

]

u in t32 k a f f e e p r e i s ;

[ Desc r i p t i on ( " Die Periode d ie e in Abrechnungszeitraum i n Tagen umfasst . " )

]

u in t32 abrechnungsperiode ;

[ Desc r i p t i on ( " Das Datum wann die änchste Abrechnung üdurchge fh r t wi rd . " )

]

s t r i n g abrechnungsdatum ;

45

[ Desc r i p t i on ( " Boo l i scher Wert , der Angibt ob ü f r jeden Zapfvorgang e in "

" d e t a l i e r t e r , das h e i s t mi t Datum , Ze i t , Menge usw . , "

" Datensatz "

" oder nur das Ere ign i s se lber gespe icher t werden s o l l . " )

]

boolean de ta l l i e r teDa tenSpe icherung ;

[ Desc r i p t i on ( " Der äTrese rbeh l te r i s t v o l l und muss e n t l e e r t werden . " )

]

boolean t r e s e r _ v o l l ;

[ Desc r i p t i on ( " Die Kaffeemaschine i s t angescha l te t und B e t r i e b s b e r e i t . " )

]

boolean maschine_an ;

[ Desc r i p t i on ( " Die Kaffeemaschine h e i z t s i ch auf Bet r iebs tempera tur auf . " )

]

boolean aufheizen ;

[ Desc r i p t i on ( " Der Wasserbehalter ä e n t h l t n i c h t mehr ügengend Wasser . " )

]

boolean wasser_leer ;

[ Desc r i p t i on ( " Entweder d ie Maschine muss g e r e i n i g t werden , oder der "

" Reinigungsvorgang ä l u f t grade . Der Zusand wird durch einen "

" S t r i n g d a r g e s t e l l t . " )

]

s t r i n g re i n i gen ;

[ Desc r i p t i on ( " Entweger d ie Machine muss e n t k a l k t werden , oder der

" Prozess ä l u f t grade . "

" Der Zusand wird durch einen S t r i n g d a r g e s t e l l t . " )

]

s t r i n g entka lken ;

[ Desc r i p t i on ( " Ein In tege r der d ie ID der Tasse angibt , d ie s ich zur Z e i t "

" i n der Maschine be f i nde t . " )

]

u in t32 tassenIDImFeld ;

} ;

[ Prov ider ( " cmpi : cmpiOSBase_laufendeKaffeemaschinen " ) ,

Desc r i p t i on ( " Diese Assoziazions−Klasse s t e l l t a l l e Kaffeemaschinen im

" System dar . Die Klasse Kaffeemaschine wi rd mi t dem"

" KaffeemaschinenSystem verbunden . " )

]

c lass FHW_laufendeKaffeemaschinen : CIM_SystemComponent

{

[ Overr ide ( " GroupComponent " ) ,

46

Desc r i p t i on ( " Referenz auf das KaffeemaschinenSystem . " )

]

FHW_KaffeemaschinenSystem REF GroupComponent ;

[ Overr ide ( " PartComponent " ) ,

Desc r i p t i on ( " Referenz auf d ie Kaffeemaschinen . " )

]

FHW_Kaffeemaschine REF PartComponent ;

} ;

47

D Literaturverzeichnis

Literatur

[dmt] WBEM. wikipedia. www.dmtf.org

[Eck03] ECKSTEIN, Denise: WBEM Overview / HP. 2003. – Präsentation

[HGH99] HEINZ-GERD HEGERING, Bernhard N.: Integriertes Management vernetzter Systeme. dpunkt-Verlag,

1999

[mof] Beschreibung der CIM-Schemata. http://wbemservices.sourceforge.net/mofhtml/

[Neu03] NEUMANN, Heidi: CIM MANAGEMENT INSTRUMENTATION : ARCHITECTURE / sblim-Projekt. 2003.

– Howto

[Sch05] SCHUUR, Adrian: sfcb Small Footprint Cim Broker Introduction / IBM. 2005. – Präsentation

[toc04] Systems Management: Common Manageability Programming Interface (CMPI) / The Open Group.

2004. – Spezifikation

[wika] www.de.wikipedia.org/LDAP

[wikb] www.de.wikipedia.org/WBEM

[Woo00] WOOD, Doug: Guidelines for CIM-to-LDAP Directory Mappings / DMTF. 2000. – Spezifikation

[www] Elearning Modul Management Verteiler-Systeme. wwwvs. www.dmtf.org

48

Die Instrumentierung einer Kaffeemaschine mit CIM/WBEMEnumerateInstances Mit dieser Methode können...

Documents

Transcript of Die Instrumentierung einer Kaffeemaschine mit CIM/WBEMEnumerateInstances Mit dieser Methode können...