Sprungmarken

Servicenavigation

Hauptnavigation

Sie sind hier:

Hauptinhalt

C-OSGi - Entwicklung eines verteilten virtuellen OSGi-Frameworks

C(ooperative)-OSGi

 

Entwicklung eines verteilten virtuellen OSGi-Frameworks.

Die OSGi-Technologie ist eine Java-basierte und service-orientierte Middleware-Plattform. Sie ist inzwischen weit verbreitet und es existieren für sie verschiedene Implementierungen und Entwicklungswerkzeuge. Ein prominentes Beispiel dürfte die Entwicklungsumgebung Eclipse sein. Aufgrund des geschichtlichen Ursprungs im Bereich der Settop-Boxen und Kabelmodems sieht OSGi jedoch nur ein einzelnes Framework auf in einer isolierten Java-VM vor. Auch wenn mittlerweile zahlreiche Schnittstellen zur Außenwelt, wie z.B. HTTP, Webservices, UPnP, etc. spezifiziert sind, so gibt es keinen Standard, der zwei OSGi-Frameworks miteinander verbindet. Diese Eigenschaft von OSGi stellt für alle Anwendungen ein Problem dar, in denen Ausfallsicherheit gewünscht ist.

 

Das Ziel des C-OSGi Projektes ist, diese Schwachstelle von OSGi durch ein verteiltes virtuelles Framework zu beheben und gleichzeitig Werkzeuge zu dessen Verwaltung zu entwickeln. Dabei verfolgt die Verteilung auf mehrere Frameworks das Ziel die Ausfallsicherheit zu steigern. Die Virtualisierung erlaubt es durch transparente Abstraktion, dass Softwarekomponenten (Bundles) die ursprünglich für ein einzelnes lokales Framework entwickelt wurden, auch in dem verteilten Framework ausgeführt werden können, ohne dass sie einen Unterschied feststellen.

 

Die zu entwickelnden Verwaltungswerkzeuge sollen dabei helfen, das virtuelle Framework trotz gestiegener Komplexität einfach zu verwalten. Darunter fallen Aufgaben wie die Anzeige des aktuellen Status und die Verwaltung der laufenden Bundles. Weiterhin soll es einfach möglich sein, das virtuelle Framework durch zusätzliche physikalische Frameworks (Knoten) zu erweitern, sowie Knoten physikalisch auszutauschen. Dabei müssen unter Umständen Bundles von dem zu entfernenden Knoten auf andere Knoten umgezogen werden. Sollte ein Knoten ausfallen, so muss ermittelt werden können, welche Bundles dort ausgeführt wurden, damit sie auf einem anderen Knoten neu gestartet werden.

 

Die bisherigen Arbeiten sind in das Callinox-Projekt eingeflossen und werden dort fortgeführt.

 

Zuständige Mitarbeiter:
Dipl.-Inf. Tobias Wegner



Nebeninhalt

Weitere Projekte