Entwurf einer Middleware zur Unterstützung der Entwicklung komponentenbasierender Softwaresysteme. Diplomarbeit im Fach Informatik

Transkript

1 Entwurf einer Middleware zur Unterstützung der Entwicklung komponentenbasierender Softwaresysteme Diplomarbeit im Fach Informatik vorgelegt von Tobias Limmer, B.IT. (Hons.) geboren am in Schrobenhausen Angefertigt am Institut für Informatik Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Betreuer: Prof. Dr.-Ing. habil. Wolfgang Schröder-Preikschat Dr.-Ing. Jürgen Kleinöder Dipl.-Ing. Efthimios Liakos, Siemens AG Victor Sauermann, Siemens AG Beginn der Arbeit: Abgabe der Arbeit:

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe, und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Erlangen, den

4

5 Kurzfassung Für komplexe Anwendungen setzt sich immer mehr die komponentenbasierte Entwicklung durch. Dabei werden Komponenten entworfen, welche möglichst unabhängig voneinander eingesetzt werden können. Ein Ziel ist die Wiederverwendung von Komponenten, welche aber durch die Verwendung von unterschiedlichen Middlewareplattformen eingeschränkt wird: es muss zusätzlicher Entwicklungsaufwand investiert werden, Komponenten von einer Plattform auf die andere zu portieren. Diese Arbeit entwickelt einen Prototyp einer Middlewareschicht, welcher die Schnittstellen unterschiedlicher Middlewareplattformen abstrahiert und Anwendungen eine einheitliche Schnittstelle zur Verfügung stellt. Dabei werden hierarchische Komponentenstrukturen in der Konfiguration unterstützt. Zusätzlich wird eine leichtgewichtige Implementierung von Middlewarediensten zur Verfügung gestellt, sodass die Ausführung komponentenbasierter Anwendungen auch ohne Middlewareplattform möglich ist, wie beispielsweise für GUI-Anwendungen. Abstract Component-based design is becoming more and more common for the development of complex applications. One of its goals is the reuse of components. This goal is constricted by the employment of different middleware platforms: additional effort needs to be invested to port components between platforms. This work devises a prototype of a middleware layer which abstracts interfaces of different middleware platforms. A common interface is provided to the application and thus independence of middleware platforms is achieved. To enable the execution of component-based applications like GUI applications without the use of a heavyweight middleware platform, we also provide a lightweight implementation of middleware services.

6

7 Danksagung Ich bedanke mich vielmals bei all denen, die mir geholfen haben diese Arbeit fertigzustellen. Als Erstes möchte ich mich bei meinen Betreuern bei Siemens, Efthimios Liakos und Victor Sauermann, für die Möglichkeit bedanken, meine Diplomarbeit in der Wirtschaft schreiben zu können. Sie standen mir zu jeder Zeit mit Rat und Tat zur Seite. Auch bei meinen wissenschaftlicher Betreuer Dr. Jürgen Kleinöder möchte ich mich sehr für seine Ratschläge und gedankliche Führung bedanken. Weiterhin möchte ich Wolfgang Rössler für die hilfreichen Diskussionen und Kommentare danken. Die sehr gute Arbeitsatmosphäre in der Abteilung I&S Software Factory trug viel zum Gelingen dieser Arbeit bei. Ohne der ständigen Unterstützung meiner Familie wäre es mir natürlich auch nicht möglich gewesen, diese Arbeit abzuschließen. Vielen Dank!

8 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Akronyme ix ix xi 1. Einführung Motivation Ziele Struktur der Arbeit Überblick Komponentenbasierte Entwicklung UML Middleware Einführung Implementierungen Analyse der verwendeten Middlewareplattformen JMX Aufbau Managed Beans JMX in JBoss OSGi Überblick Aufbau Komponentenintegration Spring Framework Überblick Inversion-of-Control Container Spring OSGi Vergleich JMS

9 Inhaltsverzeichnis ix Überblick JMS in JBoss Zusammenfassung Entwurf einer plattformunabhängigen Middlewareschicht Voraussetzungen und Ziele Angebotene Dienste Lebenszyklus Schnittstellenimport und -export Asynchroner Nachrichtenaustausch Verwendung Einbindung in Komponente Komponentenhierarchie Asynchroner Nachrichtenaustausch Konfiguration Buildprozess Ausführung Internes Design Aufbau von CIML Komponentenlebenszyklus Schnittstellenimport und -export Asynchroner Nachrichtenaustausch CIMLBuild Zusammenfassung Diskussion Design Zyklen bei Schnittstellenimport und -export Komponentensichtbarkeit Vergleich von dynamischer und statischer Komponentenerstellung Erfüllung der Anforderungen Vergleich mit Spring OSGi Fazit Zukünftige Arbeit A. Aufbau von CIML 82 A.1. Klassendiagramme A.2. CIML-Classloader Prozess

10 x Inhaltsverzeichnis B. Programmatische Schnittstellen zur Anwendung 85 B.1. AMS B.2. ShutdownTriggerBean C. Konfiguration 86 C.1. Definition C.2. Beispiel C.2.1. Überblick C.2.2. CIML C.2.3. JBoss C.2.4. OSGi

11 Abbildungsverzeichnis 1.1. Quellcodezeilen in Microsoft Windows c Betriebssystemen Schnittstellen von Komponenten in der UML Komponentenverbindung in der UML Delegierende Ports in der UML Kommunikation zwischen Komponenten mit Hilfe von Middleware Beispiel für synchrone Kommunikation zwischen Komponenten Systemarchitektur von JMX Architekturebenen von OSGi Funktionsweise des Spring Containers Struktur einer Queue beim Point-to-Point Modell von JMS Struktur eines Topics beim Publish-Subscribe Modell von JMS Aufteilung des IoC Paradigmas auf zwei Ebenen Hierarchische Anordnung von Komponenten Zustandsdiagramm des Komponentenlebenszyklus Import einer Schnittstelle in den Spring Applikationskontext Applikationskonfiguration für Verbindung von Komponenten Einbindung von CIML innerhalb einer Komponente Beispiel einer Komponentenhierarchie Beispiel eines delegierenden Ports Beispiel eines internen Ports Buildprozess von Anwendungen für CIML Dienste von CIML mit benutzten Bibliotheken Interaktion von CIML mit externen Einheiten Klassenstruktur des ComponentManagers Aufrufstruktur des CIML-Containers in der Komponentehierarchie Ablaufskizze eines Schnittstellenimports ohne Benutzung einer externen Middlewareplattform Ablaufskizze eines Schnittstellenimports mit Benutzung einer externen Middlewareplattform

