Masterarbeit Dynamische Softwarekomponentenverwaltung einer Kommunikationsmiddleware

Transkript

1 Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Masterarbeit Dynamische Softwarekomponentenverwaltung einer Kommunikationsmiddleware vorgelegt von: Aalbrecht Alby Irawan eingereicht am: geboren am: Studiengang: Studienrichtung: Ingenieurinformatik Multimediale Informations- und Kommunikationssysteme Anfertigung im Fachgebiet: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Verantwortlicher Professor: Wissenschaftlicher Betreuer: Prof. Dr. rer. nat. Jochen Seitz Dipl.-Ing. Karsten Renhak

2 Kurzfassung Ziel dieser Masterarbeit ist die Entstehung eines Verwaltungssystem zur automatischen individuellen An- und Abmeldung verschiedener Gateways. Die Gateways sollen sich zur Laufzeit dynamisch im System registrieren können, ohne das Gesamtsystem neugestartet werden zu müssen. Demnach gliedert sich die Arbeit in 2 Teile. Erstens in die Recherche über verschiedene Verfahren zum dynamischen Komponentenmodell und die Unterschiede zwischen relationale Datenbankschnittstelle und objektrelationale Datenbankschnittstelle. Zweitens in die Konzeption und Umsetzung eines optimalen dynamischen Software- Verwaltungssystems. Im ersten Teil werden 4 Ansätze recherchiert: CORBA, Jini, EJB, und OSGi. Anhand ausgewählter Kriterien, wie z.b. Plattformunabhänigkeit, Kapselung und Versionierung werden sie anschließend miteinander verglichen. OSGi wird letzendlich gewählt, da OSGi die neueste und optimalste Variante ist. Die Vor- und Nachteile von verschiedenen Datenbankschnitstellen werden auch berücksichtigt. Eine relationale Datenbank ist leichter zu realisieren, aber bei einer objektorientierten Progammierung hat objektrelationale Datenbank einen klaren Vorsprung. Mit Hilfe von einer Objekt Relational Mapping- (ORM)Software, wie z.b. EclipseLink oder Hibernate sei dies kein großes Problem mehr. Im zweiten Teil wird ein Konzept zur Verwaltung verschiedener Kommunkationsgateways erläutert. Hierbei stellt ein zentrales Element der Middleware einerseits eine Schnittstelle zum Assistenzsystem zur Verfügung und andererseits übernimmt dieses Modul die Verwaltung der einzelnen Gateways. Die Kommunikation zwischen der zentralen Schnittstelle und den Kommunikationsgateways soll ausschließlich über die vorhandene Message Oriented Middleware (MOM), in diesem Fall Advanced Message Queuing Protocol (AMQP), erfolgen. Die notwendige Speicherung vorhandener Informationen durch das zentrale Modul soll auf Basis der objektrelationalen Datenbankschnittstelle erfolgen.

3 Abstract Goal of this thesis is the development of a management system for automatic individual registration and deregistration of different gateways. The gateways can register dynamically at runtime without having the entire system to be restarted. Accordingly, the work is divided into 2 parts. First, in the research on various methods for dynamic component models, and the differences between relational database interface and object-relational database interface. Second, in the design and implementation of an optimal dynamic software management system. In the first part 4 approaches are investigated: CORBA, Jini, EJB and OSGi. They are compared based on selected criteria, such as platform independency, encapsulation and versioning. OSGi is ultimately chosen because OSGi is the latest and the most optimal variant. The pros and cons of various database interface are also be considered. A relational database is easier to implement, but in such an object-oriented programming, object-relational database has a clear lead. Using an Object Relational Mapping (ORM) software, e.g. EclipseLink or Hibernate, there shouldn t be any big problem. The second part is an approach to managing various communication gateways. Therefore, a core element of the middleware provides an interface for the assistance system and at the other hand it watches over the individual gateways. The communication between the central interface and the communication gateways is only via the existing Message Oriented Middleware (MOM), in this case Advanced Message Queuing Protocol (AMQP). The required storage of existing information by the central module should be based on the object-relational database interface.

4 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung Motivation Aufgabenstellung Dynamische Verwaltung von Softwarekomponenten CORBA JINI EJB OSGi Vergleich der Ansätze Datenbankschnittstelle Relationales Datenbanksystem Objektrelationales Datenbanksystem Java Datenbank Connectivity Java Persistence Query Language Konzeption eines dynamischen Software-Verwaltungssystems Anforderungen an das Software-Verwaltungssystem Struktur des Verwaltungssystems Umsetzung des Konzepts RabbitMQ EclipseLink Apache Derby OSGi Zusammenfassung/Ausblick Zusammenfassung der Ergebnisse Ausblick auf Erweiterungen

