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

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen

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

  1. 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.
  2. Execute
    1. SPARQL

Einarbeitung

OSGI

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:

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

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
  • Properties
    • Object Properties, benötigt um Individuals zu referenzieren
    • Datatype Properties, benötigt um Individuals Datenwerte zu geben


  • Individuals (Instanzen)
    • Zugeordnet zu seiner Klasse
    • Beschrieben mit Datatype- und 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.

Literatur und Quellen

CIM

OSGI

Jena + Zusatzbibliotheken

Entwicklungsumgebungen

Ontologien