12 xii Abbildungsverzeichnis Ablaufskizze eines Schnittstellenimports von einer intern sichtbaren Komponente AMS Zugriffe zwischen intern und extern sichtbaren Komponenten Beispiele für Zyklen bei Import und Export von Schnittstellen Ablauf bei Verwendung einer Rückruffunktion Konflikte bei unterschiedlichen Komponentensichtbarkeiten

13 Tabellenverzeichnis 3.1. Funktionsvergleich zwischen Middlewareplattformen Vergleich von synchronem Nachrichtenaustausch und Lebenszyklusmanagement zwischen Middlewareplattformen

14 Akronyme AMS API CCM CIML CORBA DRE DSML EJB HTTP IDL IoC JAR Java EE JFC JMS JMX LGPL MDA MOM OMG OSGi POJO RMI RPC SOA SQL UML XML Asynchronous Messaging Service Application Programming Interface CORBA Component Model Container Independent Middleware Layer Common Object Request Broker Architecture Distributed Real-time and Embedded Domain-Specific Modeling Language Enterprise Java Beans Hypertext Transfer Protocol Interface Description Language Inversion of Control Java Archive Java Enterprise Edition Java Foundation Classes Java Message Services Java Management Extensions GNU Lesser General Public License Model Driven Architecture Message Oriented Middleware Object Management Group Open Standards Gateway Initiative Plain old Java Object Remote Method Invocation Remote Procedure Call Service Oriented Architecture Structured Query Language Unified Modeling Language Extensible Markup Language

15 1. Einführung 1.1. Motivation Durch die steigende Automatisierung von Aufgaben in unserer modernen Gesellschaft wird immer mehr Software in den verschiedensten Geräten eingesetzt. Aufgabenbereiche von Software reichen von Haushaltsgeräten, Industrierobotern zu Computern, welche mittlerweile in jedem Haushalt üblich geworden sind. Neben der Verbreitung erhöhte sich auch der Umfang der eingesetzten Software. Vor 20 Jahren bietete eine Textverarbeitung auf einem Computer nur Textausgabe ohne grafischer Benutzerschnittstelle an. In der heutigen Zeit wird nicht nur von einer Textverarbeitung erwartet, dass man Text editieren kann, sondern dass es möglich ist, darin Grafiken zu erstellen, ein Dokument im Internet zu veröffentlichen und eine Grammatikprüfung durchzuführen. Eine Möglichkeit, die Komplexität von Software zu messen, ist die Anzahl der Quellcodezeilen, also der Lines of Code. Am Beispiel des Betriebssystems Microsoft Windows kann man sehen, dass sich innerhalb von 12 Jahren der Umfang des Quellcodes verzehnfacht hat, wie in Abbildung 1.1 gezeigt wird (Quellen: [25, 15, 6]). Im ähnlichen Maße hat sich demnach auch die Komplexität der Software gesteigert. Um die Größe von Programmen verwalten zu können, wurden immer neue Technologien in der Softwareentwicklung eingeführt. Ein immer öfter angewandtes Paradigma ist die komponentenbasierte Entwicklung von Anwendungen. Dabei wird eine Applikation aus mehreren Komponenten zusammengesetzt. Die Komponenten werden so entworfen, dass sie möglichst wenige kleine Schnittstellen und Abhängigkeiten zu anderen Kompo- 45 Microsoft Windows Lines of Code 40 NT (1993) 6 30 NT 3.5 (1994) NT (1996) (2000) XP 5(2002) 40 0 Vista Beta 2 (2005) 50 Mio. Lines of Code 50 NT 3.1 (1993) NT 3.5 (1994) NT 4.0 (1996) 2000 (2000) XP (2002) Vista Beta 2 (2005) Abbildung 1.1.: Quellcodezeilen in Microsoft Windows c Betriebssystemen

16 2 Einführung nenten besitzen. Durch diese Methodik ist es möglich, während der Entwicklung eine bessere Übersicht über eine Anwendung zu erhalten, und dadurch die Programme besser zu strukturieren. Dies verkürzt die Entwicklungsdauer, da der Quellcode weniger komplex geartet ist und sich bei der Programmierung weniger Fehler einschleichen. Ein weiterer Vorteil ist die Wiederverwendung: Komponenten eignen sich durch ihrer geringen Anzahl an Schnittstellen für Einsatz in anderen Applikationen, falls deren Funktionalität darin erneut benötigt wird. Durch die Wiederverwendung lassen sich Kosten sparen, da auf erneute Entwicklung der gleichen Funktionalität verzichtet werden kann. Oft wird im Zusammenhang komponentenbasierter Entwicklung Middleware eingesetzt. Diese stellt Funktionen zur Unterstützung der Anwendung neben dem Betriebssystem bereit. Middleware kann die Verwendung von Komponenten hinsichtlich der Verteilung über mehrere Geräte, Transaktionssicherheit, Persistierung von Objekten und vieles mehr unterstützen. Dafür existieren verschiedene Implementierungen, welche für unterschiedliche Einsatzgebiete vorgesehen sind und jeweils verschiedene Vorteile besitzen. Beispiele dafür sind das OSGi Framework für eingebettete Systeme, CORBA für programmiersprachenunabhängige Kommunikation über Netzwerke oder Java EE mit Enterprise Java Beans für Geschäftsanwendungen. Alle Funktionen dieser Middlewareimplementierungen sind darauf ausgerichtet, die Entwicklung von Anwendungen in bestimmen Bereichen zu vereinfachen. Deshalb ist es nötig, je nach Einsatzgebiet der Anwendung unterschiedliche Middlewareimplementierungen zu nutzen. Da aber viele Middlewareimplementierungen unterschiedliche Schnittstellen für die Ansteuerung von Seiten der Anwendungsseite besitzen, müssen Komponenten bei Wiederverwendung in anderer Middleware angepasst werden. Diese Aufgabe kann so aufwändig sein, dass ein großer Teil der Einsparung durch Wiederverwendung der Funktionalität aufgebraucht wird. Ein weiterer Faktor ist die Einarbeitungszeit in verschiedene Schnittstellen: D. Schmidt et al. stellen in ihrer Arbeit von 2004 [20] fest, dass Programmierer durchschnittlich 6-9 Monate zur Einarbeitung benötigen, bis sie ein Framework hocheffektiv nutzen können. Somit kann es kosteneffektiver sein, ein neues Framework zu entwickeln, wenn es die Einarbeitungszeit in mehrere Andere erspart Ziele Aufbauend auf dem Ansatz, dass ein neues Framework Portierungsaufwand von Komponenten und die Einarbeitung in unterschiedliche Frameworks erspart, soll in dieser Arbeit eine Middlewareschicht entworfen werden. Diese Schicht wird zwischen Applikation und einer Middlewareplattform eingefügt, sodass die Anwendung eine selbst definierte Schnittstelle zur Middlewareschicht ansteuert. Die außen liegende Middlewareplattform kann beliebig gewechselt werden, ohne dass der Anwendungscode innerhalb von Kompo-

