Einleitung

Mape-Loop-Integration (rotumrandete Bereiche markieren Projektumfang)

Ziel des Projekts ist es einen Konverter zu entwerfen, der aus CIM Daten eine Ontologie erstellt.

Die Idee ist es CIM Daten aus einer zu managenden Anwendung zu extrahieren und daraus eine Wissensbasis in Form von Ontologien zu erstellen, bzw. zu erweitern und daraus per Reasoning neues Wissen abzuleiten. Diese neuen Erkenntnisse können genutzt werden um die zu managende Anwendung effizient zu steuern.

Hierzu mussten sich die Projektteilnehmer zunächst mit den Grundlagen des CommonInformationMetamodel vertraut machen. Ebenso erfolgte eine Einarbeitung in die freien CIMOM-Implementierungen OpenPegasus und SBLIM. Neben den CIM-Grundlagen brauchten die Projektteilnehmer noch Kenntnisse in der Handhabung von Ontologien und der Nutzung des Jena Semantic Web Frameworks, sowie in der Modellabfrage mit SPARQL unter Verwendung von Jena ARQ. Diese wurden anhand von W3C und die Jena-Dokumentation, sowie der OWL-Modellierung anhand des Modellierungswerkzeugs "Protegé 4" erlangt.

Das Projekt umfasst die Bereiche Sensors, Monitor, Analyse und Knowledge aus dem Mape-Loop (siehe Abb. Mape-Loop-Integration). Dabei besteht setzt sich die Monitorkomponente aus den CIM-Providern (Sensors) und dem CIMOM zusammen. Der Mapper (CIM nach OWL) bezieht seine Daten aus dem CIMOM.

Problemanalyse

Für die Integration von CIM stellt sich für die angedachte Integration in das autonome Management eines Systems als nur bedingt geeignet heraus. Es gibt schlicht keine Schnittstelle um CIM-Daten mit anderen Daten zusammenzuführen. Zudem stellt sich das Hantieren mit CIM-Daten über einen CIM-Client als nicht geeignet für Automatismen dar. Allerdings machen Untersysteme die über CIM ihre Daten bereitstellen, wie z.B. OS-Basisinformationen (Speicherauslastung, laufende Prozesse, ...) und Storage Area Networks (SAN) einen wichtigen Teil im angedachten Gesamtsystem aus. D.h. diese Daten müssen in die Wissensbasis des zu managenden Systems aufgenommen werden. Aktuell sind OWL-Ontologien im Blickpunkt der Forschung und so liegt es nahe, die CIM-Daten in eine Ontologie einzubringen. Auf der Ontologie können auch schnelle Datenabfragen mittels SPARQL ausgeführt werden. Bei der Datenabfrage, bzw. der Analyse der Daten kann also erwartet werden, dass es von CIM zu OWL zu einer Geschwindigkeitssteigerung kommt. Ein Mapper, der die CIM-Klassen inkl. aller Instanzen, welche vom CIMOM zur Verfügung gestellt werden, soll somit im Mittelpunkt dieses Projekts stehen. Ziel ist es letztendlich die CIM-Daten in der Wissensbasis als OWL-Ontologie vorliegen zu haben.

Konzept

Komponentenübersicht

Übersicht

Monitor
1. Einlesen der OWL-Ontologie mittels Jena.
2. Auslesen der Daten aus OpenPegasus (CIMOM) mittels SBLIM CIM Client.
3. Gemäß der aus OpenPegasus ausgelesenen Daten Instanzen mittles Jena erzeugen.
Execute
1. SPARQL

Einarbeitung

OSGI

Einlesen in die Erstellung von Programmen mithilfe von OSGI.
Nutzung der Tutorials auf http://oscar-osgi.sourceforge.net/
Programmieren anhand von Beispielen von http://oscar-osgi.sourceforge.net/tutorial/
Stopp der Nutzung von OSGI - Übereinkuft, dass die Konzentration auf die Erstellung des CIM Import- und Export-Moduls liegt

CIM