5 Inhaltsverzeichnis ii Literaturverzeichnis 41 Abbildungsverzeichnis 43 Tabellenverzeichnis 44 Abkürzungsverzeichnis und Formelzeichen 45 Thesen zur Masterarbeit 47 Erklärung 48

6 1 Einleitung 1 1 Einleitung 1.1 Motivation Das Fachgebiet Kommunikationsnetze befasst sich mit Infrastrukturen und Anwendungen für Assistenzsysteme zur Unterstützung des täglichen Lebens. Um die Qualität und vor allem die Akzeptanz des Assistenzsystems zu erhöhen, ist es von Vorteil, möglichst viele Nutzungsmöglichkeiten anzubieten. Seit mehr als 20 Jahren haben sich Ingenieure damit beschäftigt, ein monolitisches System mit einem Komponentenmodell zu ersetzen. Im Gegensatz zum monolitischen System bietet ein modulares System viele Nutzungsmöglichkeiten. So ist es leicht, andere Module hinzuzufügen. und entsprechend können alte Module gegen neue Module ausgetauscht werden. Außerdem ist ein bestehendes Modul in einem anderen System wiederverwendbar. Hierdurch können die Entwicklungskosten sinken und schnellere Produktzyklen erreicht werden. Dieses Modell kann allerdings auch zu neuen Problemen führen, vorallem bei der Sicherheit und Kompatibilität. Da die Ressourcen jetzt für alle zugreifbar sind, muss das System gegen Angreifer geschützt sein. Eine Authentifizierung ist erforderlich, sodass kein unauthorisierter Teilnehmer den Zustand des Systems verändern kann. Im Markt finden sich viele verschiedene Realisierungen einer Spezifikation. Oft gibt es Probleme bei der Kommunikation, sodass die Interoperabilität nicht gewährleistet werden kann. Diese Inkompatibilität kann auch innerhalb einer Software gleichen Herstellers vorkommen, z.b. wenn ein Client und ein Server andere Versionen der Software benutzen. Ein anderer Aspekt, der eine große Rolle spielt, ist die Dynamik. Bei früheren Systemen muss das System heruntergefahren und neugestartet werden, wenn sich eine Komponente ändert, denn sonst ist der Name oder die Adresse eines Objekt für die anderen Komponenten unbekannt. Erst nach dem Neustart wird eine Zusammenarbeit ermöglicht. Deshalb soll das Verwaltungssystem in dieser Masterarbeit die dynamische An- und Abmeldung einer Komponente unterstützen. Eine Datenbank ist eine Sammlung von Informationen wie z.b. Texte, Zahlen und Bilder. Sie ist so organisiert, dass sie leicht zugänglich und zuzuordnen ist. Eine Da-

7 1 Einleitung 2 tenbank kann nach ihrem organisatorischen Ansatz eingestuft werden. Der häufigste Ansatz ist die relationale Datenbank, auch tabellarische Datenbank genannt. Sie wird durch ihre Attribute (Spalten) und ihre Tupel (Zeilen) charakterisiert. Eine objektrelationale Datenbank hingegen wird mit den Daten der Objekte in Klassen und Unterklassen definiert. Eine relationale Datenbank ist sehr leicht zu realisieren, aber bei objektorientierter Programmierung ist sie kaum nutzbar. Im Gegensatz dazu ist eine objektrelationale Datenbank relativ schwierig zu realisieren, aber sie wurde genau für objektorientierte Programmierung entwickelt. Deshalb soll man eine Schnittstelle anwenden, welche die Zuordnung und die Übertragung von Daten der Objekte zu einer tabellarischen Datenbank ermöglicht, sogenannte Object-Relational-Mapping (ORM)-Software. 1.2 Aufgabenstellung Eine am Fachgebiet Kommunikationsnetze entwickelte Kommunikationsmiddleware für Assistenzsysteme wird eingesetzt, um möglichst viele verschiedene Kommunikationsarten und -technologien mit dem Assistenzsystem zu nutzen. Diese Kommunikationsmiddleware verwendet unter anderem eine nachrichtenbasierte Middleware (Message Oriented Middleware - MOM) zur internen Kommunikation. Die Anbindung der verschiedenen Kommunikationssysteme erfolgt durch unabhängige Gateways, die über eine MOM mit der Kommunikationsschnittstelle des Assistenzsystems verbunden sind. Im Rahmen der Erweiterung und Pflege der Kommunikationsmiddleware soll ein Verwaltungssystem zur automatischen individuellen An- und Abmeldung der Gateways entstehen. Um dieses Ziel zu realisieren, sind folgende Arbeitsschritte erforderlich: Recherche zu Verfahren und Ansätzen zur dynamischen Verwaltung von Softwarekomponenten Recherche zu objektrelationalen Java-Datenbankschnittstellen Konzeption und Umsetzung eines dynamischen Software-Verwaltungssystems Abbildung 1.1 stellt eine mögliche Realisierung eines solchen Verwaltungssystems dar. Hierbei stellt ein zentrales Element der Middleware einerseits eine Schnittstelle zum Assistenzsystem zur Verfügung. Und andererseits übernimmt dieses Modul die Verwaltung der einzelnen Gateways. Die Kommunikation zwischen der zentralen Schnittstelle