17 1.3 Struktur der Arbeit 3 nenten geändert werden muss. Dadurch wird die Entwicklung von neuen Anwendungen durch die in dieser Arbeit entworfene Middlewareschicht, genannt CIML (Container Independent Middleware Layer), effizient unterstützt. Folgende Eigenschaften und Dienste soll CIML unterstützen: Registrierung und Lokalisierung von internen und externen Schnittstellen: Komponenten sollen Schnittstellen exportieren können, auf die andere Komponenten zugreifen und darüber Methoden für synchronen Nachrichtenaustausch aufrufen können. Verwaltung eines Komponentenlebenszykluses: Komponentenbasierte Programme werden häufig direkt von Middlewareplattformen gestartet. Hierbei besitzt jede Komponente einen Lebenszyklus mit mehreren Zuständen. Mit Hilfe von Ereignissen wird die Komponente über Zustandswechsel informiert. Asynchroner Nachrichtenaustausch: Ein zusätzlicher Dienst neben dem Schnittstellenimport und -export wird von CIML für asynchronen Nachrichtenaustausch über Kanäle angeboten, sodass Publish/Subscribe Systematik nachgebildet werden kann. Bereitstellung eines unterstützenden Frameworks innerhalb von Komponenten: Bestimmte Middlewarefunktionen, welche von einigen Middlewareplattformen zur Verfügung gestellt werden, können innerhalb von Komponenten benutzt werden. Dies umfasst unter anderem Persistierung oder aspektorientierte Programmierung. Somit werden Funktionen, welche nicht über mehrere Komponenten hinweg angeboten werden müssen, nur innerhalb einer Komponente zur Verfügung gestellt. Unterstützung von Standalone Anwendungen: In CIML entwickelte Anwendungen sollen ohne externe Middlewareplattformen effizient lauffähig sein, sodass auch GUI Anwendungen damit gestartet werden könnten. Hierarchische Komponentenstrukturen: In traditionellen Middlewareplattformen werden nur flache Komponentenstrukturen unterstützt. CIML wird hierarchisch geschachtelte Komponentenstrukturen mit mehreren Ebenen verwalten können. Im Geschäftsbereich sind aktuell hauptsächlich zwei Programmiersprachen im Einsatz: Java von Sun Microsystems und C von Microsoft. In dieser Arbeit wird Java verwendet und die von CIML unterstützten Middlewareplattformen sind das OSGi Framework und der Applikationsserver JBoss mit JMX Unterstützung Struktur der Arbeit In nächsten Kapitel wird ein Überblick über komponentenbasierte Entwicklung und Middleware gegeben. Im anschließenden Kapitel werden die von CIML verwendeten

18 4 Einführung Middlewareplattformen und -technologien analysiert und miteinander verglichen, damit Gemeinsamkeiten und Unterschiede zwischen den Technologien sichtbar werden. Das Design von CIML wird im darauffolgenden Kapitel beschrieben, folgend mit einer Diskussion des Designs und einer Überprüfung, ob das entwickelte Ergebnis den Zielen der Arbeit entspricht.

19 2. Überblick In diesem Kapitel wird eine kurze Einführung in die Thematik dieser Arbeit gegeben: im ersten Abschnitt wird komponentenbasierte Entwicklung und UML erläutert. Anschließend wird der Zusammenhang von Komponenten mit Middleware erklärt und verschiedene Middlewareimplementierungen kurz vorgestellt Komponentenbasierte Entwicklung Die sich erhöhende Komplexität von Software zwingt Softwaredesigner dazu, den Entwicklungsprozess immer weiter zu vereinfachen. Schon immer ist in der Geschichte der Softwareentwicklung ein Trend zur Abstraktion erkennbar gewesen. Anfangs wurde der Prozessor direkt mit Assemblerbefehlen programmiert, diese Befehle wurden später zusammengefasst und abstrahiert zu der prozeduralen Programmierung wie beispielsweise in der Programmiersprache C. Der nächste Schritt in dieser Entwicklung war die Einführung des Paradigmas der Objektorientiertheit, in der einzelne Prozeduren und Variablen zu Klassen gruppiert wurden, was die Softwareentwicklung wiederum übersichtlicher gemacht hat. Der Übergang von Programmen, welche nur auf einzelnen Rechnern ausgeführt wurden, zu sogenannten verteilten Applikationen, welche auf mehreren Computern gleichzeitig liefen und über das Netzwerk Daten austauschten, wurde durch die Verwendung von Bibliotheken, die zum Beispiel RPC (siehe auch Abschnitt 2.2.1) bereitstellen, erleichtert. Sie führten aber keine neue Vorgehensweise bei der Anwendungsentwicklung zur weiteren Abstraktion der Software ein. Diesen Schritt vollzog die komponentenbasierte Entwicklung, in der eine Anwendung nach dem Prinzip seperation of concerns in mehrere Komponenten aufgeteilt wurde. Die Definition einer Komponente ist sehr wichtig, da diese eine der Kriterien für das Design von Komponenten ist. Sie entscheidet mit, wann Anwendungscode in eine neue Komponente ausgelagert oder in eine Bestehende hinzugefügt wird. Bei diesem Thema gibt es verschiedene Sichtweisen, aber C. Szyperski bietet eine der klarsten Definitionen [24]: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