Einlesen in CIM mithilfe der Literatur "Common Information Model" von Wiley und auf http://dmtf.org/standards/cim
Evaluieren der für unser Projekt passendsten CIMOMs
OpenPegasus als CIMOM nicht in Betracht gezogen, da nicht in Repositories vorhanden
Nutzung von SBLIM CIMOM (http://sblim.sourceforge.net)

Ontologien

Einarbeitung in die Modellierung von Ontologien mit OWL per http://www.w3.org/TR/owl2-overview/
Nutzung von Protegé als GUI für die strukturierte Darstellung von Ontologien
Nutzung des Jena Semantic Web Frameworks für die programmatische Erstellung von Ontologien und RDF Graphen

Protegé
- Erstellen von Ontologien mithilfe von Protege anhand eines Pizza Beispiels (ProtegeOWLTutorialP4_v1_3)
- Ableiten von neuem Wissen mithilfe eines Reasoners

Jena
Einarbeitung in die Struktur eines RDF Graphen in Jena

Programmatischer Nachbau der Pizza Ontologie aus dem Protegé Tutorial in Jena

Realisierung

CIM

Installation

Verwendung von Ubuntu 11.10 als Host.

Installation der folgenden Pakete:

sfcb (Small Footprint CIM Broker)
sblim-cmpi-base (SBLIM base CMPI provider)
sblim-cmpi-common (Common scripts for CMPI base providers)

Die beiden Provider stellen Informationen über das OS und die darauf laufenden Prozesse zur Verfügung. Beide Provider implementieren CMPI (The Common Manageability Programming Interface), welches ein offener Standard für das Interface von CIM-Providern ist. Somit sollten die Provider auch zusammen mit anderen CIMOMs arbeiten.

Siehe auch: http://en.wikipedia.org/wiki/Common_Manageability_Programming_Interface

Wichtig: MOF-Dateien unter Ubuntu wie folgt installieren:

sudo -s
cd /usr/share/sfcb/CIM
curl http://dmtf.org/sites/default/files/cim/cim_schema_v2300/cim_schema_2.30.0Final-MOFs.zip -o cimof.zip
unzip cimof.zip
rm cimof.zip

Verwendete Java-Bibliothek

Verwendung des SBLIM CIM-Client (JSR48: WBEM Services Specification kompatibel)
Website: http://sourceforge.net/apps/mediawiki/sblim/index.php?title=CimClient
Source: http://sblim.cvs.sourceforge.net/viewvc/sblim/jsr48-client/?view=tar

Hinweis: Am besten erstellt man für die SBLIM CIM-Client-Sourcen ein Eclipse-Projekt. Dieses Projekt kann dann als abhängiges Projekt im CIM-Mapper-Projekt angegeben werden.

Programmatisches Vorgehen

Klassendiagramm: CIM-Daten

Daten vom CIMOM werden zum SBLIM CIM-Client in XML übertragen
Mapping von XML in Java-Klassen (SBLIM CIM-Client)
Mapping der SBLIM Klassen in von SBLIM CIM-Client unabhängige und hierarchisch geordnete Klassen
Datenaustausch zum OWL-Teil des Mappers
Momentan: Serialisieren der Klassenhierarchie zum Datenaustausch

Anmerkung: Die Serialisierung soll keine endgültige Lösung darstellen, sondern diente nur während des Entwicklungszeit zum einfachen Datenaustausch zwischen den einzelnen Projektteilnehmern.

Beschreibung der Java-Klassen

package de.hsrm.vs.itm
- CimClient: Mapper um den SBLIM CIM-Client
- CimWrapper: Hier werden die CIM-Daten in die von SBLIM unabhängigen Klassen umgewandelt
- SerializeUtil: Util-Klasse zur Unterstützung der Serialisierung der CIM-Daten
- StopWatch: Klasse zur Performancemessung
- Main: Beispielhafter Aufruf des CimWrapper und Mappen der CIM-Daten
package de.hsrm.vs.itm.cim (enthält die CIM-Daten-Modellklassen)
- CimClass
- CimClassProperty
- CimInstance
- CimInstanceProperty
- CimQualifier

Beispielhaftes Vorgehen beim Abrufen der CIM-Daten

URL cimomUrl = new URL("http://127.0.0.1:5988");
CimWrapper wrapper = new CimWrapper(new CimClient(cimomUrl));
wrapper.process();
List<CimClass> cimClasses cimClasses = wrapper.getRootCimClasses();
Map<String, CimClass> cimClassMap = wrapper.getCimClassMap();

In cimClasses sind die CIM-Klassen abgelegt, die im Root des CIMOM liegen. Über getChildren() können die jeweils untergeordneten Klassen zurückgegeben werden.

In cimClassMap liegen alle CIM-Klassen vor. Der Key ist jeweils der CIM-Klassenname.

Es ist zu beachten, dass durch wrapper.process() alle CIM-Daten abgerufen werden. getRootCimClasses() und getCimClassMap() geben lediglich eine Referenz auf die im Wrapper gespeicherten Daten zurück.

CIM-Mapping

CIM-Klassen -> OWL-Klassen
CIM-Attribute/Attributwerte -> Data-/Object-Properties
CIM-Instanzen -> OWL-Individuals
CIM-Qualifier -> Kommentare/Restriktionen

Obenstehend wird verdeutlicht welche CIM-Elemente in welche OWL-Elemente umgewandelt werden.

Serialisieren der CIM-Daten

Mit new File(SerializeUtil.DATA_FILE).exists() kann geprüft werden, ob serialisierte Daten vorliegen.

Wurden die CIM-Daten abgerufen, können sie mittels SerializeUtil.writeRootClasses(cimClasses) in SerializeUtil.DATA_FILE geschrieben werden.

Ausgelesen werden vorhandene Daten mit

List<CimClass> cimClasses = SerializeUtil.readRootClasses();
Map<String, CimClass> cimClassMap = SerializeUtil.generateCimClassMap(cimClasses);

Wichtig: Die serialisierten Daten werden in die Datei cim.data im Home-Verzeichnis des aktuellen Benutzers geschrieben. Ausschlaggebend ist die Konstante SerializeUtil.DATA_FILE.

Jena

Installation

Verwendung von Mac OS X 10.7 Lion als Host, jedoch prinzipiell jedes javafähige System verwendbar.

Unter login1.mi.hs-rm.de/home/master/mloss002/public_rw/ befindet sich derzeit unter anderen ein komplettes Eclipse-Projekt mit dem Namen "de.hrsm.ontologycreator.zip" das per "Import existing Projects into workspace" eingelesen werden kann.

Neben dem Projekt mit den Java-Paketen wird noch die Datei mit den serialisierten CIM Informationen benötigt. Diese heißt "cim.data" und muss in das User Verzeichnis kopiert werden, also /Users/<Username>/. Aus diesem Verzeichnis können die Funktionen in der Bibliothek cimdata.jar zugreifen. Diese Einschränkung dient der Einfachheit und kann bei belieben in neueren Versionen programmatisch geändert werden.

Folgende Pakete sind im Projekt enthalten:

Jena (http://incubator.apache.org/jena/)
ARQ-2.8.8 (http://sourceforge.net/projects/jena/files/ARQ/)
pellet-2.3.0 (http://clarkparsia.com/pellet/download/)
tdb-0.8.10 (http://sourceforge.net/projects/jena/files/TDB/)
cimdata.jar (Kay Müller)

Wichtig Nach der Ausführung des Programms sollten mehrere Ordner und Dateien erstellt worden sein:

DB1/
cim.owl
cimDebug.txt
cimPellet.owl
cimPelletInferences.owl
cimTurtle.owl

Diese werden derzeit unter /Users/mick/Documents/workspace/ITMGMT/data/ gespeichert. Dieser Pfad ist ebenso aus Gründen der Einfachheit hard gecodet, kann jedoch in der Klasse NamesHelper im Paket de.hsrm.ontologycreator.helper abgeändert werden.

Entwicklungsumgebung

protegé (http://protege.stanford.edu/download/download.html)
eclipse (http://www.eclipse.org/)

Programmatisches Vorgehen

Aufbau der Ontologie aus den serialisierten CIM Daten

Einlesen der CIM Struktur aus serialisierter Dateistruktur (alternativ aus TDB lesen falls vorhanden)

OntologyCreator ontologyCreator = new OntologyCreator();

boolean existingOntologyDB = ontologyCreator.checkOntologyDBExistence(NamesHelper.ontFileFolder + "DB1");
if (existingOntologyDB) {
    ontologyCreator.loadOntologyFromTDB(NamesHelper.ontFileFolder + "DB1");

} else {
    // we have no DB, so create an ontology from scratch
    List<CimClass> cimClasses = SerializeUtil.readRootClasses();
    Map<String, CimClass> map = SerializeUtil.generateCimClassMap(cimClasses);
    Collection<CimClass> cimClassCollection = map.values();

    String path = NamesHelper.ontFileFolder + "DB1";
    new File(path).mkdirs(); // using with osgi we have to create the folder manually, dont know really why, otherwise exception
    ontologyCreator.createOntology(cimClassCollection, path);
}
ontModel = ontologyCreator.getOntModel();

Generierung der Klassenstruktur, CIM-Klassen auslesen und Jena-Klassenhierarchie erstellen
CIM-Qualifier auslesen, Klassenkommentare erstellen
Erstellung der Data- und Object-Properties
CIM-Properties auslesen, Object und Datatype Properties erstellen (Referenz entscheidet ob Object oder Datatype Property)
CIM-Qualifier auslesen, Restriktionen erstellen
Erstellung der Instanzen (Individuals)

Weitere Operationen:

Persistieren der Onotlogie

Daten in TDB schreiben
Auslesen der vorhandenen Ontologie aus der TDB mit erheblichen Geschwindigkeitsgewinn
Erstellung von Dateien im .owl-Format, sowie im .owl-Turtle-Format

Reasoning der Ontologie per Pellet Reasoner

Erstellen von cimPellet.owl mit neuem Wissen
Lediglich das abgeleitete, neue Wissen per cimPelletInferences.owl

pelletReasoner.reason(ontologyCreator.getOntFileName());

Datenbankqueries per SPARQL

Abfragen an die Datenbank per SPARQL (in ARQ Library enthalten)
Beispiel, Finden des <eclipse>-Prozess

String prolog1 = "PREFIX : <" + "http://localhost/owl/ontologies/cim.owl#" + ">";
String prolog2 = "PREFIX rdfs: <" + "http://www.w3.org/2000/01/rdf-schema#" + ">";
String prolog3 = "PREFIX owl: <" + "http://www.w3.org/2002/07/owl#" + ">";
String prolog4 = "PREFIX xsd: <" + "http://www.w3.org/2001/XMLSchema#" + ">";
String prolog5 = "PREFIX base: <" + "http://localhost/owl/ontologies/cim.owl" + ">";
String prolog6 = "PREFIX rdf: <" + "http://www.w3.org/1999/02/22-rdf-syntax-ns#" + ">";

String select = "SELECT ?name ?handle WHERE { ?x a :Linux_UnixProcess . ?x :Name ?name . ?x :Handle ?handle . FILTER regex(?handle, \"3727\")}";
String queryString = prolog1 + prolog2 + prolog3 + prolog4 + prolog5 + prolog6 + NamesHelper.NL + select;

Query query = QueryFactory.create(queryString);

// formatted, call with ontModel oder dataset
sparqlOutput.printQuery(queryString);

Beschreibung der Java-Klassen

de.hsrm.ontologycreator
- OntologyWalkthrough: Stößt einen exemplarischen Durchlauf aller Funktionen des Programms an

de.hsrm.ontologycreator.create
- OntologyCreator: Erstellt die Ontologie (Klassenhierachie, Abhängikeiten, Restriktionen, ...) aus der cim.data Datei.
- PizzaNewCreator: Nur zu Testzwecken. Programmatischer Aufbau der Pizza Ontologie

de.hsrm.ontologycreator.helper
- NamesHelper: Hilfsvariablen die programmübergreifend genutzt werden

de.hsrm.ontologycreator.input
- OntologyReader: Einlesen einer owl-Datei

de.hsrm.ontologycreator.osgi
- Activator: Nur zu Testzwecken. Eine einfache OSGi Implementation
- OntologyWalkthroughService: Nur zu Testzwecken. Eine einfache OSGi Implementation
- OntologyWalkthroughServiceInterface: Nur zu Testzwecken. Eine einfache OSGi Implementation

de.hsrm.ontologycreator.output
- ClassHierarchy: Nur zu Testzwecken. Ausgabe der Klassenhierarchie
- DescribeClass: Nur zu Testzwecken. Ausgabe von Klasseninformationen
- PropertyOutput: Nur zu Testzwecken. Ausgabe von Property-Informationen.
- SPARQLOutput: Übernimmt die Ausgabe der SPARQL Ergebnisse

de.hsrm.ontologycreator.persist
- OWLFileCreator: Erstellt owl-Dateien

de.hsrm.ontologycreator.query
- ExProg1: Nur zu Testzwecken. Beispielabfragen
- GenericExample: Nur zu Testzwecken. Beispielabfragen
- PizzaExample_1: Nur zu Testzwecken. Beispielabfragen

de.hsrm.ontologycreator.reason
- PelletReasoner: Übernimmt das Reasoning
- PelletReasonerTest: Nur zu Testzwecken.

Ergebnisse

Überblick

Folgende Visualisierungen wurden mithilfe von Protegé dargestellt:

CIM-Klassenhierarchie als Jena Ontologie
Kommentare zu den Klassen
Restrictions auf den Klassen (Quantitätsrestriktionen wie Min-Max, Some, etc.)

Klassenkommentare und weitere Beschreibungen

Klassenhierarchie
Klassenbeschreibungen/Restriktionen

Properties
- Object Properties, benötigt um Individuals zu referenzieren
- Datatype Properties, benötigt um Individuals Datenwerte zu geben

Properties
Datatype Properties
Object Properties

Individuals (Instanzen)
- Zugeordnet zu seiner Klasse
- Beschrieben mit Datatype- und Object Properties

Individuals
Individuals
Individuals mit Datatype Properties
Individuals mit Object Properties

Funktionalität

Erstellung

cim.data auslesen
Ontologie wird komplett aufgebaut
Kein Diff / Update
Referenzen zu Individuals noch nicht implementiert

Operationen

Datenbankabfrage per SPARQL
Reasoning

Persistenz

Speichern in TDB, auslesen aus TDB
Erstellen von owl.- Dateien
- im RDF Format
- im Turtle Format

Bewertung

Erwartungen

Monitoring muss schnell sein
Echtzeitüberwachung des Systems
(Inkrementelles) Update der Ontologie Daten (Knowledge)
Schnelle Analyse durch SPARQL
Neues Wissen, welches durch Reasoning gewonnen wurde, zur Optimierung des beobachteten Systems nutzen

Performanz

CIMOM
- Daten nicht vorhanden:
  - Daten vom CIMOM holen und Klassenhierarchie mappen: ~18 sec
  - Serialisieren der Daten: ~3 sec
- Daten vorhanden
  - Deserialisieren: ~3 sec

Ontologieerstellung
- Ausgangslage: TDB nicht vorhanden:
  - Daten aus cim.data auslesen: ~5 sec
  - Ontologie erstellen: ~8 sec
- Ausgangslage: TDB bereits vorhanden:
  - Daten aus TDB auslesen: ~4 sec
  - restliche Operationen wie gehabt
  - Ersparnis von ~5 sec + ~8 sec - ~4 sec = ~9 sec; Gesamtzeit: ~11 sec

SPARQL
- TDB Anfrage: ~0,1 sec bei einer simplen Abfrage nach einer Prozessnummer.

Reasoning
- Reasoning: ~5 sec

Praktikabilität
- Derzeit nicht gegeben, da zu langsam. Die Ontologieerstellung muss nicht jedesmal erfolgen. In zuünftigen Version würde ein Diff ausreichen, bei dem lediglich Änderungen an der Struktur hinzugefügt werden, sowie die Aktualisierung der Informationen in den Instances.

Ausblick

Produktiveinsatz
Verschmelzung der Bausteine (CIM auslesen, Ontologie erstellen), verzicht auf Serialisierung
Diff der Ontologien
Update der Ontologie

Probleme

Die Wissensbasis kann momentan nicht partiell aktualisiert werden. So müssen jedes Mal die kompletten CIM-Daten vom CIMOM geholt werden und der komplette Mapping-Prozess durchlaufen werden.
Die Referenzierung von Instanzen funktioniert noch nicht richtig. Instanzen können zwar zu den jeweiligen Klassen zugeordnet werden, allerdings nicht zu anderen referenzierten Instanzen. Dazu muss noch eine eindeutige Kennung für die Instanzen implementiert werden, etwa ein Hash über alle Key-Attribute einer Instanz. Momentan führt die fehlende Zuordbarkeit dazu, dass in der Ontologie Individuals mit dem Namen der Klassen der referenzierten Individuals angelegt werden.

(WS11-09) CIM Import- und Export-Module für das Jena Semantic Web Framework

Einleitung

Problemanalyse

Konzept

Übersicht

Einarbeitung

OSGI

CIM

Ontologien

Realisierung

CIM

Installation

Verwendete Java-Bibliothek

Programmatisches Vorgehen

Beschreibung der Java-Klassen

Beispielhaftes Vorgehen beim Abrufen der CIM-Daten

CIM-Mapping

Serialisieren der CIM-Daten

Jena

Installation

Entwicklungsumgebung

Programmatisches Vorgehen

Weitere Operationen:

Persistieren der Onotlogie

Reasoning der Ontologie per Pellet Reasoner

Datenbankqueries per SPARQL

Beschreibung der Java-Klassen

Ergebnisse

Überblick

Funktionalität

Erstellung

Operationen

Persistenz

Bewertung

Erwartungen

Performanz

Ausblick

Probleme

Literatur und Quellen

CIM

OSGI

Jena + Zusatzbibliotheken

Entwicklungsumgebungen

Ontologien

Navigationsmenü

Suche