8 1 Einleitung 3 Abbildung 1.1: Beispiel für Realisierung eines Verwaltungssystems und den Kommunikationsgateways soll ausschließlich über einen AMQP-Server erfolgen. Die Verwaltung des Gateways ist weiterhin auf Basis der übermittelten Metadaten in XML-Format umzusetzen. Die Speicherung vorhandener Informationen durch das zentrale Modul soll auf Basis einer objektrelationalen Datenbankschnittstelle erfolgen.

9 2 Dynamische Verwaltung von Softwarekomponenten 4 2 Dynamische Verwaltung von Softwarekomponenten Dieses Kapitel befasst sich mit verschiedenen Ansätzen, welche die dynamische Verwaltung von Softwarekomponenten ermöglichen sollen. Die Ansätze werden nach nach Erscheinungsjahr aufgelistet. 2.1 CORBA Common Object Request Broker Architecture (CORBA) ist eine Spezifikation, die 1991 zum ersten Mal von der Object Management Group (OMG) verabschiedet wurde. Federführend bei der Entwicklung dieses Standards sind die Unternehmen Sun und IBM [Lan02]. Weil CORBA nur eine Spezifikation ist, gibt es im Markt viele herstellerabhängige Anwendungen, die CORBA implementieren. Dennoch soll mittels Interface Definition Language (IDL) Interoperabilität und Sprachunabhängigkeit gewährleistet werden. Anders als herkömmliche Programmiersprachen wie C, COBOL, Python, C++ oder Java ist die IDL eine reine Spezifikationssprache. Ein mit der CORBA-IDL erzeugtes Interface wird in einem normalen Text-File abgespeichert und muss in die jeweils verwendete Programmiersprache übersetzt werden. Diese Übersetzung wird von den IDL-Compilern im ORB übernommen. Da dieser Compiler und dessen Übersetzung standardisiert ist, sollen Clients und Server verschiedener Hersteller problemlos kommunizieren können, solange keine herstellerspezifische Erweiterungen installiert werden. Grundlage für die Spezifikation ist die sogenannte Object Management Architecture (OMA), die aus fünf Komponenten besteht: Object Request Broker (ORB) Common Object Service (COS) Common Facilities

10 2 Dynamische Verwaltung von Softwarekomponenten 5 Domain Objects Application Objects ORB steht im Zentrum. Dieser funktioniert als ein Broker, der Kommunikation und Interaktion von verschiedenen und entfernten Objekten verbindet. Der IDL Compiler im ORB erzeugt ein Server-Skeleton und einen Clienten-Stub. Diese fungieren als Proxy des Clients bzw. Servers. Wenn ein Client eine Server-Methode aufruft, übernimmt der Stub das Verpacken der Parameter und gibt den Aufruf an den ORB weiter. Dieser ist dafür zuständig, das Server-Objekt zu lokalisieren und den Aufruf weiterzuleiten. Die Rückgabe des Ergebnisses geschieht in umgekehrter Richtung analog. Da nur Parameter (input und output) benötigt werden, bleibt das Objekt vor der Außenwelt versteckt. Dieser Ablauf wird in Abbildung 2.1 veranschaulicht. Abbildung 2.1: Methodenaufruf bei CORBA [Haa01] CORBA ermöglicht auch dynamische Methodenaufrufe. Während bei einem statischen Aufruf der Client die Schnittstellendefinition des Servers kennen muss, können mit Hilfe des Dynamic Invocation Interface (DII) Aufrufe zur Laufzeit konstruiert werden. Analog dazu können auf der Server-Seite über das Dynamic Skeleton Interface (DSI) beliebige Aufrufe ohne Kenntnis der Schnittstellenbeschreibung entgegengenommen werden [Haa01]. Der ORB beinhaltet auch ein Implementation Repository. In dieser Datenbank wird gespeichert, welcher Server welche CORBA-Objekte beinhaltet und wie ein Server bei Bedarf zu starten ist. Auf diese Weise kann CORBA einen automatischen Aktivierungsmechanismus bieten. Wenn ein Client nach einem bestimmten CORBA-Objekt verlangt, das derzeit von keinem Server angeboten wird, kann der ORB im Implementation Repository nach einem passenden Server-Programm suchen und dessen Ablageort und Konfigurationsdaten ermitteln, um ihn anschließend zu starten [GT00].