20 6 Überblick Somit lassen sich folgende Eigenschaften für Komponenten zusammenfassen (siehe auch [8, 1]): Eine Komponente realisiert abgekapselte Funktionalitäten. Es existieren explizit definierte Schnittstellen und Abhängigkeiten zwischen Komponenten. Dabei wird versucht, diese möglichst klein zu halten. Je kleiner die Interaktion zwischen Komponenten ist, desto loser sind sie gekoppelt ( loose coupling ). Diese Abkapselung verbessert die Möglichkeiten, Komponenten auszutau- schen, voneinander unabhängig zu verbessern und sie isoliert zu testen. Eine Komponente kann nicht alleine ohne andere Komponenten existieren. Applikationen werden aus mehreren Komponenten zusammengesetzt. Diese Zusammensetzung kann auch von außen geschehen. Eine unterschiedliche Zusammensetzung von Komponenten ergibt neue Applikationen. Damit ist es möglich, Komponenten wieder zu verwenden. Um möglichst effizient Komponenten entwickeln zu können, benötigt man Prozesse und Methoden, welche Leitlinien für das Design von Komponenten definieren. Hierzu werden komponentenbasierte Vorgehensmodelle entwickelt, welche Modellierungssprachen wie UML (siehe auch Abschnitt 2.1.1) einsetzen. K. Balasubramanian et al. stellen mehrere Ansätze in ihrer Publikation von 2006 vor [2]. Innerhalb von Komponenten befindet sich meistens der Anwendungscode innerhalb von Klassen. Es kann auch eine Hierarchie von Komponenten aufgebaut werden, in der eine Komponente eine oder mehrere Subkomponenten besitzen kann. Abgrenzung von SOA (Serviceorientierte Architektur) Im Gegensatz zur komponentenbasierten Entwicklung ist die SOA kein Softwareentwicklungsprozess, sondern ein Managementkonzept, nach dessen Vorgaben eine Softwarearchitektur entwickelt wird. Applikationen versuchen dabei, Geschäftsprozesse nachzubilden und dadurch möglichst flexibel auf Änderungen reagieren zu können. Hierbei wird auch das Ziel verfolgt, Abhängigkeiten zwischen den einzelnen Services (welche durch Komponenten realisiert werden können) möglichst gering zu halten. Eine genauere Abhandlung des Themas wird von M. Stal in [23] durchgeführt UML Die UML (Unified Modeling Language) ist eine freie Spezifikationssprache zur Modellierung von Objekten. Die aktuelle Version 2.0 wurde von der OMG (Object Management Group, siehe [17]) im Oktober 2004 eingeführt. Da sie in weiten Bereichen der Softwareentwicklung eingesetzt wird, fördert sie durch die standardisierte graphische Notation

21 2.1 Komponentenbasierte Entwicklung 7 <<component>> Komponente A <<component>> Komponente B Interface A Port A Interface B Port B Abbildung 2.1.: Schnittstellen von Komponenten in der UML <<component>> Komponente A Port A Port B <<component>> Komponente B assembly connector Abbildung 2.2.: Komponentenverbindung in der UML die Einführung von modellgetriebenen Entwicklungsprozessen wie zum Beispiel MDA (Model driven architecture, siehe [16]). UML definiert verschiedene Diagrammtypen für die unterschiedlichsten Bereiche der Softwareentwicklung. Unter anderen sind dort Komponentendiagramme definiert, welche sich anbieten, die Struktur und das Zusammenspiel von Komponenten übersichtlich zu modellieren. In Komponentendiagrammen wird eine Komponente mit einem Rechteck dargestellt, das in dessen Ecke rechts oben ein Symbol bestehend aus einem Rechteck mit zwei kleinen Rechtecken an der linken Seite besitzt. Um nach außen angebotene und von außen verwendete Schnittstellen graphisch zu definieren, verwendet man die in Abbildung 2.1 dargestellte Notation. Komponente A besitzt einen Port namens Port A. An diesem Port wird die Schnittstelle Interface A bereitgestellt, was durch den Kreis am Ende der Linie gekennzeichnet wird. Komponente B fordert die Schnittstelle Interface B an Port Port B an, was durch den Halbkreis dargestellt wird. Komponenten können mehrere Ports besitzen, genauso kann auch ein Port mehrere Schnittstellen importieren (also anfordern) oder exportieren (nach außen anbieten). UML erzwingt nicht die Verwendung von Ports, Schnittstellen können auch direkt an die Komponente angedockt werden. In dieser Arbeit wird allerdings nur die Darstellung mit Hilfe von Ports verwendet, da sich damit Schnittstellen effektiv gruppieren lassen. Um die Verbindung von Komponenten darzustellen, werden connectors verwendet. Die direkte Verbindung von Schnittstellen wird mit Hilfe von assembly connectors visualisiert. In Abbildung 2.2 wird die Schnittstelle von Port A mit der Schnittstelle von Port B verbunden. Hierbei ist zu beachten, dass jeweils eine exportierende Schnittstelle mit mehreren importierenden Schnittstellen verbunden werden kann. Falls mehrere

22 8 Überblick <<component>> A delegate <<component>> B Klasse C delegate Interface C Interface C Port A2 Interface B Port A1 Interface B Port B Klasse D delegate Interface D Interface D Abbildung 2.3.: Delegierende Ports in der UML Schnittstellen einem Port zugehörig sind, müssen alle Schnittstellen des einen Ports mit allen Schnittstellen des anderen Port verbunden werden. Bieten diese Ports unterschiedliche Schnittstellen an, ist eine Verbindung nicht möglich. Falls zwei Ports mit jeweils gegenseitigen Schnittstellen vom gleichen Typ verbunden werden sollen, reicht die Information, welche zwei Ports von welchen Komponenten verbunden werden. Die entsprechenden verbunden Schnittstellen ergeben sich automatisch. Komponenten können Subkomponenten und Klassen enthalten. Klassen werden als Rechteck mit dem Klassennamen in der Mitte dargestellt. Diese können wie Komponenten auch Schnittstellen exportieren und importieren, allerdings ohne die Gruppierung durch Ports. Abbildung 2.3 zeigt eine Komponente A, welche die Klassen C und D beinhaltet. Beide Klassen realisieren jeweils eine Schnittstelle, und diese soll von Komponente A nach außen angeboten werden. Dies wird in der Grafik durch den delegation connector verdeutlicht, der die beiden Schnittstellen Interface C und Interface D jeweils zu den Klassen C und D weiterleitet. Die Beschränkung, dass jeweils Ports mit allen Schnittstellen auf einmal verbunden werden müssen, muss nur bei Verbindungen zwischen zwei Komponenten beachtet werden, für Klassen wird sie sinnvollerweise nicht beachtet. In der Abbildung wird das Delegieren von importierten Schnittstellen anhand Interface B mit Komponente B verdeutlicht. UML stellt mit den Komponentendiagrammen eine leistungsfähige und übersichtliche Methode bereit, die Interaktion und Zusammenhänge von Komponenten graphisch zu visualisieren. Durch die hohe Verbreitung dieser Notation haben sich auf dem freien Markt mittlerweile schon mehrere leistungsfähige Modellierungsapplikationen etabliert, welche den Entwickler effizient beim Entwurf von größeren Applikationen unterstützen können.