11 2 Dynamische Verwaltung von Softwarekomponenten 6 Common Object Services bieten Dienste an, die benötigt werden, um Objekte und Daten zu finden und zu verwalten. Einige wichtige COS sind etwa Naming Service, Trading Service, Persistent Object Service und Event Service. Der Naming Service verknüpft einen abstrakten Namen zu einem Objekt. Der Client muss dann nur den entsprechenden Namen eingeben, um das Objekt zu erreichen. In diesem Fall fungiert der Naming Service als eine Datenbank. Ein Objekt kann nicht nur einen Namen haben, sondern auch Eigeschaften. Der Trading Service wird benutzt, um ein Objekt zur Laufzeit zu finden. Im Gegensatz zum Naming Service werden Objekte nicht durch ihre Namen identifiziert, sondern durch den Vergleich von Eigenschaften. Nach dem Vergleich können mehrere Objekte gefunden werden. Mit dem Persistent Object Service wird eine vordefinierte Schnittstelle ermöglicht, um Persistenz für CORBA-Objekte auf verschiedenen Systemen zu gewährleisten. Der Event Service ermöglicht asynchrone Kommunikation mittels Ereignismeldungen. Dabei wird zwischen Objekten unterschieden: Supplier und Consumer. Supplier erzeugen Ereignismeldungen und versenden sie an Consumer. Ein Consumer empfängt die Ereignismeldungen und verarbeitet sie weiter. Dabei werden das Push-Modell und das Pull-Modell unterstützt. Common Facilities bieten Dienste an, die auf den COS aufbauen und in ihrer Funktionalität über sie hinausgehen. Die Dienste der Common Facilities sind weniger allgemein als die COS, aber sie erledigen noch komplexere Aufgaben. Die Comon Facilities sind in die folgende Bereiche untergliedert: Information Management Benutzerschnittstellen Systemmanagement Taskmanagement Domain Objects stellen die nächste Abstraktionsstufe nach den COS und den Common Facilities dar. Sie sind auf einen bestimmten Anwendungsbereich zugeschnitten, etwa Telekommunikation, Bankwesen oder Medizin. Application Objects stellen die eigentlichen verteilten Applikationen dar. Sie kommunizieren miteinander und mit den anderen OMA-Komponenten über den ORB. Für ihre Realisierung verwenden sie die COS, die Common Facilities sowie die Domain Objects. Die Application Objects selbst sind nicht Teil der Standardisierung.

12 2 Dynamische Verwaltung von Softwarekomponenten 7 Die 5 Komponenten der OMA und ihre Beziehungen zueinander sind in Abbildung 2.2 graphisch dargestellt. Abbildung 2.2: Object Management Architecture der OMG [Haa01] Trotz der IDL könnte es noch Probleme mit der Interoperabilität geben. Einfachstes Beispiel ist der Einsatz von VisiBroker als ORB. Wenn ein CORBA-Programm diesen Broker als Kommunikationsplattform einsetzt, müssen die Bibliotheken von VisiBroker sowohl client- als auch serverseitig eingebunden werden. Eine Zusammenarbeit mit einem anderen Broker ist nicht garantiert [Lan02]. Konkurrenz erhält CORBA vor allem von Microsoft mit seiner.net-plattform. Die.NET-Plattform verwendet das Simple Object Access Protocol (SOAP), das entfernte Methodenaufrufe auf der Basis von extensible Markup Language (XML) realisiert. Außerdem kann es mit dem Protokoll Hyper Text Transfer Protocol (HTTP) arbeiten, das die Einsetzbarkeit noch weiter steigert. Im Allgemeinen ist zu empfehlen, CORBA nur zu verwenden, wenn die Komponenten mit unterschiedlichen Programmiersprachen entwickelt werden sollen. Es ist jedoch anzunehmen, dass Großunternehmen, die bereits CORBA einsetzen, nicht von dieser Technologie abweichen werden. Besonders in den Bereichen der Banken, Versicherungen und Luftfahrten werden diese Systeme schon seit sehr langer Zeit eingesetzt und haben sich entsprechend bewährt. CORBA erfordert eine enormes Know-how der Mitarbeiter. Erst ab ca. 20 Mitarbeitern lassen sich große Projekte entsprechend bewältigen. Deshalb sollte bei der Weiterentwicklung von CORBA das Ziel sein, die Komplexität des Projektes zu reduzieren [Lan02]. Im Zuge der Weiterentwicklung verabschiedete OMG auch noch CORBA 2 und