23 2.2 Middleware 9 Applikation <<component>> A <<component>> B <<component>> C Middleware Abbildung 2.4.: Kommunikation zwischen Komponenten mit Hilfe von Middleware 2.2. Middleware Einführung Im Gebiet der Softwareentwicklung wird eine Anwendungsschicht, welche zwischen der Anwendung und niedrigeren Laufzeitfunktionen wie beispielsweise dem Betriebssystem, Netzwerkprotokollstacks oder Hardware sitzt, als Middleware bezeichnet. Dabei stellt sie Zusatzfunktionen neben den reinen Betriebssystemfunktionen für die Anwendung bereit und isoliert die Applikation von komplexen Vorgängen in den niedrigeren Ebenen, wie beispielsweise die fehleranfällige Programmierung von Netzwerkprotokollen. In dieser Arbeit wird der Begriff Middleware für eine Programmschicht bezeichnet, welche die Entwicklung von komponentenbasierten Applikationen erleichtert. Der Teil der Software, welcher die Middleware nutzt, wird als Applikation oder auch als Anwendung bezeichnet. Einzelne Komponenten fordern Dienste von anderen Komponenten an und die Middleware verwaltet deren Verbindung (siehe Abbildung 2.4). Im besten Fall weiß die Applikation nichts davon, dass einzelne Teile auf andere Rechner ausgelagert sind, weil diese transparent über die Middleware Dienste voneinander nutzen und gegenseitig Daten austauschen können. Typen der Kommunikation Eine Möglichkeit der Kategorisierung von Kommunikation zwischen zwei Komponenten ist die Betrachtung des Programmablaufs während des Datenaustauschs. Hierbei kann man zwischen synchroner und asynchroner Kommunikation unterscheiden. Bei synchroner Kommunikation wird eine Anfrage verschickt, und während des Wartens auf Antwort wird die Ausführung des Programms unterbrochen. Nach dem Eintreffen der Antwort wird die Ausführung wieder fortgesetzt. Abbildung 2.5 verdeutlicht die Arbeitsweise anhand eines Funktionsaufrufs, welcher transparent durch Middleware über das Netzwerk übertragen wird: Komponente A wird ausgeführt und ruft Funktion

24 10 Überblick Komponente A Komponente B machedas(a,b) C Abbildung 2.5.: Beispiel für synchrone Kommunikation zwischen Komponenten machedas der Komponente B auf. Über das Netzwerk wird der Aufruf an Komponente B inklusive der Parameter A und B gemeldet. Die Funktion wird auf Komponente B ausgeführt und deren Ergebnis C wird wieder zurück an Komponente A übertragen. Vom Zeitpunkt des Aufrufs von machedas bis zur Rückgabe des Ergebnisses wird die Ausführung in Komponente A angehalten. Asynchrone Kommunikation kann nicht durch einen einfachen Funktionsaufruf gekapselt werden, da die Ausführung auf der Seite der datenverschickenden Komponente nicht angehalten wird. Zum Versenden der Daten wird eine von der Middleware bereitgestellte Methode aufgerufen, welche nach Versand der Daten sofort zurückkehrt und auf keine Antwort wartet. Zum Empfangen von Daten spezifiziert die Applikation meistens eine Rückrufmethode, welche bei Eingang von Daten aufgerufen wird. Arten von Middleware Hurwitz hat 1998 [9] vorhandene Middlewareimplementierungen in verschiedene Arten unterteilt. Nachfolgend werden einige daraus vorgestellt: Asynchroner RPC (Remote Procedure Call) erlaubt, Dienste von Clients anzufordern, ohne auf eine Antwort zu warten. Normalerweise muss der Client die explizite Netzwerkadresse des Servers wissen und eine Punkt-zu-Punkt Verbindung dorthin aufbauen. Message-oriented Middleware (MOM) verwaltet den Austausch von Nachrichten, welche asynchron verschickt und empfangen werden. Üblicherweise besitzt dabei jede Komponente eine Liste an eingegangenen Nachrichten, welche von dieser abgearbeitet wird. Nachrichten können dabei entweder direkt an andere Komponenten verschickt werden, oder die Struktur einer Publish-and-subscribe Middleware nutzen. Dabei wird von der Middleware noch zusätzlich eine Datenbank verwaltet, in der festgehalten wird, welche Komponenten welche Arten von Nachrichten empfangen wollen ( Subscriber ). Falls nun eine Komponente eine Nachricht veröffentlicht ( Publisher ), wird diese von der Middleware an alle Komponenten

25 2.2 Middleware 11 verteilt, welche für die Nachrichtenart registriert sind. Object Request Broker (ORB) ermöglichen Applikationen, Objekte über das Netzwerk zu verschicken. Dabei kann der ORB die Route von jedem Objekt nachverfolgen und routet Anfragen im richtigen Format zu einem spezifischen Objekt. Dabei wird auf Objekte mit Hilfe von Namen zugegriffen, ohne dass die Applikation den Ort des Objektes wissen muss. Synchroner RPC erlaubt einem verteilten Programm, Dienste auf verschiedenen Computern im Netzwerk aufzurufen. Die Entwicklung von Middleware, die synchronen RPC anbietet, erfordert einen hohen Aufwand. Dieser lohnt sich, da der Anwendung eine transparente Schnittstelle angeboten wird, welche sich von der Benutzung von lokalen Schnittstellen innerhalb einer Komponente nicht oder nur wenig unterscheidet. Diese Arbeit wird sich hauptsächlich mit Middleware beschäftigen, welche synchronen RPC und MOM unterstützt Implementierungen In dieser Sektion werden einige Implementierungen von Middleware vorgestellt, welche auf dem freien Markt eingesetzt werden. Java EE Java EE (Java Platform, Enterprise Edition) ist ein Teil der von Sun angebotenen Java Plattform für die Entwicklung von verteilten Applikationen, welche auf Komponenten basieren. Neben Java EE werden noch die Plattformen Java SE (Standard Edition) für autonome Anwendungen und Java ME (Micro Edition) für Anwendungen auf eingebetteten Systemen angeboten. Java EE Anwendungen werden auf einem Applikationsserver ausgeführt, welche die Middleware für Applikationen bereitstellen. Java EE enthält verschiedene API Spezifikationen, welche für Geschäftsanwendungen ausgelegt sind. Beispiele dafür sind JDBC (Datenbankzugriff), RMI (synchroner Nachrichtenaustausch), , JMS (asynchroner Nachrichtenaustausch), Web Services oder eine API für den Zugriff auf XML-Daten. Innerhalb der Java EE Spezifikation sind mehrere Technologien definiert, welche die Entwicklung von komponentenbasierten Anwendungen vereinfachen sollen. EJB (Enterprise Java Beans) sind davon die populärste Technologie: mit Hilfe von EJB entwickelte Komponenten sollten dem Entwickler ersparen, sogenannten Backend-Businesscode wie für Datenbankzugriff, Transaktionsverwaltung oder Sicherheit zu schreiben. Dieses Ziel wurde nie erreicht, da EJBs nicht dynamisch genug konfigurierbar waren für die Anforderungen von den meisten Anwendungen. Dadurch entstanden sehr schwergewichtige Applikationen, da die Middleware mehr Funktionen anbot als von der Anwendung benötigt