13 2 Dynamische Verwaltung von Softwarekomponenten 8 CORBA 3. In CORBA 2 wird der GIOP und IIOP dazu addiert und in CORBA 3 die Interoperabilität mit den anderen Komponentenmodellen. General Inter ORB Protocol (GIOP) ist ein Protokoll, mit dem ORB miteinander kommunizieren. Internet Inter ORB Protocol (IIOP) ist die Umsetzung der GIOP über TCP/IP. Da IIOP nicht immer Port 80 [IAN12] wie bei XML/SOAP verwendet, kann es Probleme mit einer sehr strengen Firewall geben. Unter findet man die genauere Spezifikation von CORBA 2 und CORBA JINI Jini ist eine Service-orientierte Architektur, die Java-Technologie erweitert, um sichere und verteilte Systeme aufzubauen. Diese Systeme bestehen aus Föderationen von Diensten und Clients. Jini wurde 1999 von Sun Microsystems verabschiedet. Ab 2007 wurde das Projekt Jini von Apache übernommen und in Apache River umbenannt. Jini unterstützt nur Java-Systeme und bestimmte Plattformen wie Solaris, Ubuntu und Windows. Jini hat den Ansatz, die automatische Vermittlung zwischen Client und Server zu ermöglichen. Die Firma Sun, die Jini entwickelt hat, nennt diese Eigenschaft Spontaneous Networking [Haa01]. Jini besteht aus 3 Komponenten: Client Server Lookup Service Der Lookup Service ermöglicht einem Client, die verfügbaren Dienste in verteilten Systemen zu finden. Die Dienste können sofort benutzt werden, ohne das System neu zu starten. Lookup Service arbeitet ähnlich wie CORBA Naming oder Trading Services. Auf diese Art können Client bzw. Server auch in dynamisch konfigurierten Netzen den Lookup Service finden. Eine übliche Realisierung ist, bestimme Dienste auf reservierten TCP- oder UDP- Ports zu hören. Ein Client muss dann aber immer noch die IP-Adresse oder den logischen Rechnernamen des Server-Rechners kennen, um den Dienst zu adressieren. Wenn dies nicht der Fall ist, verwendet Jini IP-Multicast zwischen und So gibt es für jede aktive Jini-Föderation einen Registrierbaum, der sich potenziell über das gesamte Internet erstreckt [Haa01].

14 2 Dynamische Verwaltung von Softwarekomponenten 9 Wenn ein Jini Lookup Service gestartet wird, gibt dieser seine Anwesenheit durch ein Announcement auf eine Multicast-Adresse. z.b bekannt. Somit erfahren Clients und Dienste von der Existenz eines neuen Lookup Service. Dann trägt sich der Lookup Services in die Multicast-Gruppe ein. Alle Clients und Dienste melden sich auf der Adresse , wenn sie den Lookup Service finden möchten. Dieser Vorgang wird Lookup-Discovery genannt. Die angesprochenen Lookup Services antworten, in dem sie einen Java Proxy zurückschicken. Der Client bzw. Dienst kann den Proxy verwenden, um Anfragen an den Lookup Service zu stellen. Dienste in Jini stehen nicht unbedingt dauerhaft zur Verfügung, deshalb wurde das Leasing eingeführt. Wenn ein Jini-Dienst einen oder mehrere passende Lookup Services gefunden hat, kann er sich bei ihnen anmelden. Dazu hinterlegt er seinen eigenen Proxy und ggf. benutzerdefinierte Attribute. Im Gegenzug erhält der Dienst ein Lease. Leases müssen regelmäßig erneuert werden, so kann festgestellt werden, ob ein Dienst noch existiert ist oder nicht. Wenn keine Erneuerung des Leases innerhalb einer Zeitspanne erfolgt, wird der Dienst aus dem Lookup Service gelöscht. Ein Client nutzt den Lookup Service, um nach passenden Diensten zu suchen. Dazu sendet er den Typ des gesuchten Dienstes und die Werte der Attribute. Falls der Lookup Service über einen passenden Dienst verfügt, schickt er dessen Proxy zum Client. Der Client kann dann auf diesem Proxy arbeitet. So als wäre der Dienst lokal verfügbar. Abbildung 2.3: Ablauf der Jini-Anfrage [New12]