26 12 Überblick wurden. Es wird versucht dieses Problem zu lösen, indem die Funktionen von Middleware dynamisch konfigurierbar gemacht werden (siehe [7, 26]), oder durch eine leichtgewichtige Middlewareimplementierung, welche auch als Fassade zwischen schwergewichtiger Middleware und Anwendung agieren kann. Ein Vertreter der leichtgewichtigen Middleware ist das Spring Framework (siehe Abschnitt 3.3). JBoss JBoss ist ein Applikationsserver für Java EE, entwickelt von JBoss Inc. und ist aktuell in der Version 4.0 verfügbar [10]. Er ist als Open-Source-Produkt unter der LG- PL veröffentlicht. Durch die hohe Konformität zum Java EE Standard und der guten Unterstützung der Entwicklermannschaft ist der Applikationsserver sehr populär geworden. JBoss bietet neben den von der Java EE Spezifikation geforderten Diensten noch weitere an. Eine Auswahl davon wird anfolgend aufgelistet: Webcontainer mit Jetty oder Tomcat SQL-Datenbank mit Hsqldb Message Queuing Provider (für MOM) Clustering und Farming JMX (Java Management Extensions) CORBA CORBA (Common Object Request Broker Architecture) wird von der OMG (Object Management Group) entwickelt und stellt eine plattformunabhängige und objektorientierte Middleware dar. Sie definiert APIs, Kommunikationsprotokolle und Informationsmodelle, wobei ein besonderer Fokus die Vereinfachung der Entwicklung verteilter Anwendungen auf unterschiedlichen Plattformen ist. Mittels der Interface Definition Language (IDL) werden Schnittstellen beschrieben, die Objekte nach außen zur Verfügung stellen. CORBA erstellt daraus Wrapper Code, welcher die Schnittstellen auf entsprechende Schnittstellen in einer Zielsprache wie C++ oder Java abbildet. Das CORBA Component Model (CCM) führt komponentenorientierte Programmierung bei CORBA ein und stellt eine Weiterentwicklung von EJBs dar. Darin wird ein Komponentencontainer definiert, in dem Softwarekomponenten registriert werden können, und welcher für diese zusätzliche Dienste wie beispielsweise Notifizierung, Authentifizierung oder Persistenz anbietet. Ein großer Forschungsbereich beschäftigt sich mit der Erweiterung des CORBA Frameworks zur Unterstützung von verteilten Echtzeit- und eingebetteten Softwaresystemen

27 2.2 Middleware 13 (Distributed real-time and embedded software systems, DRE). Eine Führungsrolle bei dieser Forschung besitzt D. Schmidt, welcher die Thematik in verschiedene Richtungen vorantreibt. Die Komplexität von Anwendungen in eingebetteten System nimmt mittlerweile auch so stark zu, dass es nötig wird, modellgetriebene Entwicklung auch in diesem Bereich einzuführen. Schmidt präsentiert in seiner Publikation von 2006 [21] domänenspezifische Modellierungssprachen (Domain-specific modeling languages, DSMLs), welche an eine bestimmte Anwendungsdomäne angepasst sind. Diese werden durch Transformationsengines und Generatoren in Anwendungscode übersetzt. Er resümiert darin, dass für den praktischen und umfassenden Gebrauch von modellbasierter Entwicklung noch einiges an Forschung nötig ist.

28 3. Analyse der verwendeten Middlewareplattformen Einen der wichtigsten Einflüsse beim Design einer plattformunabhängigen Middlewareschicht wie CIML haben die Middlewareplattformen, auf die CIML aufsetzt. Als ersten Schritt werden deswegen die Funktionen der Middlewareplattformen JMX, OSGI und dem Spring Framework analysiert, deren Konfiguration vorgestellt und im anschließenden Abschnitt miteinander verglichen. Für den asynchronen Nachrichtenaustausch wird JMS als externe Middleware benutzt. Diese Technologie wird im letzten Abschnitt untersucht JMX Die Java Management Extensions (JMX) in der aktuellen Version 1.2 sind seit Dezember 2002 verfügbar und wurden im Rahmen des Java Community Prozesses entwickelt (siehe [12]). In der Version 5.0 von Java SE wurde JMX in die Spezifikation aufgenommen und ist seitdem in der Java API verfügbar. Mit Hilfe von JMX ist es möglich, Softwarekomponenten mit externen Werkzeugen auf einheitliche Art zu überwachen und zu verwalten. JMX konzentriert sich auf das Anbieten und Vermitteln von Diensten und stellt dabei nur einen kleinen Teil der Funktionalität von EJBs zur Verfügung. Aber die Entwicklungsfreiheit wird durch die Spezifikation von EJBs stark eingeschränkt, was viele Programmierer zur Verwendung von JMX bewegt hat. Beispielsweise dürfen Komponenten in JMX im Gegensatz zu EJBs Dateien im lokalen Dateisystem lesen und schreiben oder neue Threads starten Aufbau Man kann die JMX Architektur in drei Ebenen unterteilen (siehe Abbildung 3.1): Instrumentation: Ressourcen, so wie Applikationen, Geräte oder Komponenten werden als Managed Beans (MBeans) instrumentiert. MBeans beschreiben ihre Managementschnittstelle, welche sich aus Attributen und Operationen zusammensetzen kann. Eine Anwendung kann beliebig viele MBeans bereitstellen.