15 2 Dynamische Verwaltung von Softwarekomponenten 10 Zum Starten des Lookup Services muss auch ein HTTP-Server gestartet werden. Wenn Dienste ihre Proxy senden, ist der erste Teil der Datenstroms ein Uniform Resource Locator (URL). Diese URL gibt bekannt, wo die benötigte JAR heruntergeladen werden kann. Oft geht diese URL zurück bis zu einem bestimmten HTTP-Server. Um zu kommunizieren, wird kein Standard vorausgesetzt. Früher wurde Java RMI verwendet. Aber ab Jini 2.0 wird ein Protokoll namens Jini Extensible Remote Invocation (Jeri) vorgeschlagen. Jeri ist eine neue Implementierung des RMI-Modells und gewährt noch höhere Sicherheit [Art12]. Der Client unterscheidet nicht, ob Jeri, RMI oder IIOP verwendet werden solange das Protokoll mit der Semantik der Schnittstelle übereinstimmt. Ein Verbund von Clients, Diensten, einem oder mehreren Lookup Services wird Djinn oder Federation genannt. Obwohl sich Jini selbst nicht erfolgreich durchgesetzt hat, wird sein Ansatz in JavaSpace verwendet. JavaSpace ist ein Verbund von Jini- Diensten, die Java-Objekte speichern und als eine geschlossene Einheit zusammen arbeiten. JavaSpaces ist sehr einfach und besteht aus 7 Methoden. Vier von denen sind: schreiben Ein Objekt wird in JavaSpace geschrieben. lesen Ein Objekt wird aus JavaSpace gelesen. Dies liefert eine Kopie und hinterlässt eine Kopie in JavaSpace nehmen Ein Objekt wird aus JavaSpace genommen. Dies liefert eine Kopie und entfert das Objekt aus JavaSpace notifizieren Lookup Service wird benachrichtigt, wenn Änderungen in JavaSpace festgestellt. Anfangs war Jini Konkurrenz für CORBA und DCOM. Distributed Component Object Model (DCOM) ist eine frühere Microsoft-Spezifikation, die schon absorbiert und abgeschafft wurde zugunsten der.net-technologie. Auch innerhalb der Java- Gesellschaft konnte sich Jini nicht gegen Enterprise Java Beans (EJB) durchsetzen. Jini läuft in Java Standard Edition (Java SE), denn es wird eine Java Virtual Machine (JVM) gebraucht, um die nötigen Operationen durchzuführen. Somit ist Jini für Kleingeräte mit beschränkten Ressourcen nicht geeignet. Außerdem gibt es zurzeit kaum Dokumentation und Tutorials für Jini. Seit der Übergabe an Apache ist die Seite die als Bezugpunkt für Einsteiger dienen sollte, nicht mehr verfügbar.

16 2 Dynamische Verwaltung von Softwarekomponenten EJB Enterprise Java Beans (EJB) wurde im Jahr 2001 von Sun Microsystems verabschiedet. EJB kann leicht mit JavaBeans verwechselt werden, aber EJB ist völlig unabhängig von JavaBeans. EJB-Technologie ist die serverseitige Komponente der Architektur für Java Enterprise Edition (Java EE). EJB ermöglicht die schnelle und vereinfachte Entwicklung verteilter Anwendungen. JavaBeans hingegen ist eine Schnittstellen-Spezifikation für wiederverwendbarer Komponenten in Java. Sie definiert die Java-Komponenten und wie sie zusammen arbeiten sollen. Bei JavaBeans handelt es sich um einen Verbund von mehreren Java-Objekten, genannt Beans. Ein Java-Entwickler, der eine Funktion oder ein Objekt braucht, muss dann nicht selbst alles schreiben. Er kann den entsprechende Bean herunterladen und einsetzen. Mit EJB soll die Entwicklung von verteilten, komponentenbasierten Java-Anwendungen vereinfacht werden. EJB sorgt zudem für eine Komplexitätsreduktion: Die Ansteuerung von Mechanismen wie Verteilung, Sicherheit und Transaktionsverwaltung muss in anderen Umgebungen oft vom Entwickler explizit ausprogrammiert werden, was aufwendig und fehleranfällig ist. EJB verlagert diese Komplexität in die EJB-Server bzw. EJB-Container, so dass sich der Komponentenentwickler auf die eigentlichen fachlichen Anforderungen, also auf die Business-Logik konzentrieren kann [GT00]. EJB besteht aus 4 Teilen: Client-Anwendungen EJB-Server EJB-Container EJB-Komponenten Die Grundstruktur entscpricht einer Drei-Schicht-Anwendung aus einer Präsentations-, einer Geschäftslogik- und einer Datenebene. In einer typischen Geschäftsanwendung verwendet man für die Datenebene eine Datenbank und für die Präsentationsebene entweder GUI-Front-End oder einen Webserver. Die Geschäftslogikebene ist normalerweise am schwierigsten zu entwerfen. Man muss herausfinden, wie der eigene Code mit der Datenbank und mit Clients zusammenarbeiten wird. Wie mit den Clients interagiert wird, entscheidet häufig darüber, wie man mit der Datenbank interagiert [Wut02]. Abbildung 2.4 veranschaulicht den Aufbau der EJB-Architektur.

17 2 Dynamische Verwaltung von Softwarekomponenten 12 Abbildung 2.4: EJB-Architektur [Int12] Viele Entwickler stellen sich unter einem Container eine Datenstruktur wie ein Array, eine verkettete Liste oder einen Vektor vor. In Java EE ist ein Container jedoch fast wie ein Mini-Server. Er stellt die Laufzeitunterstützung für die Elemente bereit, die er enthält. Ein EJB-Container enthält EJB-Komponenten und sorgt für die Bildung eines Verbindungspools und die Transaktionsverarbeitung. Ein Server kann mehrere Container haben. Und die Objekte in den einzelnen Container sind voneinander isoliert, obwohl Objekte in einem Container mit Objekten in einem anderen Container kommunizieren können. Der Unterschied zwischen einer Komponente und einem Objekt ist nicht immer klar. Aber i.a. ist eine Komponente ein Software-Modul, das so entworfen ist, dass man es in vielen Anwendungen verwenden kann, ohne es zu verändern. Ein Objekt kann zwar eine Komponente sein, aber normalerweise stellt man sich unter Komponenten etwas Größeres als Objekte vor. EJB sind verteilte Objekte und daher eher Komponenten als Objekte. Und tatsächlich ist eine EJB nicht als einzelnes Objekt, sondern als Gruppe von Objekten definiert. [Wut02] EJB-Container enthalten drei Typen von Beans: Session Beans Message Driven Beans Entity Beans Session Beans führen die Anwendungslogik im Auftrag des Kunden. Sie wird nicht

18 2 Dynamische Verwaltung von Softwarekomponenten 13 in der Datenbank gespeichert, kann dennoch auf die Datenbank zugreifen. Session Beans sind relativ kurzlebig, meist nur innerhalb einer Client-Sitzung. Man unterscheidet stateful und stateless Session Beans. Eine stateful Session Bean kann Daten speichern für die spätere Wiederverwendung. Ein EJB-Container kann mehrere stateful Session Beans enthalten, deshalb wird an jede einzelne Session Bean eine eindeutige ID vergeben. Im Gegensatz dazu können stateless Session Beans keine Daten speichern. Sie werden daher von anderen stateless Session Beans nicht unterschieden und haben keine eindeutige ID. Message Driven Beans sind für asynchrone Kommunikation gedacht. Sie führen die Anwendungslogik nach Erhalt einer Nachricht vom Kunden. Hierzu wird Java Message Service (JMS) verwendet. Message Driven Beans sind auch relativ kurzlebig. Wenn das System währen der Sitzung abstürtzt, muss eine neue Bean etabliert werden. Entity Beans stellen eine persistente Entität dar. Sie werden häufig in einer relationalen Datenbank gespeichert. Sie haben eine eher lange Lebensdauer und sind nicht auf die Dauer einer Client-Sitzung beschränkt. Anders als Session Beans können mehrere Clients gleichzeitig auf dieselbe Entity Bean zugreifen. Seit EJB 3.0 sind Entity Beans obsolet und werden nicht mehr gebraucht. Sie werden von Java Persistence API ersetzt. Eine Komponente, die in EJB 3.0 geschrieben wurde, ist kompatibel mit einer Komponente, die in EJB 2.1 oder in früherer Version geschrieben wurde. Solche Komponenten- Kombination von verschiedenen Versionen der EJB kann die Migration von bestehenden Anwendungen erleichtern. Außerdem ermöglicht sie die Wiederverwendung von Komponenten aus früheren EJB-Spezifikationen. 2.4 OSGi Open Service Gateway Initiative (OSGi) Framework ist ein modularisches System und eine Service-Plattform, die ein dynamisches Komponentenmodell implementiert. Installation, Start, Stopp und Deinstallation erfolgen über das Netzwerk und benötigen keinen Neustart des Gesamtsystems. Außerdem ermöglicht OSGi auch eine Versionierung, d.h. Komponenten können zur Laufzeit auf eine neuere Version upgegradet werden. OSGi ist nicht sprachunabhängig, nur Java wird hier unterstützt. OSGi wurde von der OSGi-Allianz verabschiedet, die 1999 gegründet wurde. Die OSGi-Allianz besteht aus vielen bekannten Großunternehmen im Bereich Service- und Content-Anbieter, Infrastruktur- und Netzbetreiber sowie Software-Entwicklung. Dazu gehören z.b. Adobe Systems, Oracle, IBM, Deutsche Telekom, Mitsubishi Electric