29 3.1 JMX 15 JMXConsole Web Browser RMI HTML/HTTP Remote Management Connector Adaptor Ag ent MBeanSer ver Instrumentation MBean A MBean B MBean C Abbildung 3.1.: Systemarchitektur von JMX Agent: Der wichtigste Teil eines JMX Agenten ist der MBean Server. Dieser stellt Dienste zum Verwalten von MBeans bereit, außerdem werden dort MBeans registriert. JMX Agenten steuern Ressourcen und stellen diese für externen Zugriff bereit. Remote Management: Protocol adaptors und standard connectors ermöglichen Zugang zum JMX Agenten für externe Applikationen. Dienste in den Ebenen Agent und Remote Management werden oft von Applikationsservern wie JBoss bereitgestellt, sodass nur die Anwendungsschicht entwickelt werden muss, und alles andere von der Middleware verwaltet wird. Da die zu entwickelnde Middlewareschicht CIML zwischen Applikation und einer Middlewareplattform wie einem JMX Agenten liegt, wird sich diese Arbeit hauptsächlich auf die Interaktion zwischen Instrumentations- und Agentenschicht konzentrieren Managed Beans MBeans beschreiben Schnittstellen für den Zugriff von externen Programmen aus. Sie beziehen sich immer auf eine Java-Klasse, welche Methoden und Attribute besitzt. In der Definition von MBeans wird beschrieben, welche dieser Methoden und Attribute für externe Programme sichtbar und zugreifbar sind. Hierbei gibt es vier verschiedene Arten, diese Beschreibung zu definieren: Standard-MBeans: Alle zu exportierenden Methoden und Attribute einer Klasse MyClass werden im Java-Interface MyClassMBean aufgelistet und in MyClass

30 16 Analyse der verwendeten Middlewareplattformen implementiert. Der MBean Server sucht bei Standard-MBeans nach einem implementierten Java-Interface Klasse MBean. Diese Möglichkeit der MBean-Definition ist vor allem für Klassen geeignet, die eine fest definierte Schnittstelle besitzen und diese bei der Entwicklungszeit schon feststeht. Dynamic-MBeans: Klassen, welche über diese Methode ihre Schnittstelle beschreiben, müssen das Interface javax.management.dynamicmbean implementieren. Durch dieses Interface wird vom MBeanServer die zu exportierenden Methoden und Attribute zur Laufzeit abgefragt. Dadurch kann die exportierte Schnittstelle dynamisch zur Laufzeit den aktuellen Bedingungen angepasst werden. Wegen dieser Flexibilität ist die Programmierung relativ aufwändig und unübersichtlich. Model-MBeans: Diese Art von MBeans ist eine Erweiterung der Dynamic-MBeans. Eine beliebige Klasse kann hierbei ein MBean mit allen angebotenen Methoden und Attributen definieren. Dafür wird eine Struktur mit den exportierten Namen der Elemente und der entsprechenden Klasseninstanz gefüllt, welche die Methoden sowie Referenzen auf die aufzurufenden Methoden implementiert. Diese Methode eignet sich besonders, wenn ein Mittler die Schnittstelle einer Klasse festlegen kann und exportieren will. Open-MBeans: Ebenso wie Model-MBeans setzen Open-MBeans auf Dynamic- MBeans auf. Damit eine größere Auswahl an externen Programmen auf die JMX- Schnittstelle zugreifen kann, begrenzen sich Open-MBeans auf wenige fest spezifizierte Datentypen. JMX ist sehr stark auf Trennung der Komponenten ausgerichtet, sodass diese auf verschiedene Server verteilt werden können. So wird bei Zugriff auf andere Komponenten immer vom MBeanServer ein Dynamic Proxy (für weitere Informationen siehe die Java-API Dokumentation) erstellt, welcher die Schnittstelle der anderen Komponente bereitstellt und die Aufrufe transparent weiterleitet. Diese Methode führt zusätzlichen Overhead beim Aufruf von MBeans ein, welcher vor allem bei lokalen MBeans unnötig wäre. Durch einen ausgeklügelten Mechanismus schränkt JMXs Proxy-Wrapper die Verwendung von Rückrufen (Callbacks) bei MBean Aufrufen nicht ein: ruft beispielsweise ein MBean A das MBean B auf und übergibt als Parameter eine Referenz auf ein Java- Interface von MBean C, werden die dem Interface entsprechenden Methoden in MBean C transparent aufgerufen, falls es von MBean B benutzt wird. MBeans werden innerhalb von einer MBeanServer Instanz mit Hilfe ihres ObjectName identifiziert. Dieser wird bei Erstellung der MBeans definiert. Er muss der Form [Domäne]:Schlüssel=Wert[,Schlüssel=Wert]*

31 3.1 JMX 17 entsprechen. Das Feld Domäne ist optional. Anschließend können beliebig viele Schlüssel und Wertpaare angegeben werden, um das MBean zu benennen JMX in JBoss Nachfolgend wird die Verwendung von JMX in JBoss vorgestellt. Dabei wird speziell auf die Verpackung und Konfiguration von Komponenten und ihrer MBeans eingegangen. Die JMX Spezifikation definiert eine Schnittstelle für den Import und Export von Diensten. Falls eine komponentenbasierte Anwendung eine Verwaltung für den Lebenszyklus von Komponenten und eine Abhängigkeitsverwaltung benötigt, muss ein Applikationsserver wie JBoss eingesetzt werden. Dieser stellt unter anderem Komponentenverwaltung und eine JMX-Schnittstelle bereit. JBoss erwartet, dass die zu verwendenden Komponenten in JAR-Dateien verpackt sind. In diesen Archiven befinden sich die benötigten Klassen und Konfigurationsdateien, welche die Komponenten spezifizieren. Dabei kann ein Archiv mehrere MBeans enthalten, welche automatisch durch JBoss beim Deployment der Komponente gestartet werden. Die Startreihenfolge der Komponenten wird durch die Abhängigkeitsbeziehungen der Komponenten untereinander bestimmt. In der Konfigurationsdatei für JBoss können folgende Angaben pro MBean gemacht werden: ObjectName des MBeans (siehe Abschnitt 3.1.2) Implementierungsklasse (diese sollte sich entweder im Jar-Archiv der entsprechenden Komponente oder im Classpath befinden) Abhängigkeiten von anderen MBeans: Dabei werden ObjectNames von anderen MBeans angegeben. Diese ObjectNames müssen in Konfigurationsdateien von anderen Komponenten angegeben sein und dürfen nicht programmatisch durch die JMX-API erstellt worden sein, da sonst JBoss nicht erkennt dass die Abhängigkeit erfüllt wurde, und die Komponente nicht automatisch gestartet wird. Liste aller zu exportierenden Methoden und Attribute: Dies ist eine Alternative zu den verschiedenen MBean-Klassen, welche im vorigen Abschnitt vorgestellt wurden. Alle MBeans innerhalb einer Komponente können Ereignisse bei Wechsel des Komponentenlebenszykluszustands erhalten. Dafür wird die Methode create in der Implementierungsklasse bei der ersten Erzeugung aufgerufen, nachdem alle Abhängigkeiten erfüllt wurden. Anschließend kann das MBean beliebig oft gestartet oder gestoppt werden, hierbei werden die Methoden start und stop aufgerufen. Bei Herunterfahren des Applikationsservers wird vor Zerstörung des MBeans die Lebenszyklusmethode destroy aufgerufen.