19 2 Dynamische Verwaltung von Softwarekomponenten 14 und NTT [OSG12a]. Durch so ein großes Konsortium ist es kein Wunder, dass die Entwicklung von OSGi anderen Ansätzen überlegen ist. Die aktuellste Version der OSGi-Framework ist Version 5 (Juni 2012). Diese Masterarbeit befasst sich jedoch nur mit der OSGi Version 4.2, die im Juni 2009 verabschiedet wurde. Abbildung 2.5 veranschaulicht die OSGi-Architektur. Abbildung 2.5: OSGi-Architektur[OSG12b] Bundles Bundles sind die OSGi-Komponenten, die von den Entwicklern erstellt werden. Service-Schicht Die Service-Schicht verbindet Bundles in einer dynamischen Art und Weise. Life-Cycle-Schicht Hier wird die Installation, Starten, Stoppen, Update und Deinstallation von Bundles ermöglicht. Module-Schicht Die Module-Schicht definiert wie Bundles Codes importieren und exportieren können. Security-Schicht Sie behandelt Sicherheitsaspekte und die digitale Signatur.

20 2 Dynamische Verwaltung von Softwarekomponenten 15 Execution Environment Bundles, die nur in einer bestimmten Ausführungsumgebung wie JavaSE-1.6 oder J2SE-1.5 lauffähig sind, müssen dies in der Execution Environment Schicht angeben. In OSGi werden Softwarekomponenten als Bundles bezeichnet. Ein Bundle ist eine Menge von Java-Klassen und anderen Ressourcen, verpackt in ein Java-Archiv (JAR) mit zusätzlichen Header-Informationen (Manifest). Informationen über das Bundle, wie z.b. Name, Version und Abhängigkeit (Dependencies) werden in der Manifest- Datei gespeichert. Alles, was nicht explizit exportiert wird, bleibt im Bundle versteckt. Anders als bei OSGi ist im Standard-Java der gesamte Inhalt einer JAR-Datei für alle sichtbar. Analog zum Export muss ein Bundle die Teile, die es aus einem anderen Bundle nutzen will, explizit importieren. Die Lebenszyklusschicht in der OSGi-Framework ermoglicht die Installation, Starten, Stoppen, Update und Deinstallation von Bundles, unabhängig von der Lebensdauer der JVM. Sie sorgt auch dafür, dass Pakete nur gestartet werden, wenn alle ihre Abhängigkeiten aufgelöst wurden. Dadurch sinkt das Auftreten von der ClassNotFoundException-Ausnahme zur Laufzeit. Falls sich ungelöste Abhängigkeiten ergeben, wird das Bundle nicht gestartet und eine Problemmeldung wird erstellt. Jedes Bundle kann eine Bundle-Activator-Klasse haben, die im MANIFEST.MF als solche gekennzeichnet ist. Ein Bundle-Activator muss über einen öffentlichen Konstruktor ohne Parameter, zum Erzeugen eines Objektes durch Class.newInstance() verfügen. Für jedes auf einer OSGi-Plattform installierte Bundle gibt es ein assoziiertes Bundle- Objekt über das der Lebenszyklus des Bundles direkt gesteuert werden kann. Ein Bundle kann sich in sechs verschiedenen Zuständen befinden [WBB10]: INSTALLED Das Bundle wurde erfolgreich auf der OSGi-Plattform installiert. RESOLVED Alle Java-Klassen, die das Bundle benötigt, sind verfügbar. Das Bundle ist bereit, gestartet zu werden oder wurde gerade gestoppt. STARTING Das Bundle wird über den Aufruf der Start-Methode des BundleActivators gestartet. Die Methode ist noch nicht beendet. Oder die Methode ist beendet, aber das Bundle wird erst aktiv, wenn es von anderen Bundles benötigt wird. ACTIVE Das Bundle läuft. Die Start-Methode wurde erfolgreich beendet. STOPPING Die BundleActivator. Stopp-Methode wurde zum Stoppen des Bundles aufgerufen, aber noch nicht beendet. UNINSTALLED Das Bundle wurde deinstalliert.