32 18 Analyse der verwendeten Middlewareplattformen 3.2. OSGi Überblick Das OSGi Framework [18] ist eine auf Java basierende Serviceplattform, die seit Oktober 2005 in der Version R4 verfügbar ist. Sie wurde von der gleichnamigen OSGi Alliance entwickelt, welche ein Zusammenschluss von verschiedenen Firmen wie u.a. Sun Microsystems und IBM ist, um einen Industriestandard zu schaffen. Es existieren viele verschiedene Implementierungen der OSGi Spezifikation. In dieser Arbeit wird das Knopflerfish OSGi Framework in der Version 2.0 verwendet [14]. Das OSGi Framework stellt ein dynamisches Komponentenmodell bereit, in dem Komponenten, welche Bundles genannt werden, installiert, gestartet, gestoppt, aktualisiert und deinstalliert werden können, ohne dass das Framework neu gestartet werden muss. Dabei ist es auch möglich, gleichnamige Bundles mit unterschiedlichen Versionen gleichzeitig zu starten. Die Dienstverwaltung ermöglicht es, dass Bundles Dienste bereitstellen oder von anderen Bundles benutzen können. Basierend auf diesen Funktionen wurden weitere Dienste hinzugefügt, so wie unter anderem die Verwaltung von Logs, Konfigurationsmanagement, ein HTTP-Dienst, welcher u.a. Java Servlets ausführen kann oder ein XML Parser. Im Gegensatz zu JMX ist OSGi nicht darauf ausgelegt, von Komponenten angebotene Dienste möglichst transparent geräteübergreifend zur Verfügung zu stellen. Der Schwerpunkt beim OSGi Framework liegt beim Bereitstellen einer standardisierten Umgebung für Anwendungen, die das Starten und Stoppen einer Vielzahl von Diensten auf einem Gerät ermöglicht. Die Java Entwicklungsumgebung Eclipse [3] verwendet beispielsweise für die Verwaltung von Plugins und internen Komponenten eine leicht veränderte Version eines OSGi Frameworks. Ein weiterer Aspekt beim Entwurf der OSGi Spezifikation war, dass Implementierungen im Bereich von eingebetteten Systemen lauffähig sind. Die Spezifikation ist deshalb modular aufgebaut, sodass von Anwendungen unbenötigte Teile spezifikationskonform nicht zwingend in einer OSGi Implementierung bereitgestellt werden müssen Aufbau Abbildung 3.2 zeigt den grundlegenden Aufbau eines OSGi Frameworks: Auf der untersten Ebene befindet sich das Execution environment, welches die Java- Umgebung definiert. Dafür können verschiedene Konfigurationen und Profile verwendet werden wie z.b. Java SE oder Java ME. In der OSGi Spezifikation werden mehrere Execution environments entsprechend der verfügbaren Funktionen und der Hardwareanforderungen definiert. Darauf baut das OSGi Framework auf und setzt sich aus verschiedenen Komponenten zusammen. Die Modules Komponente definiert die Richtlinien für das Laden von

33 3.2 OSGi 19 application layer OSGi layer J2RE layer bundles modules ser vice registr y lifecycle execution environment Abbildung 3.2.: Architekturebenen von OSGi Klassen. Das OSGi Framework fügt zum Standard-Java-Klassenlademodell Modularisierung hinzu. Jedes Modul besitzt die Möglichkeit, einen Classpath zum Auffinden von benötigten Klassen selbst zu definieren. Dabei können private Klassen geladen werden, oder auch Klassen von anderen Bundles. Die Lifecycle Komponente stellt Bundles einen Lebenszyklus zur Verfügung. Dadurch können diese von außen dynamisch installiert, gestartet, gestoppt und wieder deinstalliert werden, ohne dass davon andere Bundles beeinflusst werden oder das OSGi Framework neu gestartet werden müsste. Bestimmte Mechanismen stellen dabei sicher, dass Abhängigkeiten zwischen Bundles beachtet werden, um eine korrekte Funktionsfähigkeit zu gewährleisten. Die Service Registry ermöglicht die Kommunikation und das Austauschen von Objekten zwischen verschiedenen Bundles. Hat ein Bundle Dienste anzubieten, registriert sie die Schnittstelle des Dienstes in der Service Registry. Bundles können mittels Ereignissen überwachen, welche Dienste in der Service Registry registriert und deregistriert werden. Somit ist für sie feststellbar, wann alle benötigten Dienste zur Verfügung stehen und können dann ihre normale Arbeit aufnehmen Komponentenintegration Die OSGi Spezifikation definiert den Aufbau und die Konfiguration von Bundles. Dies sind Jar-Archive, welche die Implementierungsklassen mit zusätzlichen Daten enthält (wie bei Komponenten bei JBoss). Jedes Bundle wird durch eine Manifest-Datei, welche sich unter META-INF/MANIFEST.MF innerhalb des Archivs befindet, konfiguriert. Darin wird unter anderem spezifiziert, welche Java-Packages von anderen Bundles importiert werden. Dies ist für die Verwendung von gemeinsamen Java-Interfaces wichtig, wie bei der Verwendung von gemeinsamen Bibliotheken. Bibliotheken müssen als eigenes Bundle in das Framework aufgenommen werden und dann von den abhängigen Bundles importiert werden. Eine Abhängigkeitsverwaltung für exportierte und importierte Schnittstellen wird im OSGi Framework als zusätzliches Modul bereitgestellt. Dieses wird nicht in dieser Arbeit verwendet.