Migration von Web Services

Transkript

1 Diplomarbeit in Computer-Networking Migration von Web Services Referent: Koreferent: Prof. Dr. Christoph Reich Prof. Dr. Bernhard Hollunder vorgelegt am: 1. Oktober 2007 vorgelegt von: Manuel Mayer Schramberger Straße 15, Schiltach

2

3 Abstract I Abstract Die Zahl an Web Services ist in den letzten Jahren erheblich gestiegen - und damit auch der anfallende Verwaltungsaufwand. Um möglichst produktiv zu sein ist es notwendig, dass Web Services in einem Netz aus Applikationsservern möglichst gleichmäßig verteilt werden. Diese Diplomarbeit beschreibt eine Architektur, in der Web Services zwischen Applikationsservern transferiert werden können, ohne dass dabei Klientenanfragen und die Zustände bzw. Sitzungsdaten der Web Services verloren gehen. I

4 II Inhaltsverzeichnis Inhaltsverzeichnis Abstract...I Inhaltsverzeichnis...II Abbildungsverzeichnis...IV Tabellenverzeichnis...V Quellcodeverzeichnis...VI Abkürzungsverzeichnis...VII Kapitel 1: Einleitung Problemstellung Vorgehensweise...9 Kapitel 2: Konzepte Migration Merging Lastkontrolle Zusammenfassung...17 Kapitel 3: Umgebung Java Enterprise Edition Java Deployment API (JSR-88) Java Management API (JSR-77, JSR-3, JSR-160) Java Persistence API (JSR-220) Apache Geronimo GBean-Architektur Plugins Zusammenfassung...30 Kapitel 4: Web Service Standards Web Services Addressing (WS-Addressing) Web Service Resource Framework (WSRF) Web Services Notification (WSN) Zusammenfassung...42 Kapitel 5: Serverapplikationen Eigenschaften Statische Webapplikationen Servlets...47 II

5 Inhaltsverzeichnis III 5.4 WS-Resources JPA Entities Datenbanken Legacy-Systeme Zusammenfassung...58 Kapitel 6: Stateful Web Services Der CounterService Implementierung mit JAX-WS und JPA Implementierung mit Apache Muse Zusammenfassung...69 Kapitel 7: Architektur Anforderungen Dispatcher Merger Deployer Gesamtarchitektur Autonomie Zusammenfassung...78 Kapitel 8: Servicemodul Dispatching mit einem HttpServlet Dispatcher- und MergerGBean Ablauf einer Migration Zusammenfassung...86 Kapitel 9: Grafische Benutzeroberfläche Anforderungen Aufbau Features Zusammenfassung...92 Kapitel 10: Messungen Testaufbau JSR-88 vs Plugin Deployment Zurückstellung von Klientenanfragen Merging von WS-Resources Zusammenfassung...97 Kapitel 11: Resümee Fazit Ausblick...99 Literaturverzeichnis Anhang III

6 IV Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 2.1: Migration einer Serverapplikation...11 Abbildung 2.2: Merging...13 Abbildung 2.3: Weiche Migration einer Serverapplikation...14 Abbildung 2.4: Lastkontrolle durch Migration...15 Abbildung 3.1: Deployment nach JSR Abbildung 3.2: Geronimo-Architektur...24 Abbildung 3.3: Plugin-Konzept von Apache Geronimo...27 Abbildung 4.1: WS-Resources...33 Abbildung 4.2: WS-Resource Factory Pattern...38 Abbildung 4.3: Web Services Notification (WSN)...39 Abbildung 5.1: Stateless Service vs Stateful Service...42 Abbildung 5.2: statisch & dynamisch...43 Abbildung 5.3: Beispiel für Abhängigkeiten in einer Java EE Applikation...44 Abbildung 5.4: Migration einer statischen Webanwendung...45 Abbildung 5.5: Get- bzw. SetResourceProperties-Methode...48 Abbildung 5.6: PutResourcePropertyDocument-Methode...48 Abbildung 5.7: Benutzung einer ServiceGroup...50 Abbildung 5.8: Verwaltung von Referenzen auf WS-Resources mit WS-Notification...51 Abbildung 5.9: Migration bei der Verwendung einer Resource Factory...52 Abbildung 5.10: Entity Lifecycle...52 Abbildung 5.11: Distributed Persistence Layer...54 Abbildung 6.1: Aufruf des CounterService...56 Abbildung 6.2: CounterService mit JAX-WS und JPA...57 Abbildung 6.3: Übertragung einer CounterEntity...61 Abbildung 6.4: Apache Muse Programming Model...62 Abbildung 7.1: Der Dispatcher als Vermittlungsstelle...68 Abbildung 7.2: Der Merger als Migrationsauslöser...71 Abbildung 7.3: Der Deployer...72 Abbildung 7.4: Gesamtarchitektur...73 Abbildung 8.1: Funktionsweise des Dispatchers...77 Abbildung 8.2: Ablaufplan...78 Abbildung 8.3: MergeActionBuilder...80 Abbildung 9.1: MergeUI-Aufbau...85 Abbildung 9.2: MergeUI-Screenshot...86 Abbildung 10.1: Testaufbau...89 Abbildung 10.2: JSR-88 vs Plugin Deployment...90 Abbildung 10.3: Apache Tomcat Monitoring mit Apache JMeter...91 Abbildung 10.4: Migration von WS-Resources...92 IV

7 Tabellenverzeichnis V Tabellenverzeichnis Tabelle 5.1: Scope-Objekte der Servlet API...48 Tabelle 5.2: Vergleich von Verfahren zur Verwaltung von WS-Resource-Referenzen...53 Tabelle 5.3: Anwendungskomponenten und ihre Migrierbarkeit...59 V

8 VI Quellcodeverzeichnis Quellcodeverzeichnis Quellcode 4.1: Message Information Headers in einer SOAP-Nachricht...32 Quellcode 4.2: Referenzierung des Resource Properties Documents in WSDL...35 Quellcode 4.3: Nachrichtenaustausch für eine GetResourcePropertyDocument-Operation..36 Quellcode 6.1: persistence.xml für CounterService...61 Quellcode 6.2: Serialisierung einer CounterEntity...62 Quellcode 8.1: (Geronimo)DeploymentManager...83 VI

9 Abkürzungsverzeichnis VII Abkürzungsverzeichnis API ASF AXIOM CD CIM CPU CRUD ECM EIS EJB EPR ERP FH HTML HTTP J2EE JAR Java EE JAX-WS JCP JDBC JNDI JMX JPA JSP JSR JVM MIH NAT Application Programming Interface Apache Software Foundation Axis Object Model Compact Disc Common Information Model Central Processing Unit Create, Update, Delete Enterprise Content Management Enterprise Information System Enterprise JavaBeans Endpoint Reference Enterprise Resource Planning Fachhochschule Hypertext Markup Language Hypertext Transfer Protocol Java Enterprise Edition Java Archive Java Enterprise Edition Java API for XML-based Web services Java Community Process Java Database Connectivity Java Naming and Directory Interface Java Management Extensions Java Persistence API Java Server Page Java Specification Request Java Virtual Machine Message Information Header Network Address Translation VII

10 VIII Abkürzungsverzeichnis OASIS RMI SNMP SOAP SQL StAX TCK UDDI URI URL WSDL WSDM WSN Organization for the Advancement of Structured Information Standards Remote Method Invocation Simple Network Management Protocol Simple Object Access Protocol Structured Query Language Streaming API for XML Technology Compatibility Kit Universal Description Discovery and Integration Uniform Resource Identifier Uniform Resource Locator Web Service Description Language Web Services Distributed Management Web Services Notification (WS-Notification) VIII

11 Einleitung 9 Kapitel 1: Einleitung 1.1 Problemstellung Mit dem Erfolg von serviceorientierten Architekturen und Web Services ist die Anzahl an Diensten und Serverapplikationen in den vergangenen Jahren erheblich gestiegen. Typische Umgebungen enthalten eine große Anzahl an Diensten, die über mehrere Server verteilt sind und miteinander kommunizieren. Für einen möglichst effektiven und produktiven Geschäftsablauf ist es zwingend erforderlich, dass Systemadministratoren Serverapplikationen so verteilen, dass eine optimale Auslastung der einzelnen Serversysteme erreicht wird. Das ist in den meisten Fällen kein leichtes Unterfangen, denn einzelne Serverapplikationen können sehr unterschiedliche Anforderungen bezüglich CPU 1, Speicher oder Antwortzeit besitzen. Hinzu kommt die gesamte Dynamik von verteilten Anwendungen. Eventuell stehen zu Stoßzeiten Serverapplikationen zeitweise oder gar nicht zur Verfügung, weil das entsprechende Serversystem überlastet ist. Der Transfer einer Applikation vom überlasteten Server auf einen Server, der genügend Ressourcen bereitstellt, würde diesem Problem Abhilfe verschaffen. Eine Übertragung zur Laufzeit ist jedoch sehr problematisch und zeitaufwendig, da Abhängigkeiten zwischen einzelnen Diensten bestehen, Klientenanfragen stetig fortschreiten und aktuelle Zustände und Sitzungen nicht verloren gehen dürfen. 1.2 Vorgehensweise Im letzten Jahr entstand an der FH Furtwangen Software 2, um den Applikationsserver Apache Geronimo 3 zu überwachen. Im Rahmen dieses Projekts wird zuerst untersucht, unter welchen Umständen es möglich ist, eine Serveranwendung von einem Quell- auf einen Zielserver zu transferieren. Dabei wird auf zwei Dinge besonderen Wert gelegt. Zum einen, dass die Erreichbarkeit der Serverapplikation zu jedem Zeitpunkt gewährleistet ist - das bedeutet, dass keine Klientenanfragen verloren gehen oder verworfen werden. Zum anderen, dass 1 Central Processing Unit 2 ASCMon, HMon 3 Java Applikationsserver 9

12 10 Einleitung der aktuelle Zustand der Applikation auch nach der Übertragung unverändert vorliegt, damit bereits begonnene Klientensitzungen nicht neu gestartet werden müssen. Zu diesem Zweck ist es erforderlich, dass typische Serverapplikationen und Servertechnologien näher betrachtet werden. In diesem Zusammenhang wird besonders Wert darauf gelegt, wie Zustände modelliert werden und wie es möglich ist, diese auf andere Server zu übertragen. Um die Erkenntnisse aus einem ersten theoretisch angelegten Teil zu veranschaulichen, wird im weiteren Verlauf zuerst aufgezeigt, wie ein Servernetz aufgebaut sein muss, damit Klientenanfragen nicht verloren gehen. Anschließend wird dargestellt, wie Serverapplikationen konstruiert sein müssen, damit deren Zustände problemlos übertragen werden können. Zum Abschluss wird gezeigt, wie mit einem grafischen Demonstrationstool Beispielapplikationen auf sehr einfache Weise per Drag&Drop zwischen einzelnen Serverinstanzen transferiert werden können. Abschließend werden Messungen durchgeführt, die deutlich machen sollen, wie performant die ausgewählten Methoden sind. Überblick Die Kapitel 2 bis 5 befassen sich mit den theoretischen Grundlagen. In den Kapiteln 6 bis 11 werden die theoretischen Erkenntnisse in der Praxis angewandt. Kapitel 2: Konzepte Die Begriffe Migration, Merging und Lastkontrolle werden beschrieben. Kapitel 3: Java Enterprise Edition 5 Einführung in die Java Enterprise Edition mit einem besonderen Augenmerk auf die für diese Diplomarbeit relevanten Themen. Kapitel 4: Web Service Standards Beschreibung und Einführung in die für diese Diplomarbeit relevanten Web Service Standards. Kapitel 5: Serverapplikationen Beschreibung des Aufbaus typischer Serverapplikationen und Lieferung von Gedankenansätzen, wie deren Zustände übertragen werden können. 10

13 Einleitung 11 Kapitel 6: Stateful Web Services Zeigt die Implementierungen eines einfachen Web Services auf zwei unterschiedliche Weisen. Kapitel 6: Architektur Stellt dar, wie eine Architektur aussehen muss, damit Serverapplikationen ohne Verlust von Klientenanfragen zwischen Serverinstanzen migriert werden können. Kapitel 9: Servicemodul In diesem Kapitel wird erklärt, wie man ein Servermodul erstellt, mit dessen Hilfe Applikationen migriert werden können. Kapitel 10: Grafische Benutzeroberfläche Zum Schluss wird gezeigt, wie eine grafische Oberfläche für die einfache Migration mit Drag&Drop erstellt wird. Kapitel 11: Messungen Durchführung von Migrationen mit Zeit- und Leistungsmessungen. Kapitel 12: Resümee Abschluss der Diplomarbeit mit Ausblick. Begleitend zu dieser Diplomarbeit befindet sich in Anhang A eine CD, die Quellcode und zusätzliche Informationen enthält. 11

14 12 Konzepte Kapitel 2: Konzepte Migration ist ein sehr weitgefächerter Begriff, der in vielen Situationen sowohl innerhalb als auch außerhalb der Informationstechnik angewandt wird. In diesem Kapitel wird zuerst die Bedeutung dieses Begriffes geklärt und Anforderungen an einen Migrationsprozess definiert. Anschließend wird der Begriff Merging eingeführt. Am Ende des Kapitels wird der grobe Ablauf einer Migration dargestellt und der Begriff Lastkontrolle erläutert. 2.1 Migration Der Begriff Migration stammt von dem lateinischen Verb migrare ab, welches wörtlich mit wandern bzw. auswandern übersetzt werden kann. Im Fremdwörterbuch 4 wird Migration auf folgende Weise beschrieben: Migration: 1.BIOLOGIE dauerhafte Wanderung (Abwanderung und Einwanderung) und Durchzug ( Permigration, z. B. Vogelflug) in der Tierwelt 2.PHYSIK Wanderung von flüssigen oder gasförmigen Stoffen in einem porösen Material (z.b. Weichmachern in Kunststoffen oder Erdöl in Gestein) Beide Definitionen verdeutlichen die weite Streuung des Begriffs Migration. Neben den Bereichen Biologie und Physik wird das Wort Migration in vielen weiteren Zusammenhängen verwendet, die im Fremdwörterbuch allerdings nicht aufgeführt sind. Formen Für den Bereich Informationstechnik existiert keine allgemein gültige Definition des Begriffes Migration. Man unterscheidet stattdessen grundsätzlich zwei Migrationsformen. Unter der Software- bzw. Systemmigration versteht man den Software bzw. Systemwechsel auf ein Modell des gleichen oder eines anderen Herstellers 5. Bei dieser Form der Migration geht es 4 Vgl. Langenscheidt Fremdwörterbuch 5 Vgl. Migration von ECM-Systemen ( ) 12

15 Konzepte 13 darum eine bestehende Funktionseinheit in Form eines Softwaremoduls oder eines Systems durch ein neueres Modell zu ersetzen. Unter Datenmigration versteht man die Übertragung von Daten im Zuge eines Format-, Medien- oder Hardwarewechsels. Hierbei geht es darum bestehende Daten zu konvertieren bzw. ein altes Datenmodell in ein neues Exemplar zu überführen. Abbildung 2.1: Migration einer Serverapplikation Im Rahmen dieser Diplomarbeit kann der Begriff Migration missverstanden werden. Bei Migration handelt es sich im Rahmen dieser Diplomarbeit weder um Softwaremigration, also die Ersetzung einer Serverapplikation durch eine neue (bessere) Version, noch geht es um Datenmigration, also die Konvertierung einer Serverapplikation in ein neues Datenformat. Beide der genannten Definitionen für Migration sind in Bezug auf diese Diplomarbeit nicht korrekt. Da für den Begriff Migration keine standardisierte und allgemein gültige Definition existiert, der Begriff jedoch in vielen Situation verwendet und auch verstanden wird, wird für diese Diplomarbeit eine neue Definition eingeführt: Unter Migration versteht man die Überführung einer Serverapplikation von einem Quellserver (Server A) auf einen Zielserver (Server B). Abbildung 2.1 stellt dies grafisch dar. Anforderungen Für die Software- bzw. Datenmigration existieren allgemeine Anforderungen an einen Migrationsprozess. Die wichtigste Anforderung ist, dass eine Migration einen ununterbrochenen und sicheren Weiterverlauf der Geschäftsprozesse garantieren muss 6. Der produktive Geschäftsablauf darf nicht durch eine Migration unterbrochen werden. Diese Anforderung hat 6 Vgl. Migrationsstrategien (Informationstechnik) ( ) 13

16 14 Konzepte für die Migration von Serverapplikationen weitreichende Konsequenzen: zum einen muss eine Möglichkeit gefunden werden, wie Benutzer einer Serverapplikation von der Migration und dem damit veränderten Standort der Applikation in Kenntnis gesetzt werden, zum anderen werden Verfahren benötigt, die Zustandsdaten einer Serverapplikation übertragen, so dass Sitzungsdaten nicht verloren gehen. Strategien Neben den Migrationsformen unterscheidet man unterschiedliche Migrationsverfahren bzw. Migrationsstrategien 7. Während sich die Formen Software- und Datenmigration hauptsächlich mit der Frage Was? beschäftigen, widmen sich die Migrationsverfahren der Frage Wie?. Man unterscheidet grundsätzlich drei Formen. Die Migrationsform On demand ist abgeleitet von der weichen bzw. integrativen Migration: Weiche Migration: Bei diesem Verfahren erfolgt die Migration schrittweise und während des laufenden Betriebs. Für die Dauer der Migration werden Alt- und Neusystem parallel betrieben. Integrative Migration: Wie bei der weichen Migration werden Alt- und Neusystem parallel betrieben, das Neusystem ist jedoch in der Lage, auf das Altsystem zuzugreifen. Migration On Demand : Dieses Verfahren ist von der weichen bzw. integrativen Migration abgeleitet und aufwendig in der Implementierung. Dieses Verfahren verfolgt die Strategie einzelne Komponenten bei Bedarf vom Alt- auf das Neusystem zu übertragen. Harte Migration (Big Bang): Bei der harten Migration erfolgt die Umstellung vom Alt- auf das Neusystem punktuell zu einem bestimmten Zeitpunkt. Es erfolgt kein Parallelbetrieb des Alt- und Neusystems. 7 Vgl. Migration von ECM-Systemen ( ) 14

17 Konzepte 15 Nicht alle der aufgeführten Strategien sind für die Migration von Serverapplikationen geeignet. Die integrative Migration ist ungeeignet, da jede migrationsfähige Serverapplikation Methoden implementieren muss, die es ihr erlauben auf die Quellapplikation zuzugreifen. Prinzipiell ist dies zwar möglich, in der Realität jedoch aufwendig und unproduktiv. Das gleiche gilt für die Migration On Demand. Die harte Migration ist für die Migration von Serverapplikationen gänzlich ungeeignet, da die Zustandsdaten der Applikation übertragen werden müssen. Dies ist nur möglich, wenn sich die Laufzeiten der Quell- und Zielapplikation überschneiden. Das einzige geeignete Verfahren zur Migration von Serveranwendungen ist die weiche Migration, in der die Migration schrittweise erfolgt. 2.2 Merging Wie der Begriff Migration wird auch das Wort Merging bzw. Merge in vielen Situationen angewandt. Der aus dem englisch stammende Begriff kann mit fusionieren, mischen oder zusammenführen in die deutsche Sprache übersetzt werden. In der Informationstechnik wird tritt das Wort Merge beispielsweise in der Bezeichnung des Sortierverfahrens Merge- Sort auf, das eine gegebene Liste sortiert, indem es die Liste in mehrere kleinere Listen zerteilt, diese sortiert und anschließend wieder zusammenführt. Abbildung 2.2: Merging Im Rahmen dieser Diplomarbeit bezeichnet der Begriff Merging die Übertragung von Zustandsdaten zwischen zwei Instanzen einer Applikation. Das Merging ist der Migrationsschritt, bei dem die Zustandsdaten der Quellapplikation mit den (nicht vorhandenen) Zustandsdaten der migrierten Applikationsinstanz zusammengeführt werden. Die Migration einer Serverapplikation besteht im Grunde aus drei Schritten: die Installation der Applikation auf dem Zielsystem, dem Merging der Zustandsdaten und der Deinstallation der Applikation auf dem Quellsystem. Abbildung 2.2 stellt den Merging-Vorgang in einer Grafik dar. 15

18 16 Konzepte Für die Zeitdauer des Merging stehen die Quellapplikation und die Zielapplikation nicht für Anfragen zur Verfügung. Um den Anforderungen an Migrationen gerecht zu werden, wird ein Verfahren benötigt, welches die Anfragen, die über diese Zeitdauer hinweg gestellt werden, in eine Warteschlange stellt und abarbeitet sobald das Merging abgeschlossen ist. Abbildung 2.3: Weiche Migration einer Serverapplikation Abbildung 2.3 stellt den groben zeitlichen Ablauf der Migration einer Serverapplikation dar. Für die Zeitdauer des Merging sind zwar beide Applikationsinstanzen in der Lage, Anfragen anzunehmen, um die Zustandsdaten der Applikation konsistent zu halten, dürfen die Anfragen auf dem Quellsystem jedoch nicht abgearbeitet werden. Mit dem Abschluss des Merging wird ein Schalter umgelegt, der dafür sorgt, dass die Anfragen für die Applikation nun an das Zielsystem gerichtet werden. Zu diesen Anfragen sind auch die während des Merging zurückgestellten Anfragen zu zählen. 2.3 Lastkontrolle Unter Lastkontrolle versteht man die Feinabstimmung eines Systems, die dazu führt, dass Ressourcen gleichmäßig auf mehrere ressourcenbeanspruchende Prozesse verteilt werden 8. 8 Vgl. Load Balancing ( ) 16

19 Konzepte 17 Mit der Nutzung von Lastkontroll-Mechanismen versucht man, die Produktivität und Effizienz von Systemen zu erhöhen. Die Migration einer Serverapplikation kann diesem Zweck dienen. Wenn Serverapplikationen während der Laufzeit auf eine andere Maschine migriert werden, dann wird das Quellsystem entlastet. Abbildung 2.4: Lastkontrolle durch Migration Die Auslastung eines Serversystems hängt von vielen Parametern ab. Neben der Zahl und dem Umfang der einzelnen Applikationen, spielt die Klientenanzahl eine entscheidende Rolle. Abbildung 2.4 veranschaulicht das Prinzip der Lastkontrolle durch die Migration einer Serverapplikation. Die Last aller drei Server wird überwacht. Wird eine bestimmte Grenze überschritten, dann wird ein Vorgang ausgelöst, der eine Serverapplikation migriert. Für die Qualität der Lastkontrolle ist dabei wichtig, welche Applikation migriert wird und auf welchen Server die Migration erfolgt. 2.4 Zusammenfassung Da für den Begriff Migration in der Informationstechnik lediglich die Bedeutungen im Sinne von Software- bzw. Systemmigration und Datenmigration existieren, wurde für diese Di- 17

20 18 Konzepte plomarbeit ein neues Verständnis eingeführt. Die Migration einer Serverapplikation ist die Übertragung einer Serverapplikation von einem Quell- auf einen Zielserver. Eine Anforderung an eine Migration ist, dass für die Dauer einer Migration der produktive Geschäftsablauf nicht unterbrochen wird. Das bedeutet, dass Klientenanfragen nicht gelöscht oder verworfen werden. Ein weiteres Problem stellen die Zustände und Daten einer Serveranwendung dar. Diese müssen nach der Migration auf dem Zielsystem wieder verfügbar sein. Für die Migration einer Serveranwendung eignet sich am besten die Strategie einer weichen Migration, bei der Teile der Quellanwendung in Schritten auf das Zielsystem übertragen werden. Der erste Schritt ist die Installation der Applikation auf dem Zielsystem. In einem weiteren Schritt werden die Zustandsdaten der Quellapplikation auf das Zielsystem übertragen. Dieser Prozess wird in dieser Diplomarbeit als Merging bezeichnet. Um den Zustand einer Applikation konsistent zu halten, ist es erforderlich, dass für die Zeitdauer des Merging keine weiteren Anfragen auf dem Quellsystem abgearbeitet werden. Damit die Anforderungen weiterhin erfüllt bleiben, wird ein Mechanismus benötigt, der die in diesem Zeitraum gestellten Anfragen solange zurückhält bis das Merging abgeschlossen ist. Das Ziel, das mit der Migration von Serverapplikationen verfolgt wird, ist die Lastkontrolle. In einem Netz aus mehreren Servern werden die Applikationen so verteilt, dass eine möglichst gleichmäßige Auslastung wird. 18

21 Umgebung 19 Kapitel 3: Umgebung Serverapplikationen benötigen eine Laufzeitumgebung. Für Serverapplikationen wie Web Services eignet sich die Java Enterprise Edition (Java EE). Die Java EE 9 ist in der Industrie weit verbreitet, sie baut auf herstellerunabhängigen Standards auf und wird stetig weiterentwickelt. Dieses Kapitel befasst sich zunächst mit ausgewählten Themen der Java EE, wie dem Deployment, dem Management und der Persistenz. Am Ende des Kapitels werden außerdem die Besonderheiten des Java EE Applikationsservers Apache Geronimo vorgestellt, der als Laufzeitumgebung für Serverapplikationen und Web Services verwendet wird. 3.1 Java Enterprise Edition 5 Die Java EE ist ein Bündel aus mehreren Spezifikationen. Diese wurden von der Java-Community in einem langwierigen Prozess eingeführt und entwickelt. Die Java EE umfasst Technologien für die Entwicklung von skalierbaren, verteilten und transaktionsbasierten Multi- Tier-Anwendungen. Sie ist neben.net, die am weitesten verbreitete Enterprise Architektur. Die Popularität der Java EE beruht vor allem auf der Plattform- und Herstellerunabhängigkeit, den offenen Standards, der Stabilität und der evolutionären Weiterentwicklung durch den Java Community Process (JCP). Die Java EE umfasst eine Reihe an Spezifikationen 10, die Hersteller von konformen Produkten implementieren müssen. Multi-Tier-Architektur Bei Java EE Applikationen kann die Anwendungslogik je nach Funktionalität auf mehrere Schichten verteilt werden. Die Komponenten der einzelnen Schichten, die auch als Tiers bezeichnet werden, befinden sich dabei auf einer anderen Maschine. Man unterscheidet bei der Java EE grundsätzlich vier Tiers 11. Client Tier: Diese Schicht ist für die Präsentation zuständig und befindet sich auf Klien- 9 Java Enterprise Edition 10 Vgl. Anhang B 11 Vgl. Jendrock/Ball/Carson et al. (2006), S. 3 19

22 20 Umgebung tenseite. Die Präsentation erfolgt auf unterschiedliche Weise, z. B. über eine Java-Applikation, ein Java-Applet oder als Webseite in einem Browser. Web Tier Die Web-Tier-Schicht ist auf einem Java EE Applikationsserver lokalisiert. In ihr befinden sich Komponenten wie Servlets und Java Server Pages (JSP), die in der Lage sind, Webseiten dynamisch zu erzeugen. Business Tier Auch die Business-Tier-Schicht befindet sich auf einem Java EE Server. Sie enthält Enterprise Java Beans, die Geschäftslogik enthalten und Transaktionen unterstützen. EIS 12 -Tier Die EIS-Tier-Schicht umfasst Systeme innerhalb der Unternehmensstruktur, wie Datenbank-, ERP 13 - oder Legacysysteme. In vielen Fällen interagieren Java EE Serveranwendungen mit Systemen des EIS-Tier, um Dienste bereitzustellen. Die Multi-Tier-Architektur der Java EE ermöglicht die Entwicklung leistungsfähiger und skalierbarer Serverapplikationen Java Deployment API (JSR-88) Unter Deployment versteht man die Verteilung, Installation und Konfiguration von Software auf einem Zielsystem 14. Die Java EE Deployment API ist in JSR spezifiziert und wurde erstmals im Oktober 2000 eingeführt. Sie definiert eine Architektur, die es erlaubt Anwendungen auf Java EE 5 konformen Serverprodukten unterschiedlicher Anbieter zu installieren und zu konfigurieren. Die Spezifikation beschreibt Java-Schnittstellen, die von den Anbietern von Java EE Serverprodukten implementiert werden müssen -die Implementierung dieser Schnittstellen wird als Server Plugin bezeichnet. Außerdem werden Java Schnittstellen beschrieben, die Anbieter von Deploymenttools integrieren müssen, damit ihr Deployment 12 Enterprise Information System 13 Enterprise Resource Planning System 14 What is deploy? ( ) 15 vgl. Dochez (2006) 20

23 Umgebung 21 Tool mit einem Server Plugin interagieren kann. Abbildung 3.1 stellt die Beziehungen zwischen Server Plugin, Deployer, Deployment Tool und Java EE 5 Server grafisch dar. Abbildung 3.1: Deployment nach JSR-88 Bei der Implementierung und Verwendung eines Server Plugins spielen vor allem zwei Schnittstellen eine wichtige Rolle. Die Schnittstelle DeploymentManager ist der Zugangspunkt für ein Deploymenttool, um Operationen auf einem konformen Java EE Server auszuführen. Zu den in der Spezifikation geforderten Operationen zählen die Konfiguration, die Verteilung, der Start, das Anhalten und das Undeployment einer Applikation 16. Bei der zweiten Schnittstelle DeploymentFactory handelt es sich um den eigentlichen Treiber für das Deployment. Eine DeploymentFactory erzeugt DeploymentManager-Instanzen, mit denen Operationen auf einem Java EE Server aufgerufen werden können. Damit Serverapplikationen auf unterschiedlichen Java EE Servern installiert werden können, werden sie in Java-Archive gepackt. Es gibt insgesamt fünf unterschiedliche, Java EE konforme Archivtypen: Webarchive, EJB 17 -Archive, Applikationsarchive, Archive für Resource Adapter und Archive für Application Clients. Bei jedem dieser Archivtypen handelt es sich um eine JAR 18 -Datei, die internen Ordnerstrukturen sind aber unterschiedlich. Die Tabelle in Anhang B gewährt einen Einblick in die Struktur der verschiedenen Archivtypen. 16 Anm. des Verfassers: Die Spezifikation lässt weitere herstellerspezifische Operationen zu. 17 Enterprise JavaBeans 18 Java Archive 21

24 22 Umgebung Java Management API (JSR-77, JSR-3, JSR-160) Unter den zahlreichen Spezifikationen der Java EE befindet sich auch eine Spezifikation für das Management. In JSR wird festgelegt, wie ein Java EE Server und die darauf enthaltenen Applikationen effizient und auf standardisierte Weise verwaltet werden können. Dazu werden in JSR-77 Managed Objects eingeführt. Es handelt sich dabei um Objekte eines Java EE Servers oder einer Serverapplikation, die verwaltet und über einen einen eindeutigen Namen angesprochen werden können. Für den Zugriff auf die Managed Objects sieht die Spezifikation JMX 20, SNMP 21 oder CIM 22 vor. Java Management Extensions (JMX) Die JMX-Spezifikation befindet sich in JSR-3 23 und JSR JMX umfasst eine Architektur, Entwurfsmuster, APIs und Dienste für das Management und das Monitoring von Java-Anwendungen. Der JMX-Standard macht es möglich, Softwarekomponenten in ein bestehendes Management- oder Monitoringnetzwerk zu integrieren und zu verwalten. Die Vorteile von JMX sind der geringe Implementierungsaufwand, die Skalierbarkeit und die bereits genannte simple Integration neuer Managementobjekte. Die JMX-Architektur ist in drei Ebenen gegliedert 25. Das Instrumentation- und Agent-Level sind Bestandteil von JSR-3. Das Remote Management ist getrennt in JSR-160 festgelegt. Instrumentation Level: Verwaltbare Ressourcen werden als Java-Objekte dargestellt. Diese Objekte werden als Managed Beans (MBeans) bezeichnet. MBeans besitzen Attribute und Operationen, die JMX-Management- und Monitoringtools über einen JMX-Agenten bereitgestellt werden. 19 Vgl. Hrasna (2006) 20 Java Management Extensions 21 Simple Network Management Protocol: Netzwerkprotokoll um Netzwerkkomponenten zu verwalten 22 Common Information Model: von der Distributed Management Task Force (DMTF) verabschiedeter Standard für das Management von IT-Systemen 23 Vgl. Java Management Extensions (JMX) Specification, version 1.4 (9. November 2006) Kapitel I+II 24 Vgl. Java Management Extensions (JMX) Specification, version 1.4 (9. November 2006), Kapitel III 25 Vgl. Java Management Extensions (JMX) Technology Overview ( ), Chapter 2 22

25 Umgebung 23 Agent Level: Die Hauptkomponente eines JMX-Agenten ist ein MBean-Server. Die MBeans werden an einem MBean-Server registriert und so für die Verwaltung zugänglich gemacht. Remote Management Level: Über Protokolladapter und Konnektoren wird ein JMX-Agent auch für Anwendungen verfügbar gemacht, die sich nicht innerhalb derselben Java Virtual Machine (JVM) befinden. Um verschiedenen Anforderungen gerecht zu werden, gibt es vier verschiedene MBean-Typen 26. Die Schnittstellen und das Entwurfsmuster für die einzelnen Typen werden in der Spezifikation festgelegt 27. Standard MBeans Die Attribute und Operationen des MBeans stehen zur Kompilierungszeit fest und ändern sich nicht. Dynamic MBeans Die Attribute und Operationen werden zur Laufzeit erkannt. Es ist möglich, dass sich Attribute und Operationen mit der Zeit ändern. Open MBeans & Model MBeans Open MBeans und Model MBeans sind erweiterte Dynamic MBeans 28. Der entfernte Zugriff auf Verwaltungsfunktionen erfolgt über Konnektoren. Ein Konnektor macht den MBean-Server auf einem entfernten Rechner zugänglich 29. Für den Zugriff wird standardmäßig ein auf RMI 30 basierendes Protokoll verwendet. Diese Zugriffsmethode muss von jeder JMX-Implementierung unterstützt werden. Die JMX-Spezifikation erlaubt auch die Implementierung eigener Konnektoren. Für die Nutzung von JMX existieren zahlreiche Management Applikationen. Das Java Development Kit enthält eine solche Applikation mit dem Namen JConsole. 26 Vgl. Hanson (2006) bzw. Köhler (2003) 27 Vgl. Java Management Extensions (JMX) Specification, version 1.4 (9. November 2006), S. 41 f. 28 Anm. des Verfassers: Für mehr Informationen vgl. Hanson (2006) 29 Java Management Extensions (JMX) Technology Overview ( ), Chapter 5 30 Remote Method Invocation 23

26 24 Umgebung Java Persistence API (JSR-220) Persistenz spielt in vielen Anwendungen eine wichtige Rolle. Unter Persistenz versteht man die Fähigkeit Daten in nicht-flüchtigen Speichermedien wie dem Dateisystem oder einer Datenbanken zu speichern 31. Persistente Daten sind unabhängig von der Laufzeit der Applikation. Wenn Daten innerhalb einer Applikation persistent gemacht werden, können sie bei einem Neustart der Anwendung wieder geladen und angezeigt bzw. verarbeitet werden. Bezüglich der Persistenz von Daten, spielen seit jeher relationale Datenbanksysteme eine dominante Rolle. Relationale Datenbanken haben sich am Markt wegen ihrer Einfachheit, Flexibilität und Leistung durchgesetzt. Die Persistierung von Java-Objekten (oder Objekte anderer objektorientierter Programmiersprachen) in einer relationalen Datenbank ist jedoch nicht einfach und gespickt mit Hindernissen. Der Grund liegt in der Kluft zwischen dem relationalen Modell der Datenbank und dem objektorientierten Modell der Anwendung. Relationale Datenbanken sind einfach aufgebaut und bestehen, vereinfacht gesagt, aus Tabellen, die über Schlüssel miteinander verknüpft sind. Das Objektmodell von Java ist im Vergleich zum relationalen Datenbankmodell umfangreicher. Beispielsweise unterstützt Java Vererbung, das relationale Datenmodell verfügt über keine adäquate Methodik. Wie das Objektmodell auf das relationale Datenbankmodell abgebildet wird, ist nicht eindeutig. Es existieren immer verschiedene Möglichkeiten, wie Daten zwischen den Modellen abgebildet werden können. Die Abbildung zwischen objektorientierten und relationalen Daten wird als Object-Relational-Mapping oder OR-Mapping bezeichnet. Entities Der Begriff Entity 32 wurde erstmals von Peter Chen im Jahr 1976 bei der Einführung des Entity-Relationship Model definiert. Chen beschreibt eine Entity als eine Sache, die über Attribute und Beziehungen zu anderen Entities verfügt. Entities werden über Annotationen oder einen XML-Deskriptor konfiguriert. Die Konfiguration erfolgt nach dem Configuration-by-Exception-Prinzip, was bedeutet, dass die Konfiguration einer Entity zunächst Standardwerte annimmt, die für den Großteil aller Anwendungen zutreffen. Vom Standard abweichende 31 Vgl. Persistenz ( ) 32 Vgl. Chen (1976) 24

27 Umgebung 25 Konfigurationseinstellungen werden, wie bereits erwähnt, über Annotationen oder einen XML-Deskriptor festgelegt. Durch diese Methode bleibt die vorhandene Komplexität von Entities verborgen und die Verwendung der Java Persistence API (JPA) wird vereinfacht. EntityManager & PersistenceContext Da Entities nicht in der Lage sind sich selbst persistent zu machen, bedarf es einer spezialisierten Schnittstelle. Der EntityManager verwaltet Entities und verrichtet die notwendigen Aufgaben, um Entities zu persistieren. Eine Entity die von einem EntityManager verwaltet wird, wird als eine managed Entity bezeichnet. Die Menge aller von einem EntityManager verwalteten Entities nennt man den PersistenceContext. Der EntityManager stellt Operationen bereit, um mit Entities zu arbeiten. Es gibt unterschiedliche Arten, wie ein EntityManager und damit Persistenz in Anwendungen integriert werden können 33. Der einfachste Weg, ist die Verwendung eines container-managed EntityManagers, bei dem ein Container über die einen EntityManager injiziert 34. Bei einem application-managed EntityManager, wird der PersistenceContext nicht vom Container injiziert, sondern der Entwickler selbst ist für die Erstellung eines EntityManagers und damit für dessen Laufzeit verantwortlich. EntityManagerFactory & PersistenceUnit EntityManager werden mit Hilfe der EntityManagerFactory-Schnittstelle erzeugt. Damit eine EntityManagerFactory erstellt werden kann, wird ein XML-Deskriptor persistence.xml benötigt, in dem eine oder mehrere PersistenceUnits definiert werden. Die PersistenceUnit enthält Konfigurationsdaten wie z. B. Informationen zur Datenbankverbindung. Die EntityManagerFactory benutzt diese Konfigurationsdaten, um EntityManager zu erstellen. Abschnitt 5.5 enthält weitere Informationen zu der JPA 35, insbesondere über den Lebenszyklus von Entities und einzelne EntityManager-Operationen. 33 Vgl. Sriganesh/Brose/Silverman (2006), S Anm. des Verfassers: Es gibt zwei Arten von Container-managed EntityManagers, die sich im Verhalten unterscheiden: transaction-scoped und extended. 35 Java Persistence API 25

28 26 Umgebung 3.2 Apache Geronimo Der Java EE Applikationsserver Apache Geronimo ist ein Softwareprojekt der ASF 36 und unterliegt der Apache License Version Apache Geronimo ist zum aktuellen Zeitpunkt in einer Vorabversion mit der Versionsbezeichnung 2.0 Milestone 6 Release Candidate 1 verfügbar. Diese Version hat die Tests des Java EE 5 TCK 38 bestanden und steht kurz vor der Zertifizierung für die Java EE Version 5. Apache Geronimo ist modular aufgebaut und verwaltet Servermodule, Bibliotheken und Applikationen in einem internen, Apache Maven2 39 ähnlichen Repository. Durch die modulare Bauweise kann Apache Geronimo sehr leicht an die individuellen Bedürfnisse angepasst werden. Auf der offiziellen Webseite 40 werden zwei verschiedene Installationspakete angeboten. Zum einen ein vollständiges Apache Geronimo Installationspaket, zum anderen ein leichtgewichtiges Paket mit dem Namen Little-G, welches dem Anwender einen minimalen Funktionsumfang bereitstellt GBean-Architektur Apache Geronimo ist zu einem großen Teil aus bereits bestehenden Open Source Softwarekomponenten 41 aufgebaut. Um diese einzelnen Komponenten zu einem funktionsfähigen Gesamtsystem zu verbinden, stellt Apache Geronimo ein Framework zur Verfügung, mit dessen Hilfe Komponenten als sogenannte GBeans auf einfache Weise eingebunden werden können 42. Referenzen zwischen einzelnen GBeans werden vom Framework, dem Geronimo Kernel, verwaltet. Dadurch wird eine lose Kopplung der einzelnen Komponenten Abbildung 3.2: Geronimo-Architektur Quelle: vgl. Genender (2005), leicht abgeändert 36 Apache Software Foundation 37 Verfügbar unter 38 Technology Compatibility Kit 39 Frei erhältliches Build-Management-Tool der ASF, verfügbar unter Vgl. Anhang B 42 Vgl. Geronimo Architecture ( ) 26

29 Umgebung 27 erreicht. Die in Abbildung 3.2 dargestellte Grafik stellt den Geronimo-Kernel dar. Um den Geronimo-Kernel werden einzelne Systemkomponenten von Apache Geronimo als Dreiecke dargestellt. Bei diesen Komponenten handelt es sich um andere ASF-Projekte, wie beispielsweise den Web Container Apache Tomcat oder die Datenbank Apache Derby. Die verschiedenen Komponenten werden mittels eines oder mehreren GBeans in das System eingebunden. Der Geronimo-Kernel ermöglicht die Kommunikation unter einzelnen GBeans und Komponenten. GBean Ein GBean ist ein leichtgewichtiger Wrapper, der eine bestimmte Funktionseinheit Apache Geronimos umhüllt und bestimmte Operationen dieser Funktionseinheit für andere Komponenten bereitstellt 43. GBeans unterliegen einem Lebenszyklus 44. Praktisch jede Komponente innerhalb von Apache Geronimo ist als GBean realisiert. Dazu zählen beispielsweise Container wie Apache Tomcat, aber auch einzelne Applikationen wie Servlets, Enterprise Beans oder Web Services. Jedes GBean wird im Kernel registriert. Der Kernel initialisiert das GBean und injiziert die im GBean festgelegten Referenzen auf andere GBean-Instanzen mit Hilfe des Dependency Injection Patterns 45. Durch diese Methode sind die einzelnen GBeans nur lose miteinander verbunden. Ein Erweiterung von Geronimo ist dadurch sehr einfach. Es muss lediglich ein GBean implementiert und anschließend mit Hilfe eines speziellen Deployment Plans in Apache Geronimo eingebunden werden. Der Aufwand, ein einfaches GBean zu erstellen, ist gering. Bei einem GBean handelt es sich um eine einfache Java-Klasse, die die Methode getgbeaninfo und optional die Schnittstelle GBeanLifecycle implementiert. Die getgbeaninfo-methode liefert eine GBeanInfo-Instanz zurück, in der die Eigenschaften des GBeans festgelegt sind. Zu den Eigenschaften des GBeans zählen Informationen zum Konstruktor, zu Operationen, zu Attributen und zu Referenzen. Der Geronimo-Kernel verwendet diese Informationen um Instanzen des GBeans zu erstellen. Die Schnittstelle GBeanLifecycle definiert die drei Callback-Methoden dostart, 43 Vgl. Lee (2005) 44 Vgl. Zimmerly (2006), Abschnitt 3 45 Vgl. Fowler (2004) 27

30 28 Umgebung dofail und dostop, die beim Start, im Fehlerfall und bei der Beendigung eines GBeans aufgerufen werden. Geronimo-Kernel Der Geronimo-Kernel ist ein Container für GBeans. Er ist das Herzstück von Apache Geronimo und ermöglicht die Kommunikation zwischen einzelnen GBean-Instanzen, indem er die in den GBeanInfo eingetragenen Referenzen auswertet und mit der Bibliothek cglib 46 dynamisch Proxy-Objekte erstellt 47. Operationen auf einem anderen GBean werden über das Proxy-Objekt und über den Kernel ausgeführt. Die einzelnen GBeans sind so nur lose miteinander verknüpft. Eine andere wichtige Funktion des Geronimo-Kernels ist die Bereitstellung der Managementfunktionalität nach JSR-77. Ein GBean ist keine Erweiterung der aus JMX bekannten MBean- Klasse. Der Geronimo-Kernel stellt GBeans über eine MBeanServerKernelBridge als MBeans zur Verfügung. Bei einem MBeanServerKernelBridge-Objekt handelt es sich um ein dynamisches MBean 48, welches an Geronimos integrierten MBeanServer gebunden wird Plugins Plugins sind ein spezieller Installationsmechanismus von Apache Geronimo. Bei einem Geronimo Plugin handelt es sich um ein speziell gepacktes Archiv, das neben einen oder mehreren Java EE Archiven bzw. Geronimo-Diensten einen Plugin Deskriptor enthält. Dieser XML- Deskriptor enthält Informationen über das Plugin und beschreibt dessen Abhängigkeiten. Zu den Abhängigkeiten zählen neben den von der Applikation benötigt Java-Bibliotheken (JAR- Archiven), auch andere Geronimo Module, wie z. B. Web Container, Database Pools oder Security Realms, die für den korrekten Ablauf der Anwendung notwendig sind. Der Apache Geronimo Deployer erlaubt neben dem üblichen Deployment von Applikationen über die JSR-88-Schnittstelle auch die Installation von Plugins aus einem entfernten Reposi- 46 Code Generation Library: Bibliothek für dynamische Code-Generierung, 47 Vgl. Kumar (2006), S. 33 f. 48 Vgl. Abschnitt

31 Umgebung 29 tory. Die für die Installation zuständige Serverkomponente, der PluginInstaller, lädt auf Initiave des Deployers hin das Plugin herunter und überprüft, ob die im Plugin-Deskriptor beschriebenen Abhängigkeiten erfüllt werden können. Sind Abhängigkeiten vorhanden, die im Augenblick am Server nicht aufgelöst werden können, wird versucht, die benötigten Bibliotheken und Module nachzuinstallieren 49. Der PluginInstaller kann hierzu entweder das Quell- Repository des Plugins oder eines der im Plugin-Deskriptor angegebenen Repositories verwenden. Kann aus einem bestimmten Grund eine Abhängigkeit nicht aufgelöst werden, wird das Plugin nicht installiert. Abbildung 3.3: Plugin-Konzept von Apache Geronimo Abbildung 3.3 stellt zwei typische Plugin-Szenarien dar. Im ersten Fall wird ein Plugin aus einem zentralen Repository installiert, im zweiten Fall ein Plugin, das im lokalen Server-Repository einer anderen Apache Geronimo Instanz vorhanden ist. Das entfernte Repository 49 Vgl. Geronimo Plugins - Frequently Asked Questions ( ) 29

32 30 Umgebung muss, damit Plugins daraus installiert werden können, über HTTP 50 erreichbar sein. Das Repository entspricht strukturmäßig einem Apache Maven2 Repository. Die darin hinterlegten Softwarekomponenten liegen nach Gruppen (groupid), Produkt (artifactid), Version (version) und Archivtyp (packaging) geordnet im Dateisystem vor. Einzelne Komponenten des Repositories können über die Bezeichnung groupid/artifactid/version/packaging identifiziert werden. Die in einem Repository vorhandenen Plugins werden in einer XML-Datei mit der Bezeichnung geronimo-plugins.xml im Wurzelverzeichnis des Repositories definiert. Apache Geronimo stellt auch einen Mechanismus zur Verfügung, um einen bestehenden Geronimo-Server als Plugin-Repository zu verwenden. Mit einem Servlet wird die XML-Datei geronimo-plugins.xml zur Laufzeit erzeugt und über die URL anderen Servern über HTTP bereitgestellt. Für den Zugriff auf die genannte URL 51 wird eine gültige Benutzer-Passwort-Kombination benötigt. Eine Geronimo-Instanz bietet alle auf ihm installierten Module als Plugin-Download an. Der entsprechende Plugin-Archiv wird zur Laufzeit von Apache Geronimo mit Hilfe des PluginBuilder erzeugt. Durch dieses Verfahren ist es möglich, einzelne Module schnell und komfortabel zwischen Server-Instanzen zu übertragen. 3.3 Zusammenfassung Die Java EE ist ein Bündel aus mehreren APIs 52, die in einzelnen JSR 53 spezifiziert worden sind. Dieses Kapitel gewährte dem Leser einen ersten Einblick in die Deployment-, Management- und Java Persistence API: Die J2EE Deployment API standardisiert die Verteilung und Konfiguration von Java EE Serverapplikationen. Hersteller von Java EE Serverprodukten implementieren ein Paket aus Schnittstellen, das als Server Plugin bezeichnet 50 Hypertext Transfer Protocol 51 Uniform Resource Locator 52 Application Programming Interface 53 Java Specification Request 30

33 Umgebung 31 wird. Mit Hilfe des Server Plugins ist es möglich, JSR-88-Operationen auf dem entsprechenden Java EE Server auszuführen. Mit der Java Management API existiert ein einheitliches Modell, um Java EE Server zu verwalten. Der Zugriff auf Verwaltungsfunktionen erfolgt in den meisten Fällen mit JMX. JMX erlaubt auch Remote-Zugriff. Die Java Persistence API ist Teil der neuen EJB3-Spezifikation. Mit JPA wird die Persistenz in Applikation standardisiert und vereinfacht. Um Persistenzoperationen auszuführen wird ein EntityManager benötigt, der Entities verwaltet. Entities sind einfache Java-Klassen. Sie enthalten Daten und Informationen, wie die in einer Entity enthaltenen Daten in einer Datenbank gespeichert werden (OR-Mapping). Mit Apache Geronimo existiert ein leistungsfähiger Java EE Applikationsserver: Durch die GBean-Architektur wird es Entwicklern leicht gemacht, bestehende Software zu integrieren oder neue Softwaremodule für Apache Geronimo zu erstellen. GBeans werden im Geronimo-Kernel registriert und verwaltet. Referenzen unter GBeans werden nach dem Dependency Injection Entwurfsmuster vom Geronimo-Kernel in die GBeans injiziert, wodurch eine lose Kopplung entsteht. Das Plugin-Konzept von Apache Geronimo ist eine sinnvolle Erweiterung des üblichen Deployment-Konzepts. Es erlaubt die Installation von Servermodulen aus entfernten Plugin-Repositories oder von einem anderen Apache Geronimo Server. Bei der Installation eines Plugins werden Abhängigkeiten geprüft und gegebenenfalls nachinstalliert. Apache Geronimo stellt über einen Adapter, die in JSR-77 geforderte Management-Funktionalität, bereit. Dieses Kapitel führte in die Grundlagen der Java EE und Apache Geronimo ein. Diese Grundlagen finden in den kommenden Kapiteln vermehrt ihre Anwendung. 31

34 32 Web Service Standards Kapitel 4: Web Service Standards Neben den W3C-Standards WSDL 54, SOAP 55 und UDDI 56 wuchs in der Industrie in den letzten Jahren der Bedarf für weitere Web Service Standards. Das Industriekonsortium OASIS 57 hat mehrere Spezifikationen veröffentlicht, die den Nachrichtenaustausch von Web Services vereinheitlichen. Durch den standardisierten Nachrichtenaustausch wird die Interoperabilität von Web Service Systemen unterschiedlicher Hersteller erhöht. Dieses Kapitel führt in einige dieser Spezifikationen ein. 4.1 Web Services Addressing (WS-Addressing) Die WS-Adressing-Spezifikation wurde im August des Jahres 2004 dem W3C vorgelegt. Hinter WS-Addressing verbirgt sich ein Konzept, um Web Services und Nachrichten unabhängig vom Transportprotokoll zu adressieren. Dazu werden in der Spezifikation zwei Konstrukte eingeführt: Endpoint References (EPR) und Message Information Headers (MIH). WS-Addressing wird in vielen anderen Spezifikationen als Addressierungsmechanismus verwendet, unter anderem in dem im Abschnitt 4.2 beschriebenen Web Service Resource Framework. In der Spezifikation werden zunächst die Begriffe Web Service Endpoint und Endpoint Reference erläutert 58. A Web service endpoint is a (referenceable) entity, processor or resource where Web service messages can be targeted. Endpoint references convey the information needed to identify/reference a Web service endpoint, [...] 54 Web Service Description Language 55 Simple Object Access Protocol 56 Universal Description Discovery and Integration 57 Organization for the Advancement of Structured Information Standards: 58 Vgl. Box/Christensen/Curbera et al. (August 2004), Abschnitt 1 32

35 Web Service Standards 33 Für die Verwendung von Endpunktreferenzen in Web Service Nachrichten wird in der Spezifikation ein XML 59 -Schema für Endpoint References festgelegt. Der damit definierte EPR 60 - Typ wird in den Message Information Headers verwendet, um einzelne Web Service Nachrichten zu adressieren. Neben der Adresse kann eine Endpunktreferenz weitere anwendungsspezifische Parameter enthalten. Dadurch ist die Spezifikation flexibel und vielseitig einsetzbar 61. Die Spezifikation beschreibt mehrere Message Information Headers, einige davon sind optional andere erforderlich. Die Message Information Headers können einem SOAP-Header hinzugefügt werden, wodurch eine Nachricht unabhängig vom verwendeten Transportprotokoll adressiert wird. Quellcode 4.1: Message Information Headers in einer SOAP-Nachricht <S:Envelope xmlns:s=" xmlns:wsa=" <S:Header> <wsa:messageid>uuid:6b29fc40-ca b31d-00dd010662da</wsa:messageid> <wsa:replyto> <wsa:address> </wsa:replyto> <wsa:to> <wsa:action> </S:Header> <S:Body>... </S:Body> </S:Envelope> Quelle: Box/Christensen/Curbera et al. (August 2004), Abschnitt 1 Der in Quellcode 4.1 dargestellte Codeauschnitt zeigt eine mit Message Information Headers versehene SOAP-Nachricht. Bei allen im SOAP-Header befindlichen Elementen mit dem Präfix wsa, handelt es sich um Message Information Headers gemäß der WS-Addressing-Spezifikation. Die Nachricht ist an den Web Service adressiert (To-Element), auf dem die Aktion (Action-Element) durchgeführt wird. Das ReplyTo-Element ist vom Typ Endpoint Reference und gibt die Endpunktreferenz an, an die eine Antwort erfolgt. Die Antwortadresse kann sich vom eigentlichen Anfragesteller unterscheiden. In diesem Beispiel wird die Antwort an den 59 Extensible Markup Language 60 Endpoint Reference 61 Anm. des Verfassers: vgl. Implied Resource Pattern in Abschnitt

36 34 Web Service Standards Endpunkt mit der Adresse gesandt. Das MessageID-Element, dient dazu die Nachricht zu identifizieren. 4.2 Web Service Resource Framework (WSRF) Das Web Service Resource Framework ist ein Rahmenwerk um mit Hilfe eines Web Service auf eine Ressource zuzugreifen. Das WSRF 62 besteht aus mehreren Spezifikationen 63 mit den Bezeichnungen WS-Resource, WS-ResourceProperties, WS-ResourceLifetime, WS-Service- Group und WS-BaseFaults, die im folgenden beschrieben werden. Die Spezifikation WS-ResourceMetadataDescriptor ist nicht Bestandteil der WSRF-Spezifikation, wurde aber von dem dafür zuständigen Komitee 64 der OASIS geprüft und für die Verwendung innerhalb des WSRF freigegeben. WS-Resource In der WS-Resource-Spezifikation wird zunächst geklärt was eine Ressource ist und anschließend der Begriff WS-Resource vorgestellt 65. A resource is a logical entity that has the following characteristics: it MUST be identifiable. it MUST have a set of zero or more properties which are expressible in XML infoset. it MAY have a lifecycle. Auf Grundlage dieser Definition wird die Bezeichnung WS-Resource eingeführt. Eine WS-Resource ist die Komposition von einer Ressource und einem Web Service, über den auf die Ressource zugegriffen werden kann. Es wird festgelegt, wie die Anforderungen an eine Ressource innerhalb einer WS-Resource umgesetzt werden müssen. Um eine WS-Resource eindeutig zu identifizieren muss sie mittels einer WS-Addressing-konformen Endpunktreferenz 62 Web Service Resource Framework Vgl. Graham/Karmarkar/Mischkinsky et al. (April 2006), S. 5 34

37 Web Service Standards 35 adressiert werden. Diese Art der Adressierung wird auch als Implied Resource Pattern bezeichnet. Die Eigenschaften eine Ressource werden mit den Mitteln der WS-ResourceProperties-Spezifikation beschrieben. Verfügt oder benötigt eine Ressource einen Lebenszyklus dann muss dieser mit Hilfe der WS-ResourceLifetime-Spezifikation implementiert werden. Abbildung 4.1: WS-Resources Quelle: Graham/Karmarkar/Mischkinsky et al. (April 2006), S. 6 (leicht abgeändert) In Abbildung 4.1 wird das Konzept von WS-Resources noch einmal verdeutlicht. Der Web Service gewährt Zugriff auf die Ressourcen A, B und C. Durch die Adressierung mit dem Implied Resource Pattern kann eine Anfrage einer bestimmten Ressource zugeordnet werden. Die Ellipsen mit den Bezeichnungen WS-Resource-A und WS-Resource-C stellen eine einzelne WS-Resource dar und teilen sich den Web Service als Zugriffspunkt. Ressource B stellt eine Ressource dar, die nicht an einen Web Service gebunden ist, und deshalb nicht als WS-Resource bezeichnet wird. WS-ResourceProperties Die WS-ResourceProperties-Spezifikation 66 beschäftigt sich mit den Eigenschaften einer Ressource. Zum einen legt sie fest, wie die Eigenschaften einer Ressource beschrieben werden, zum anderen beschreibt sie Nachrichten, mit denen einheitlich auf diese Eigenschaften zugegriffen werden kann. 66 Vgl. Graham/Treadwell (April 2006) 35

38 36 Web Service Standards Die Eigenschaften einer Ressource werden mit XML-Schema beschrieben und in einer XML- Schema-Datei, dem sogenannten Resource Properties Document, abgelegt. Der Web Service referenziert das Resource Properties Document in seiner WSDL-Datei im porttype-element, wie Quellcode 4.2 noch einmal darstellt. Quellcode 4.2: Referenzierung des Resource Properties Documents in WSDL... <wsdl:porttype... wsrf-rp:resourceproperties= xsd:qname... >... </wsdl:porttype>... Quelle: Graham/Treadwell (April 2006), S. 12 Um auf einzelne Eigenschaften einer Resource zugreifen zu können werden in der Spezifikation mehrere Web Service Operationen eingeführt. Zu diesen Operationen gehören 67 : GetResourcePropertyDocument Gibt das Resource Properties Document einer WS-Resource zurück, das die aktuellen Werte der definierten Ressourceneigenschaften enthält. GetResourceProperty Gibt den Wert einer Eigenschaft zurück. GetMultipleResourceProperties Gibt Werte für mehrere Eigenschaften zurück. QueryResourceProperties Erlaubt die Abfrage von Eigenschaften, beispielsweise mit XPath 68. PutResourcePropertyDocument: Erlaubt die Ersetzung eines Resource Properties Documents für eine WS-Resource. InsertResourceProperties: Erlaubt es, einer bestimmten Eigenschaft ein neues Element hinzuzufügen. 67 Vgl. Banks (Dezember 2005)

39 Web Service Standards 37 UpdateResourceProperties: Erlaubt die Änderung eines Eigenschaftswerts. DeleteResourceProperties: Löscht alle Elemente einer bestimmten Eigenschaft. SetResourceProperties: Erlaubt die gleichzeitige Änderung mehrere Eigenschaften, so dass separate Insert-, Update- und DeleteResourceProperties-Aufrufe nicht nötig sind. Für jede der genannten Operation wird innerhalb der Spezifikation der Nachrichtenaufbau und die Semantik festgelegt. Durch die Spezifizierung des Nachrichtenaufbaus ist der Zugriff auf Eigenschaften verschiedenster Ressourcen einheitlich. Quellcode 4.3: Nachrichtenaustausch für eine GetResourcePropertyDocument-Operation <!-- GetResourcePropertyDocumentRequest --> <SOAP-ENV:Body> <wsrf-rp:getresourcepropertydocument/> </SOAP-ENV:Body> <!-- GetResourcePropertyDocumentResponse --> <SOAP-ENV:Body> <wsrf-rp:getresourcepropertydocumentresponse> <ssc:simpleshoppingcart> <ssc:item> <ssc:productcode>cat-a </ssc:productcode> <ssc:description>garden String 150m</ssc:Description> <ssc:quantity>1</ssc:quantity> <ssc:productprice>1.59</ssc:productprice> </ssc:item> </ssc:simpleshoppingcart> </wsrf-rp:getpropertydocumentresponse> </SOAP-ENV:Body> Quelle: Banks (Dezember 2005), S. 16 Quellcode 4.3 zeigt die SOAP-Bodys der Anfrage und der Antwort für eine GetResource- PropertyDocument-Operation. Der Nutzen der einheitlichen Nachrichten, wird bei der Betrachtung der Anfrage deutlich. Die Anfrage ist für jeden WSRF-basierenden Web Service gleich. Lediglich die daraus resultierende Antwort unterscheidet sich. Im Codeausschnitt wird das Resource Properties Document einer Einkaufswagen-Ressource zurückgegeben. 37

40 38 Web Service Standards WS-ResourceLifetime Während Ressourcen wie beispielsweise ein Drucker dauerhaft vorhanden sind, unterliegen andere Ressourcen, wie beispielsweise einzelne Druckaufgaben, einem natürlichen Lebenszyklus. Die WS-ResourceLifetime-Spezifikation 69 behandelt diesen Lebenszyklus. Grundsätzlich unterscheidet die WS-ResourceLifetime-Spezifikation zwei unterschiedliche Arten eine WS-Resource zu zerstören. Bei der planmäßigen Terminierung, in der Spezifikation mit scheduled destruction bezeichnet, kann über standardisierte Nachrichten der Zeitpunkt festgelegt werden, an dem die WS-Resource zerstört wird. Bei der sofortigen Terminierung, der sogenannten immediate destruction, wird eine WS-Resource mittels einer Destroy-Nachricht direkt zerstört. WS-ResourceMetadataDescriptor Mit der WS-ResourceProperties-Spezifikation wurde ein Standard geschaffen, um einheitlich auf WS-Resources zugreifen zu können. Für den Aufruf einiger Operationen sind jedoch Kenntnisse über die Eigenschaften der Ressource erforderlich. Beispielsweise ist ein Aufruf der SetResourceProperty-Operation für eine Eigenschaft, die nur gelesen werden kann, nicht sinnvoll. Die WS-ResourceMetadataDescriptor-Spezifikation 70 versucht diesen Schwachpunkt auszumerzen, indem sie festlegt, wie Metadaten zu einer WS-Resource abgerufen werden können. Die WS-ResourceMetadataDescriptor-Spezifikation ist kein offizieller Bestandteil des WSRF, wurde aber vom Komitee der OASIS geprüft und freigegeben. Metadaten zu den Eigenschaften werden in ein XML-Dokument, dem Resource Metadata Descriptor, eingetragen. Beispiele für solche Metadaten sind die Zugriffsmöglichkeiten (readonly/read-write), die Veränderlichkeit (constant/appendable/mutable) oder Initialisierungswerte für eine Eigenschaft. Ein Nutzer erhält den Resource Metadata Descriptor für eine WS-Resource entweder über das WSDL-Dokument des Web Services oder über mit Hilfe der GetResourceProperty-Operation und einer bestimmten Resource Property, die den Resource Metadata Descriptor enthält. 69 Vgl. Srinivasan/Banks (April 2006) 70 Vgl. Jemiolo (November 2006) 38

41 Web Service Standards 39 WS-ServiceGroup Unter einer ServiceGroup ist laut WS-ServiceGroup-Spezifikation 71 folgendes zu verstehen: A ServiceGroup is a heterogeneous by-reference collection of Web services. Bei einer ServiceGroup handelt es sich um eine WS-Resource, die dazu verwendet werden kann, um ein Verzeichnis mit Referenzen auf andere WS-Resourcen zu erstellen. Die Einträge einer ServiceGroup werden als ServiceGroupEntry bezeichnet und sind als Resource Property in der ServiceGroup implementiert. Mit den Operationen der WS-ResourceProperties- Spezifikation ist es möglich, ServiceGroupEntrys hinzuzufügen, zu löschen und Abfragen durchzuführen. Durch die Verwendung von WS-BaseNotification 72 besteht außerdem die Möglichkeit, auf Ereignisse wie das Hinzufügen oder Löschen eines Eintrags zu reagieren. WS-BaseFaults Die Behandlung von Fehlern in Web Service Anwendungen ist ein schwieriges Unterfangen, wenn Entwickler Fehlernachrichten auf unterschiedliche Weise implementieren. Mit der WS- BaseFaults-Spezifikation 73 wird ein Basisfehlertyp eingeführt, der eine einheitliche Fehlerbehandlung in Tools verschiedener Hersteller möglich macht. Das WS-Resource Factory Pattern Es gibt eine nahezu unendlich große Anzahl an unterschiedlichen Ressourcentypen. Praktisch jedes Objekt in der Informationstechnik kann als Ressource und somit auch als WS-Resource modelliert werden. Verschiedene Typen von Ressourcen unterscheiden sich in mehreren Punkten. Der erste und markanteste Unterschied sind die Eigenschaften. Mit der WS-ResourceProperties-Spezifikation wurde festgelegt, wie die Eigenschaften einer WS-Resource dargestellt, abgefragt und geändert werden. Der zweite Punkt ist die Lebenszeit einer WS-Resource. Diese Thematik wird von der WS-ResourceLifetime-Spezifikation abgedeckt. Diese WS-ResourceLifetime-Spezifikation legt lediglich fest, wie WS-Resources zerstört werden 71 Vgl. Maguire/Snelling/Banks (April 2006), S Vgl. Abschnitt Vgl. Liu/Meder (April 2006) 39

42 40 Web Service Standards können, sie definiert jedoch nicht, wie die Erstellung von Resourcen mit WSRF erfolgen kann. Das folgende Beispiel einer Warenkorb-Ressource verdeutlicht die Erfordernis nach einem allgemeinen Konzept, um WS-Resources während der Laufzeit zu erstellen. Typischerweise wird ein Warenkorb einem einzelnen Benutzer zugewiesen, wenn er einen Einkauf startet. Um den Ressourcenverbrauch so gering wie möglich zu halten, ist es sinnvoll, dass eine Warenkorb-WS-Resource in dem Moment erstellt wird, in dem der Benutzer den ersten Artikel hineinlegt. Der Warenkorb wird idealerweise gelöscht sobald der Benutzer den Einkauf mit einer Bestellung abgeschlossen hat oder falls eine bestimmte Zeitdauer überschritten wurde. Abbildung 4.2: WS-Resource Factory Pattern Quelle: Sotomajor (2004), Abschnitt 5.1 Das WS-Resource Factory Pattern ist ein Entwurfsmuster, um Resourcen zur Laufzeit zu erstellen. Es teilt die Aufgabe der Ressourcenerstellung einem separaten Factory Service zu, der als auch als Resource Factory bezeichnet wird 74. Der Factory Service liefert als Ergebnis für eine Anfrage, eine Endpunktreferenz auf den Instance Service und die erzeugte Resource zurück. Mit dieser Referenz ist der Klient in der dazu in der Lage, Operationen auf der Ressource duchzuführen. 74 Vgl. Foster/Frey/Graham (2004), S

43 Web Service Standards 41 Abbildung 4.2 stellt das WS-Resource Factory Pattern noch einmal dar. Um eine neue Resource zu erstellen ruft der Client zuerst den Factory Service auf. Der Factory Service erstellt die Ressource 1 und gibt dem Client als Antwort eine Endpunktreferenz auf den Instance Service und die neu erstellte Resource 1 zurück. Mit dieser Referenz kann der Client über den Instance Service Operationen auf Resource 1 ausführen. 4.3 Web Services Notification (WSN) Wie WSRF handelt es sich bei der Web Services Notification (WSN) um einen von der OASIS eingeführten Industriestandard. Der WSN 75 -Standard besteht aus einer Gruppe von drei Spezifikationen 76 mit den Bezeichnungen WS-BaseNotification, WS-BrokeredNotification und WS-Topics. Mit dem WSN-Standard wird ein ereignisgesteuerter Interaktionsmechanismus für Web Services auf Grundlage des weit verbreiteten Notification-Patterns eingeführt, der nach dem Publish-Subscribe-Verfahren abläuft und auf sogenannten Topics beruht. Abbildung 4.3: Web Services Notification (WSN) Quelle: Vgl. Graham/Niblett/Chapell (2004), S. 14 Abbildung 4.3 zeigt das Publish&Subscribe-Prinzip des WSN-Standards. Subscriber A meldet den Consumer B beim Broker für Notifikationen des Topics SystemError an. Sobald Publisher X und Y eine Notifikation mit diesem Thema veröffentlichen, bekommen alle für das Topic angemeldeten Consumer die Notifikation zugesendet. 75 Web Services Notification (WS-Notification) 76 Vgl. 41

44 42 Web Service Standards 4.4 Zusammenfassung In diesem Kapitel wurden mehrere Web Service Standards beschrieben. Folgende Erkenntnisse wurden gewonnen: Mit WS-Addressing können Web Services unabhängig vom verwendeten Transportprotokoll adressiert werden. Eine WS-Resource ist die Komposition von einem Web Services und einer Ressource, deren Eigenschaften im XML-Format in einem Resource Properties Document beschrieben werden. Die WS-ResourceProperties-Spezifikation stellt Nachrichten vor, durch die der Zugriff auf die Eigenschaften einer Ressource vereinheitlicht wird. Die WS-ResourceLifetime-Spezifikation beschreibt, wie Ressourcen planmäßig oder direkt zerstört werden können. In der WS-ResourceMetadataDescriptor-Spezifikation wird aufgezeigt, wie Metadaten einer Ressource beschrieben und abgefragt werden. Eine WS-ServiceGroup ist eine WS-Resource in der Referenzen auf mehrere WS-Resourcen abgelegt, ausgelesen und gelöscht werden können. Die WS-BaseFault-Spezifikation führt einen einheitlichen Basisfehlertyp ein, durch den die Fehlerbehandlung standardisiert wird. Das WS-Resource Factory Pattern ist ein Entwurfsmuster um Ressourcen im Sinne des WSRF 'on demand' zu erstellen. Die Ressourcen werden über einen separaten Web Service, auch Resource Factory genannt, erstellt. Der WS-Notification-Standard (WSN) ist eine Implementierung des Notification-Entwurfsmusters für Web Services. Mit Hilfe des Web Service Resource Framework ist es möglich zustandsbehaftete Web Services zu erstellen. In Kapitel 6 wird mit der WSRF-Implementierung Apache Muse ein einfacher Web Service erstellt. 42

45 Serverapplikationen 43 Kapitel 5: Serverapplikationen Um Serveranwendungen problemlos migrieren zu können, müssen einzelne Typen von Anwendungen näher untersucht werden. Für eine einfache Applikation, wie beispielsweise eine Webapplikation, die aus statischen HTML 77 -Seiten besteht, ist die Migration bzw. das Merging trivial, da es keine Abhängigkeiten und Zustandsinformationen gibt. Bei komplexeren Anwendungen mit Sitzungsdaten, Datenbankzugriffen oder Verbindungen zu Legacy-Systemen, ist die Migration jedoch schwierig. In diesem Kapitel werden typische Serverapplikationen untersucht, bezüglich ihrer Migrationsfähigkeit beurteilt und Lösungsmöglichkeiten für die Migration angeboten. 5.1 Eigenschaften Wie in Abschnitt beschrieben werden Serverapplikationen je nach Typ in unterschiedliche Archive gepackt. Berücksichtigt man die für die Anwendung angewandten Technologien und deren Eigenschaften, können einzelne Applikationen weiter differenziert werden. Im folgenden werden drei Eigenschaften von Serverapplikationen bzw. Servertechnologien beschrieben, die bezüglich der Migration von Serverapplikationen eine Rolle spielen. stateless vs stateful Die Worte stateless bzw. stateful bedeuten übersetzt zustandslos bzw. zustandsbehaftet. Zustände spielen in der Informationstechnik eine wichtige Rolle. Zustandslose und zustandsbehaftete Dienste weisen in vielerlei Hinsicht ein unterschiedliches Verhalten auf. Unter dem Zustand einer Applikation versteht man die Daten einer Applikation, die über einen längeren Zeitraum vorhanden sind, also als Klassenattribute vorhanden sind. Bei der Migration einer Serverapplikation ist es sinnvoll, Applikationen zusammen mit ihren Zuständen zu migrieren. Bei einem zustandslosen Dienst entfällt dieser Schritt und die Migration ist nicht so umfangreich und zeitaufwendig. 77 HyperText Markup Language 43

46 44 Serverapplikationen Abbildung 5.1: Stateless Service vs Stateful Service In Abbildung 5.1 werden zwei Ausführungen eines einfachen Dienstes, der Zahlen addiert, dargestellt. In der links gezeigten zustandslosen Variante besitzt der Dienst eine Operation Add, die zwei Zahlen als Parameter entgegennimmt, diese addiert und das Ergebnis an den Client zurückliefert. Der Dienst ist stateless, da die einzelnen Dienstaufrufe völlig unabhängig voneinander sind und der Dienst weder einen Parameter noch das Ergebnis im Speicher behält. Bei der rechts gezeigten, zustandsbehafteten Variante des Dienstes wird lediglich ein Parameter für die Operation benötigt, da der Dienst das Ergebnis aus jedem Aufruf im Speicher festhält. Bei einem später folgenden Aufruf benutzt der Dienst den gespeicherten Wert als Grundlage für die Addition. Obwohl die links gezeigte Variante keine serverseitigen Zustände erlaubt, ist es möglich eine insgesamt gesehen zustandsbehaftete Anwendung zu erschaffen. In diesem Fall übernimmt die Klientenanwendung die Verwaltung der Zustände. In der dargestellten Grafik speichert der Klient die Antwort einer ersten Anfrage und benutzt diese als einen Parameter für einen zweiten Aufruf. statisch vs dynamisch Die Eigenschaften statisch und dynamisch werden häufig für Webanwendungen angewandt 78. Beim Aufruf einer statischen Webseite steht die Antwort bereits vor der Anfrage fest. In der Regel liest der Webserver lediglich eine HTML-Datei aus und gibt diese als Antwort zurück. Das Verhalten dynamischer Webseiten ist komplexer: bei dieser Form erzeugt ein Prozessor für jede Anfrage eine separate Antwort. Diese Antworten können sich voneinander unterscheiden, sie müssen es aber nicht. Für die Generierung einer Antwort greift der Prozessor 78 Vgl. A Comparison of Static and Dynamic Websites ( ) 44

47 Serverapplikationen 45 auf serverseitige Ressourcen, wie beispielsweise Dateien, Datenbanken und interne Applikationsdaten (Zustände) zurück. Die Migration einer statischen Webanwendung Abbildung 5.2: statisch & dynamisch stellt kein Problem dar, da eine statische Webanwendung keinen Zustand besitzt. Um lauffähig zu sein, werden lediglich die im Webarchiv enthaltenen HMTL-Dateien benötigt. Die Migration von dynamischen Webanwendung ist komplizierter. Dynamische Webseiten können so kodiert werden, dass sie zwar dynamisch erzeugt werden, sich aber dennoch wie eine statische Webseite verhalten. Ein Beispiel hierfür ist ein HttpServlet, das nur festkodierte HTML-Tags und festkodierten, einfachen Text als Antwort schreibt. In diesem Fall kann auch die dynamische Webanwendung bedenkenlos migriert werden. Es gibt weitere zahlreiche Ausnahmen, in denen die Migration einer dynamischen Webanwendungen möglich ist. Ein Servlet, dessen Antwort das aktuelle Datum oder die Uhrzeit enthält, gibt zwar nicht immer dieselbe Antwort wie eine statische Webseite zurück. Da es sich bei Datum und Uhrzeit jedoch um eine universelle Ressource handelt kann auch dieses Servlet problemlos migriert werden. Abhängigkeiten In einem Großteil der Fälle sind Serverapplikationen nicht selbständig lauffähig. Meistens benötigen sie andere Komponenten. Solche Komponenten können bestimmte Java-Bibliotheken, Java-EE-Anwendungen, Datenbanken oder Legacy-Systeme sein. In Abbildung 5.3 ist die Architektur einer typischen Java EE Anwendung dargestellt. Die gerichteten Pfeile symbolisieren Abhängigkeiten unter einzelnen Komponenten. Für jede Komponente besteht ein Baum aus Abhängigkeiten. Beispielsweise benötigt die im Web Container befindliche Webanwendung für einen korrekten Ablauf beide Businessanwendungen, die Datenbank und das Legacy-System. 45

48 46 Serverapplikationen Abbildung 5.3: Beispiel für Abhängigkeiten in einer Java EE Applikation Für die Migration von Serverapplikationen ist es notwendig, dass Abhängigkeiten erkannt und berücksichtigt werden. Damit eine Serverapplikation nach ihrer Migration auf einem Zielsystem funktionsfähig ist, müssen die Abhängigkeiten aufgelöst werden können. Um die nach außen sichtbaren Abhängigkeiten zu reduzieren, ist es sinnvoll die Komponenten einer Applikation zu einem Applikationsarchiv zusammenzufassen. Das Applikationsarchiv verhält sich später beim Deployment wie eine einzelne Komponente. Dadurch wird die Komplexität reduziert. Abhängigkeiten zu Systemen des EIS-Tier stellen auch bei Benutzung eines Applikationsarchiv weiterhin ein Problem dar. Eine Methode, wie dieses Problem umgangen werden kann ist eine entsprechende Adressierung des jeweiligen Systems innerhalb der Anwendung. 5.2 Statische Webapplikationen Grundsätzlich werden zwei Typen von Webanwendungen bzw. Webseiten unterschieden. Statische Webanwendungen enthalten Dateien, in den meisten Fällen im HTML-Format, die über einen Webserver bereitgestellt werden. Bei dynamischen Webanwendungen werden die Inhalte auf dem Webserver beim Erhalt einer Anfrage automatisch erzeugt. Zur Generierung von dynamischen Inhalten stellt die Java EE Servlets, Java Server Pages (JSP) und weitere Technologien bereit. 46

49 Serverapplikationen 47 Abbildung 5.4: Migration einer statischen Webanwendung Für statische Webanwendungen ist die Migration trivial. Statische Webanwendungen besitzen keinen Zustand. Abbildung 5.4 verdeutlicht, dass statische Webanwendungen auf mehreren Servern installiert werden können, ohne dass dabei Unterschiede zwischen einzelnen Instanzen entstehen. Die einzelnen Instanzen weisen exakt dasselbe Verhalten auf. 5.3 Servlets Servlets sind ein beliebtes Mittel um dynamische Webinhalte zu generieren. Sie können jegliche Art von Java-Code enthalten, wodurch sie sehr flexibel einsetzbar sind. Servlets an sich sind zustandslos. Sie können zwar Daten in Form von Attributen enthalten, da Servlets jedoch von einem Container erstellt werden und dieser alle Klientenanfragen auf eine einzige Servletinstanz 79 abbildet, bezieht sich der Zustand eines Servlets nicht auf den aktuellen Klienten sondern auf das Servlet selbst. Um Zustände wie Sitzungen dennoch serverseitig verwalten zu können, stellt die Servlet API mehrere Scope Objekte bereit. Scope Objekte können Daten in Form von Objekten aufnehmen. Diese Objekte können von anderen Webkomponenten wieder abgerufen werden. 79 Anm. des Verfassers: bzw. auf eine Instanz aus einem Pool von Servletinstanzen 47

50 48 Serverapplikationen Tabelle 5.1: Scope-Objekte der Servlet API Scope Object Class Accessible from Web context javax.servlet.servletcontext Web components within a web context. Session javax.servlet.http.httpsession Request subtype of javax.servlet.servletrequest Web components handling a request that belongs to a session. Web components handling the request. Page javax.servlet.jsp.pagecontext The JSP page that creates the object. Quelle: Jendrock/Ball/Carson et al. (2006), Chapter 3, Sharing information Bezüglich benutzerspezifischer Zustände, spielt vor allem die HttpSession API eine wichtige Rolle. Apache Tomcat stellt einen Mechanismus bereit, mit dem Sitzungsdaten von mehreren Tomcat-Instanzen in einem Cluster geteilt werden können. Dies ist beispielsweise über eine gemeinsame Datenbank oder Replikation der Daten möglich. Dieser Mechanismus wird dazu verwendet, um beim Ausfall eines Tomcat-Servers die dort begonnenen Sitzungen auf einem anderen Tomcat-System weiterzuführen 80. Wie für alle anderen Technologien, die Zustände unterstützen, gilt auch für Servlets, dass Zustände auf vielfältige Art und Weise übertragen werden können. Für die Übertragung der Zustandsdaten werden nur Schnittstellen benötigt, die in der Lage sind, Zustände einer Anwendung abzurufen und wiedereinzubinden. Im Fall von Servlets wäre es denkbar, eine Servlet-Unterklasse zu erstellen, die diese Operationen enthält. 5.4 WS-Resources Mit der Hilfe des Web Service Resource Frameworks (WSRF) kann über einen Web Service standardisiert auf Ressourcen zugegriffen werden. In Kapitel 4.2 wurde der Begriff WS-Resource als die Komposition von einem Web Service und einer Ressource eingeführt. Prinzipiell gibt es zwei unterschiedliche Szenarien für die Migration von WS-Resources: bei der ersten Variante werden die WS-Resources beim Deployment initialisiert und sind für die gesamte Laufzeit des Services vorhanden. Die zweite Variante nutzt das ebenfalls in Kapitel 4.2 beschriebene WS-Resource Factory Pattern, um WS-Resources zu erstellen. 80 Vgl. Apache Tomcat Clustering/Session Replication HOW-TO ( ) 48

51 Serverapplikationen 49 Dauerhafte WS-Resource Eine dauerhafte WS-Resource ist eine Ressource, die für die gesamte Laufzeit einer Applikation bekannt ist. Die Ressource wird beim Deployment oder beim ersten Aufruf mit Standardwerten initialisiert. Wenn Operationen auf der WS-Resource ausgeführt werden, ändern sich diese Werte. Wird ein Web Service, der WS-Resources enthält, migriert, dann ist es je nach Anwendung sinnvoll, die geänderten Werte der Ressource-Eigenschaften ebenfalls zu übertragen. Um dies zu bewerkstelligen stellt das WSRF zahlreiche Operationen bereit. Wie die WS-Resource-Eigenschaften schlussendlich übertragen werden, ist abhängig von den unterstützten WSRF-Operationen der WS-Resource. Die Operation GetResourceProperty muss von allen WSRF-konformen Web Services implementiert werden 81. Mit dem GetResourceProperty-Nachrichtenaustausch kann eine bestimmte Eigenschaft einer WS-Resource abgefragt werden. Als Parameter wird der qualifizierte Name der Eigenschaft aus dem Resource Properties Document benötigt. Da dieser nicht allgemein bekannt ist, ist es notwendig, dass zunächst Informationen über die WS-Resource-Eigenschaften gewonnen werden. Dafür bieten sich zwei Methoden an: 1. Über das WSDL-Dokument und das Resource Properties Document 2. Mittels WS-MetadataDescriptor Sobald die Eigenschaften einer WS-Resource bekannt sind, können die Werte mit Hilfe der GetResourceProperty-Operation abgefragt werden. Um die Werte von einer WS-Resource auf eine andere zu übertragen, werden die aus der GetResourceProperty-Operation gewonnen Daten als Parameter für eine SetResourceProperties-Operation verwendet. Mit der SetResourceProperties-Operation können mehrere Eigenschaften einer WS-Resource innerhalb eines einzigen Nachrichtenaustauschs verändert werden. Besitzt die zu übertragende WS-Resource sehr viele Eigenschaften kann die Anzahl der benötigten GetResourceProperty- Aufrufe sehr hoch sein. Mit der GetMultipleResourceProperties-Operation stellt das WSRF ein Pendant zur SetResourceProperties-Operation zur Verfügung, mit dem mehrere Eigenschaften in einem Nachrichtenaustausch angefragt werden können. 81 Vgl. 49

52 50 Serverapplikationen Abbildung 5.5: Get- bzw. SetResourceProperties-Methode Abbildung 5.5 stellt die Übertragung einer WS-Resource-Eigenschaft in einem Sequenzdiagramm dar. Für die Übertragung einer Eigenschaft mit der GetResourceProperty-Operation werden drei Nachrichtenwechsel benötigt. Für jede weitere Eigenschaft muss ein weiterer Nachrichtentausch hinzugefügt werden. Durch Benutzung der GetMultipleResourceProperties-Operation kann die Anzahl an nötigen Operationen konstant auf drei gehalten werden. Abbildung 5.6: PutResourcePropertyDocument-Methode Eine weitere Methode ist die Benutzung der WSRF-Operationen GetResourceProperty- Document bzw. SetResourcePropertyDocument. Bei dieser Methode werden die Eigenschaften mit je einem Aufruf auf der Quell- und Zielressource übertragen. Die GetResource- PropertyDocument-Operation liefert als Antwort eine Instanz des Resource Properties Document zurück, das die aktuellen Eigenschaftswerte der WS-Resource enthält. Durch die Verwendung dieser beiden Operationen entfällt der Schritt der Metadatenabfrage, da keine Kenntnisse über die Ressource erforderlich sind. Abbildung 5.6 stellt den Ablauf in einer 50

53 Serverapplikationen 51 vereinfachten Ansicht, analog zu der zuvor beschriebenen Get- bzw. SetResourceProperties- Methode, dar. Resource Factory Bei einer Resource Factory handelt es sich um einen Bestandteil des in Kapitel 4.2 beschriebenen WS-Resource Factory Patterns, mit dessen Hilfe Ressourcen zur Laufzeit erstellt werden. Die Verwendung einer Resource Factory hat Folgen für die Migration einer Applikation: durch die fortlaufende Ressourcen-Erstellung entstehen ständig neue WS-Resources, deren Eigenschaften bei einer Migration übertragen werden müssen. Die Abfrage und Übertragung kann zwar nach dem im letzten Abschnitt beschriebenen Verfahren erfolgen, jedoch wird für die erforderlichen Methodenaufrufe eine Endpunktreferenz benötigt. Endpunktreferenzen werden beim WS-Resource Factory Pattern aber nur dem Ersteller der WS-Resource bekanntgemacht. Um die Zustände aller WS-Resources einer Applikation zu migrieren, wird eine Methode benötigt, mit deren Hilfe die Endpunktreferenzen für die vorhandenen WS-Resources festgestellt werden können. Eine weitere Anforderung für die Migration ist die Neuerstellung von WS-Resourcen mit einem vorgegebenen Identifikator. Im Normalfall bekommen Ressourcen bei ihrer Erstellung automatisch einen Identifikator zugewiesen, der für die Adressierung mit dem Implied Resource Pattern 82 benutzt wird. Da WS-Resources bei der Migration auf dem Zielsystem zuerst erstellt werden müssen, muss die Resource Factory es erlauben, eine neue Ressource mit der Resource-ID der Quell-Ressource zu erstellen, damit der Zugriff weiterhin über dieselbe Resource-ID erfolgen kann. Um Referenzen auf WS-Resources zu verwalten bietet sich eine ServiceGroup 83 an. Dazu wird bei der Erstellung einer neuen Ressource ein Eintrag in die ServiceGroup eingefügt. Analog dazu wird der Eintrag gelöscht, wenn die dazugehörige Ressource zerstört wurde. Abbildung 5.7 zeigt eine Anwendung mit einer ServiceGroup. Bei der Erstellung einer neuen Ressource wird automatisch ein entsprechender Eintrag in der ServiceGroup erstellt. Über einen standardisierten Nachrichtenaustausch kann ein Client die Einträge einer Service- Group auslesen und dazu benutzen, Operationen auf einer WS-Resource durchzuführen. 82 Vgl. Abschnitt Vgl. Abschnitt

54 52 Serverapplikationen Abbildung 5.7: Benutzung einer ServiceGroup Eine andere Möglichkeit WS-Resource-Referenzen zu verwalten, kann mit WS-Notification erreicht werden. Wenn der Lebenszyklus von Ressourcen auf Serverseite überwacht wird und bei der Erstellung und der Zerstörung einer Ressource eine Notifikation erzeugt wird, dann ist es möglich in einer Klientenanwendung eine Liste mit WS-Resource-Referenzen aufzubauen. Abbildung 5.8 stellt dieses Konzept grafisch dar. Die Schnittstellen Notification- Producer und NotificationConsumer sind Bestandteil der WS-Notification-Spezifikation. Der NotificationProducer ist in der Lage bei bestimmten Ereignissen Notifikationen zu erzeugen und an die registrierten NotificationConsumer zu übermitteln. Die Notifikation muss die Endpunktreferenz der entsprechenden WS-Resource enthalten. Die Klientenanwendung kann den Inhalt der Notifikationen auswerten und dadurch ein Register mit verfügbaren WS-Resource-Referenzen anlegen. Die beiden dargestellten Verfahren weisen mehrere Unterschiede auf. Tabelle 5.2 fasst diese Unterschiede zusammen. Der Hauptunterschied zwischen beiden Verfahren liegt im Standort des Referenzenregisters. Die WS-Notification-Methode besitzt einen Nachteil: Die Client-Applikation enthält lediglich die WS-Resource-Referenzen, die während ihrer Laufzeit erstellt wurden. 52

55 Serverapplikationen 53 Abbildung 5.8: Verwaltung von Referenzen auf WS-Resources mit WS-Notification Tabelle 5.2: Vergleich von Verfahren zur Verwaltung von WS-Resource-Referenzen Verfahren WS-ServiceGroup WS-Notification Standort des Referenzenregisters Server Client Zugriff auf Referenzen Standardisiert (WSRF) Programmatisch Flexibilität Gering Hoch Implementierungsaufwand Gering Mittel-Hoch Drawbacks - Referenzen auf Ressourcen, die außerhalb der Laufzeit der Client- Applikation erstellt wurden, sind nicht im Register enthalten Unabhängig vom verwendeten Verfahren, um die WS-Resource-Referenzen einer Applikation zu erhalten, unterscheidet sich der Migrationsablauf bei der Verwendung einer Resource Factory von den in Abbildung 5.5 und Abbildung 5.6 dargestellten Abläufen. Das liegt daran, dass bei der Verwendung einer Resource Factory, die Ressourcen auf dem Zielsystem zuerst erstellt werden müssen. Erst anschließend können die Eigenschaften übertragen werden. Abbildung 5.9 zeigt den Ablauf für die Migration von einer oder mehreren WS-Resources in einem Sequenzdiagramm. Zuerst werden die Referenzen für die erstellten WS-Resources abgefragt. Anschließend werden die Eigenschaftswerte mit der PutResourceProperty- Document-Methode übertragen. 53

56 54 Serverapplikationen Abbildung 5.9: Migration bei der Verwendung einer Resource Factory Die in der Abbildung verwendeten Verfahren zur Erfassung der WS-Resource-Referenzen und zur Übertragung der WS-Resource-Eigenschaften können durch die zuvor beschriebenen analogen Verfahren ersetzt werden. 5.5 JPA Entities In Kapitel wurde die Java Persistence API und das Konzept von Entities beschrieben. Entities sind einfache Java-Klassen, die Daten in Form von Attributen enthalten. Durch Annotationen werden die Daten auf ein Datenbankmodell abgebildet. Entities unterliegen durch ihre Bindung zu einem EntityManager einem festen Lebenszyklus. Abbildung 5.10 stellt diesen Lebenszyklus dar. Es werden vier Zustände unter- Abbildung 5.10: Entity Lifecycle Quelle: vgl. Sriganesh/Brose/Silverman (2006), S

57 Serverapplikationen 55 schieden: new, managed, detached und removed. Die Transitionen zwischen den Zuständen sind als Pfeil dargestellt und mit einer EntityManager-Methode gekennzeichnet. Für das Merging von CounterEntities sind zwei Zustände besonders interessant. Im Managed -Zustand ist die Entity an einen EntityManager gebunden, der die Entity verwaltet. Im Detached -Zustand hat die Entity den PersistenceContext des EntityManagers verlassen. Der EntityManager stellt die merge-methode bereit, mit der eine detached Entity wieder in einen PersistenceContext eingegliedert werden kann. Da Entities einfache Java-Klassen sind und auch die Serializable-Schnittstellen implementieren können, ist es möglich Entities zu serialisieren. Dadurch verlässt die Entity den PersistenceContext und wird detached. Zu einem späteren Zeitpunkt kann die Entity deserialisiert und über die merge-methode wieder in den PersistenceContext eingegliedert werden. Auf diese Weise ist auch möglich Entities zwischen verschiedenen Instanzen einer Anwendung zu übertragen. Die Applikation benötigt lediglich zwei Schnittstellen: eine Schnittstelle, die den Export von serialisierten Entities erlaubt und eine weitere Schnittstelle, die die serialisierten Entities entgegennimmt, deserialisiert und in den PersistenceContext der Anwendung eingliedert. Auf diese Weise kann ein einfaches Merging von JPA Entities erzielt werden. 5.6 Datenbanken Datenbanken sind eine beliebte und effektive Methode für die persistente Datenhaltung. Sollen Serverapplikationen mit einem Datenbank-Backend migriert werden, muss eine Möglichkeit gefunden werden, wie die Informationen aus der Datenbank auf dem Zielsystem bereitgestellt werden. Die folgenden Abschnitte enthalten Denkansätze, wie die Migration einer Datenbank erfolgen bzw. umgangen werden kann. Geeignete Connection Strings In vielen Fällen werden Datenbanken auf einer selbständigen Servermaschine betrieben. In solchen Situationen erfolgt der Datenbankzugriff über die Netzwerkschnittstelle des Datenbanksystems. Der Zugriff auf Datenbanken wird in der Programmiersprache Java in der Regel mit JDBC 84 durchgeführt. Eine JDBC-Datenbankverbindung wird mittels eines Connection 84 Java Database Connectivity 55

58 56 Serverapplikationen Strings eingeleitet. Beim Datenbankzugriff über das Netzwerk, enthält der Connection String den Hostnamen oder die IP-Adresse. Wird in einer Applikation ein entsprechender Connection String für die Datenbankverbindung verwendet, dann kann diese Applikation problemlos auf einen anderen Server innerhalb desselben Netzwerks migriert werden. Abbildung 5.11: Distributed Persistence Layer Verteilte Persistenzschicht Einige Java EE Server bieten integrierte Datenbanken an, die von Anwendungen für die persistente Datenhaltung verwendet werden können. Für dieses Szenario ist eine Lösung praktikabel, die es erlaubt, dass eine Anwendungsinstanz die lokal vorhandene Datenbank verwendet, im Falle einer Migration jedoch auf die Daten von einer anderen Anwendungsinstanz zugreifen kann. Abbildung 5.11 stellt einen Distributed Persistence Layer vor, der es einzelnen Anwendungsinstanzen ermöglicht, auf die Datenbestände anderer Anwendungsinstanzen zuzugreifen. Der Distributed Persistence Layer bietet dafür eine Schnittstelle an, mit der Daten abgerufen und manipuliert werden können. Die Verwaltung der verteilten Datenbestände übernimmt der Distributed Persistence Layer in vollem Umfang, so dass es aus der Perspektive der Anwendung nicht ersichtlich ist, wo sich die Daten befinden. Mit Hibernate 85 und Tangosol Coherence 86 existieren am Markt zwei Produkte, die dieses Kon

59 Serverapplikationen 57 zept ansatzweise implementieren. Beide Produkte besitzen einen Cache-Mechanismus, mit dessen Hilfe Ergebnisse von Datenbankabfragen in einer verteilten Umgebung repliziert werden. SQL-Dump Bei den beiden bisher genannten Methoden handelt es sich ausschließlich um Workarounds, also Möglichkeiten durch die die Migration einer Datenbank umgangen wird. In bestimmten Situationen kann es aber vorkommen, dass der Inhalt einer Datenbank in gesamtem Umfang auf ein System migriert werden muss. Die meisten Datenbankhersteller liefern ihre Datenbankprodukte mit einigen nützlichen Werkzeugen aus. Zu diesen Werkzeugen zählt in den meisten Fällen auch ein SQL 87 -Dump-Tool 88, mit dem das Schema und die Einträge einer Datenbank in einer Text-, XML- oder CVS-Datei gesichert werden können. Mit einem weiteren Werkzeug kann die generierte Datei später dazu verwendet werden, die Datenbank wiederherzustellen. 5.7 Legacy-Systeme Legacy-Systeme sind Systeme, die nicht Bestandteil eines Java EE Servers sind. Es handelt sich dabei in der Regel um Applikationen oder ganze Systeme, die auf veraltete Technologien setzen oder für ein besonderes Betriebssystem bzw. in einer alten Programmiersprache wie Cobol oder Assembler geschrieben wurden. Oft bieten diese Systeme spezialisierte Schnittstellen an, die wenig dokumentiert sind und für die kein Quellcode vorhanden ist 89. Die Migration von Legacy-Systemen ist problematisch. Mit einem J2EE Resource Adapter kann zwar eine Schnittstelle für das Legacy-System geschaffen werden, die auf mehreren Java EE Servern installiert werden kann, diese Methode eignet sich jedoch nur für Legacy- Systeme, die über eine Netzwerkschnittstelle verfügen. Legacy-Systeme, die lokal auf einem Java EE Server vorhanden sind, können nur schwer migriert werden. Um die Legacy-Anwendung zu migrieren, muss sie auf dem Zielsystem installiert und gestartet werden. Au- 87 Structured Query Language 88 Anm. des Verfassers: Für MySQL vgl Vgl. What is legacy application? ( ) 57

60 58 Serverapplikationen ßerdem muss das Legacy-System Schnittstellen bereitstellen, mit denen der Zustand der Legacy-Applikation festgestellt und übertragen werden kann. 5.8 Zusammenfassung In diesem Kapitel wurden zuerst die Eigenschaften von typischen Serverapplikationen beschrieben. Zustandsbehaftete Serverapplikationen speichern Zustände über mehrere Anfragen hinweg und erfordern einen erhöhten Aufwand bei der Migration. Dagegen sind statische Webapplikation sehr leicht zu migrieren. Dynamische Anwendungen sind in sehr vielen Fällen von anderen Komponenten oder Systemen abhängig. Diese Abhängigkeiten müssen bei einer Migration berücksichtigt werden. Im weiteren Verlauf des Kapitels wurden einige ausgewählte Technologien aus der Java EE Umgebung ausgewählt und ihre Eigenschaften bezüglich ihrer Migrationsfähigkeit beurteilt. Tabelle 5.3 Zeigt einen Überblick. 58

61 Serverapplikationen 59 Tabelle 5.3: Anwendungskomponenten und ihre Migrationsfähigkeit Komponente Eigenschaften Migration Statische Webapplikation Servlets (stateless) Servlets (mit HttpSession-Nutzung) WS-Resources JPA Entities Datenbanken Legacy-Systeme statisch, stateless, unabhängig dynamisch, stateless, (un)abhängig dynamisch, stateful, (un)abhängig dynamisch, stateful, (un)abhängig dynamisch, stateful, abhängig dynamisch, stateful, unabhängig dynamisch, stateful, (un)abhängig Einfach die Anwendung auf dem Zielsystem installieren und auf dem Quellsystem deinstallieren. Vgl. statische Webapplikation Entweder manuelle Übertragung der Sitzungsdaten oder Verwendung einer gemeinsamen Sitzungsdatenbank bzw. Replikation der Sitzungsdaten im Tomcat-Cluster Bei bekannten WS-Resources einfach über WSRF- Standardoperationen. Bei der Verwendung einer WS-Resource Factory müssen zunächst die vorhandenen WS-Resources ermittelt werden. Die Entity-Klassen mit der Serializable-Schnittstelle markieren und auf dem Quellsystem serialisieren. Auf dem Zielsystem deserialisieren und mit der merge-methode des EntityManagers wieder einbinden. Entweder mit einer gemeinsamen Datenbank oder einer verteilten Persistenzschicht ein Workaround wählen oder über ein SQL-Dump die Datenbank auf dem Zielsystem neu erstellen. Hier hilft nur ein Workaround, z. B. mit einem Resource Adapter. 59

62 60 Stateful Web Services Kapitel 6: Stateful Web Services Es gibt zahlreiche unterschiedliche Methoden, wie Stateful Web Services implementiert werden können. In diesem Kapitel wird zunächst ein sehr einfacher Stateful Web Service vorgestellt. Anschließend werden zwei Implementierungsweisen für diesen Web Service beschrieben. Die erste Implementierung nutzt die Java Persistence API, welche Teil der neuen EJB3-Spezifikation Version 3 ist, um einen internen Zustand darzustellen. Die zweite Implementierung verwendet das Web Service Resource Framework 90, einen von der OASIS eingeführten Industriestandard. Für beide Varianten wird gezeigt, wie im Falle einer Migration Zustandsdaten übertragen werden können. 6.1 Der CounterService Ein sehr einfacher Stateful Web Service ist der im folgenden beschriebene CounterService. Dieser Web Service stellt eine Operation bereit, die es erlaubt einen im Web Service befindlichen Zähler um einen bestimmten Wert zu erhöhen. Mit dem W3C-Standard WSDL 91 werden die Operation und die dafür benötigten Nachrichten und Typen in einem WSDL-Dokument beschrieben. In Anhang D befindet sich das WSDL-Dokument für den CounterService. Darin wird eine Operation raise beschrieben, die einen Ganzzahlwert als Parameter entgegennimmt und einen Ganzzahlwert zurückgibt. Abbildung 6.1: Aufruf des CounterService 90 Vgl. Kapitel Web Service Description Language: XML-Spezifikation zur Beschreibung von Web Services 60

63 Stateful Web Services 61 Abbildung 6.1 stellt die Funktionsweise des CounterService dar. Die Raise-Operation nimmt einen Ganzzahlwert (2) als Parameter entgegen. Dieser Wert wird intern auf einen Zähler (3) aufaddiert und der aktuelle Zählerstand (3+2=5) zurückgegeben. 6.2 Implementierung mit JAX-WS und JPA Die Java API for XML-Based Web Services (JAX-WS) ist eine Java EE 5 API, mit deren Hilfe Web Services auf einfache Weise mittels Annotationen erstellt werden können 92. Für die Darstellung des Zählerstandes wird eine Entity verwendet. Bei einer Entity handelt es sich, wie in Kapitel beschrieben um eine einfache Java-Klasse, die mit speziellen Annotationen versehen wurde. Der Web Service führt mit Hilfe eines EntityManagers Persistenzoperationen aus. Für die Datenbankverbindung muss ein XML-Deskriptor erstellt werden, der die notwendigen Verbindungsinformationen enthält. Abbildung 6.2: CounterService mit JAX-WS und JPA 92 Vgl. Kohlert/Gupta (2007) 61

64 62 Stateful Web Services Abbildung 6.2 zeigt einen Überblick über die Architektur des CounterService auf Basis der APIs JAX-WS 93 und JPA. Für die persistente Datenhaltung wird die interne Derby-Datenbank von Apache Geronimo verwendet. CounterService Web Services können mit der JAX-WS API auf sehr einfache Weise erstellt werden. Es müssen lediglich eine Java-Schnittstelle und eine Java-Klasse implementiert und mit JAX-WS- Annotationen versehen werden. Eine dieser Annotationen ist beispielsweise die vor die Klassendefinition gesetzt wird und diese kennzeichnet. In der Version 2.0 M6 RC1 hat Apache Geronimo Probleme mit JAX-WS Web Services, weshalb eine ganze Reihe weiterer Klassen angelegt werden müssen 94. CounterEntity Die CounterEntity-Klasse ist eine einfache Java-Klasse, bestehend aus einem Standardkonstruktor, Attributen und Getter- bzw. Setter-Methoden. Um die erstellte Java-Klasse zu einer Entity-Klasse zu machen, müssen einige in der JPA definierten Annotationen in die Klasse eingesetzt werden. Die wird vor die Klassendefinition gesetzt und gibt an, dass die folgende Klasse eine Entity ist. Mit der Annotation Eid wird das Attribut markiert, welches als Identifikator dient. Mit weiteren Annotationen, wie kann das OR-Mapping für die Entity beeinflusst werden. Eine nützliche Annotation ist mit deren Hilfe eine Entity um Callback-Operationen erweitert werden kann. Mit einem EntityListener kann der Lebenszyklus einer Entity überwacht werden. XML-Deskriptor: persistence.xml Um Persistenzoperationen mit der JPA auszuführen wird eine PersistenceUnit benötigt 95. Die PersistenceUnit wird in einem XML-Deskriptor persistence.xml konfiguriert. Der XML-De- 93 Java API for XML-based Web services 94 Anm. des Verfassers: Als Grundlage für die Erstellung des JAX-WS-CounterService wurde die abgeänderte Geronimo-Beispielapplikation verwendet, die unter verfügbar ist. Es ist davon auszugehen, dass kommende Geronimo-Releases eine bessere JAX-WS- Unterstützung bieten. 95 Vgl. Abschnitt

65 Stateful Web Services 63 skriptor muss im Applikationsarchiv an der korrekten Stelle platziert werden 96, damit JPA die Konfigurationsdaten auslesen kann. Der folgende Codeauschnitt Quellcode 6.1 zeigt den XML-Deskriptor für den CounterService an. Quellcode 6.1: persistence.xml für CounterService <?xml version="1.0" encoding="utf-8"?> <persistence xmlns=" xmlns:xsi=" version="1.0" xsi:schemalocation=" <persistence-unit name="counterpu"> <description>entity Beans for CounterService</description> <provider>org.apache.openjpa.persistence.persistenceproviderimpl</provider> <class>merge.samples.ejb.counterentity</class> <properties> <property name="openjpa.connectionurl" value="jdbc:derby:counterdb;create=true" /> <property name="openjpa.connectiondrivername" value="org.apache.derby.jdbc.embeddeddriver" /> <property name="connectionusername" value="app" /> <property name="openjpa.jdbc.synchronizemappings" value="buildschema" /> </properties> </persistence-unit> </persistence> Neben dem Namen der PersistenceUnit (CounterPU) und der Entity-Klasse (CounterEntity) wird im XML-Deskriptor auch der PersistenceProvider festgelegt. Wie bei den meisten anderen Java-APIs sind auch für die JPA zahlreiche verschiedene Implementierungen verfügbar. Apache Geronimo setzt auf die Implementierung der ASF, nämlich OpenJPA 97, auf. In einem weiteren Abschnitt werden spezielle Einstellungen für OpenJPA getroffen. Darunter befinden sich die JDBC-Verbindungsdaten und die Einstellung openjpa.jdbc.synchonizemappings, durch deren Wert buildschema das Datenbankschema automatisch erzeugt wird. Benutzung des EntityManagers Wie in Abschnitt beschrieben, gibt es zwei Arten von PersistenceContext: containermanaged und application-managed. Für den CounterService wird im folgenden erklärt, wie mit Hilfe eines application-managed EntityManagers 98 eine CounterEntity geladen und ge- 96 Vgl. DeMichiel/Keith (2006), S JPA-Implementierung der ASF, 98 Anm. des Verfassers: die Nutzung eines container-managed EntityManagers schlug fehl, der Container 63

66 64 Stateful Web Services speichert werden kann. Um eine Operation des EntityManagers auszuführen wird im CounterService wie folgt vorgegangen. 1. Erzeugung einer EntityManagerFactory mit dem im XML-Deskriptor angegebenen Namen CounterPU. 2. Erzeugung eines EntityManagers mit Hilfe der EntityManagerFactory. 3. Laden der CounterEntity mit der find-methode des EntityManagers. 4. Start einer neuen Transaktion. 5. Änderung von CounterEntity-Eigenschaften und Ausführung von Persistenzoperationen. 6. Abschluss der Transaktion. Die in Anhang A angeheftete CD enthält den Quellcode für den CounterService auf Basis von JAX-WS und vermittelt einen detaillierten Einblick in die Verwendung des EntityManagers. Serialisierung einer CounterEntity In Abschnitt 5.5 wurde gezeigt, wie JPA Entities migriert werden können. Um die CounterEntity migrierbar zu machen, muss diese die Markierungsschnittstelle Serializable implementieren. Um ein Objekt zu serialisieren verwendet man die Klasse ObjectOutputStream aus dem java.io-paket. Quellcode 6.2 zeigt, wie eine CounterEntity serialisiert wird. Die Deserialisierung einer Bytefolge erfolgt äquivalent mittels eines ByteArrayInputStreams und eines ObjectInputStreams. Quellcode 6.2: Serialisierung einer CounterEntity... CounterEntity counter = (CounterEntity)entityManager.find(CounterEntity.class, 1);... byte[] bytes; if (counter!= null) { ByteArrayOutputStream out = new ByteArrayOutputStream(); ObjectOutputStream os = new ObjectOutputStream(out); os.writeobject(counter); os.close(); bytes = out.tobytearray(); }... 64

67 Stateful Web Services 65 Merging Abbildung 6.3 verdeutlicht, wie der Zustand eines CounterService, die CounterEntity, in einen anderen CounterService kopiert werden kann. Die Klientenanwendung, die die Migration vornimmt, erstellt zwei Web Service Clients für den CounterService (in der Abbildung mit CounterClient bezeichnet). Der Klient ruft zunächst die Export-Operation des Counter- Services auf Server A auf und benutzt anschließend den zurückgelieferten Byte-Array als Parameter, um die Merge-Operation auf Server B aufzurufen. Der PersistenceContext des CounterService auf Server B enthält nach Aufruf der beiden Operationen eine identische CounterEntity wie Server A. Abbildung 6.3: Übertragung einer CounterEntity Der in diesem Abschnitt beschriebene CounterService besitzt nur eine CounterEntity. Um diese CounterEntity zu übertragen wird sie zu einem Byte-Array serialisiert. Theoretisch ist es auch denkbar, mehrere CounterEntities zu serialisieren und zu übermitteln. Dabei ist man weder auf den Byte-Array als Übertragungsformat noch auf das Übertragungsmedium von Web Services beschränkt. Beispielsweise ist es auch möglich, die CounterEntity in das XML-Format zu serialisieren und über einen einfachen Dateiaustausch zu migrieren. In allen 65

68 66 Stateful Web Services Fällen werden Schnittstellen benötigt, die in der Lage sind, CounterEntities zu exportieren und zu mergen. Im produktiven Einsatz ist darauf zu achten, dass diese Schnittstellen entsprechend abgesichert sind, damit Unbefugte keinen Zutritt zu den Daten erhalten. 6.3 Implementierung mit Apache Muse Apache Muse 99 ist Teil des Apache Web Services Projekts. Es ist eine Java-Implementierung der Spezifikationen WS-ResourceFramework (WSRF), WS-BaseNotification (WSN) und WS-DistributedManagement (WSDM). In der aktuellen Version baut Apache Muse auf Apache Axis auf. Apache Muse erlaubt die Erstellung von WSRF-konformen Web Services mit geringem Aufwand. Programmiermodell Apache Muse beruht auf einem einfachen Programmiermodell. Dieses Modell wird in Abbildung 6.4 dargestellt und enthält die folgenden Komponenten: Muse Web Service: Der Muse Web Service nimmt Anfragen entgegen und übergibt diese an den Resource Router. Resource Router: Der Resource Router leitet Anfragen an die entsprechenden Ressourcen weiter. Dabei hilft ihm ein Resource Manager. 99 Vgl Vgl. 66

69 Stateful Web Services 67 Abbildung 6.4: Apache Muse Programming Model Quelle: Apache Muse Reference Manual ( ), Programming Model Resource Manager: Mit Hilfe des Resource Managers werden Ressourcen verwaltet. Resource Type: Innerhalb eines Muse-basierenden Web Services kann es mehrere Ressourcentypen geben. Capability: Eine Capability ist eine Fähigkeit, die ein bestimmter Ressourcentyp bereitstellt. Ein Ressourcentyp kann mehrere Capabilities haben. Apache Muse stellt für die Erstellung von WSRF Web Services eine Reihe von Tools zur Verfügung. Mit dem Tool WSDL2Java 101 ist es möglich über ein WSDL-Dokument oder einen Muse- Deskriptor 102 ein neues Muse-Projekt zu erstellen. Prinzipiell empfiehlt sich die in Anhang F dargestellte Vorgehensweise. CounterService mit einem dauerhaften Zähler Die einfachste Art einen CounterService zu implementieren ist mittels einer dauerhaften Ressource als sogenannte Single Resource. Der Muse-Service enthält in diesem Fall nur eine 101 Vgl Vgl. 67

70 68 Stateful Web Services einzelne Ressource des Typs Counter. Die Erstellung dieses Muse-Services erfolgt nach dem in Anhang F beschriebenen Prinzip. 1. Erstellung eines WSDL-Dokuments für den CounterService, das die Definitionen für die WSRF- und weitere Operationen enthält Erzeugung des Muse-Projekts mit WSDL2Java über das in Punkt 1 geschaffene WSDL-Dokument. 3. Programmierung der benutzerdefinierten Capabilities. Im Falle des CounterService muss die raise-operation implementiert werden. 4. Da der CounterService die PutResourcePropertyDocument-Operation verwenden soll, müssen Änderungen vorgenommen werden 104. Außerdem ist es sinnvoll den Deployment Deskriptor geronimo-web.xml in den WEB-INF-Ordner des Webarchivs einzufügen. 5. Erstellung des Webarchivs mit Apache Ant. Die in Anhang A angeheftete CD enthält das Muse-Projekt für den in diesem Abschnitt beschriebenen CounterService. Der im kommenden Abschnitt beschriebene Muse-Service erweitert diesen CounterService um eine Resource Factory. Einige der Dateien können dabei wiederverwendet werden. CounterService mit Resource Factory Bei einer Resource Factory handelt es sich aus Sicht von Apache Muse um eine Ressource. Die Fähigkeit einer Resource Factory, neue Counter-Instanzen zu erzeugen, ist dementsprechend eine Capability. Der im vorausgegangenen Paragraphen beschriebene CounterService kann relativ einfach um eine Resource Factory erweitert werden. Für die Erstellung eines CounterService mit einer Resource Factory kann wie folgt vorgegangen werden: 1. Erstellung eines WSDL-Dokuments für die Resource Factory: Zunächst muss ein WSDL-Dokument erstellt werden, das die Operationen der Resource Factory beschreibt. 103 Anm. des Verfassers: Als Grundlage kann das in Anhang D dargestellte WSDL-Dokument verwendet werden, vgl. auch Abschnitt Vgl. Anhang E 68

71 Stateful Web Services Erstellung eines Muse-Deskriptors: Da der CounterService in dieser Ausführung mehrere Ressourcentypen enthält, wird eine Muse-Deskriptor benötigt. Als Grundlage kann der im vorausgegangenen Paragraphen erstellte Muse-Deskriptor verwendet werden. Diesem wird ein neuer Ressourcentyp hinzugefügt. An dieser Stelle ist es auch möglich ServiceGroups 105 oder einen NotificationProducer 106 einzufügen. 3. Erzeugung des Muse-Projekts über den Muse-Deskriptor: Erzeugung eines neuen Muse-Projekts über den in Punkt 2 geschaffenen Muse-Deskriptor. 4. Programmierung: Die Fabrikmethode der Resource Factory muss implementiert werden Änderungen: Wie bereits beschrieben, ist es sinnvoll den Apache Geronimo Deployment- Deskriptor in das Webarchiv einzubinden. Für die PutResourceProperty- Document-Operation muss auch hier das in Anhang E beschriebene Workaround angewendet werden. 6. Build & Deployment Die in Anhang A angeheftete CD enthält den Quellcode für dieses Muse-Projekt und einen eine einfache Klientenanwendung mit der der CounterService inklusive der Resource Factory verwendet werden können. 6.4 Zusammenfassung Mit dem CounterService wurde ein sehr einfacher Stateful Web Service eingeführt. Der CounterService stellt eine Operation bereit, mit der ein interner Zustand, ein Zähler, erhöht werden kann. 105 Vgl. Apache Muse Reference Manual ( ), Add WSRF Service Groups to an Endpoint 106 Vgl. Apache Muse Reference Manual ( ), Publish Any Notification Message 107 Vgl. Apache Muse Reference Manual ( ), Create a Resource (Programmatically) 69

72 70 Stateful Web Services Eine Möglichkeit den eingeführten Web Service zu implementieren ist mittels der JAX-WS und Java Persistence API. Die Erstellung des Web Services erfolgt mit einfachen Java-Klassen, die mit Annotationen aus beiden APIs versehen werden. Um den definierten JPA-Entity- Typ in einem Datenspeicher ablegen zu können, wird der Applikation ein XML-Deskriptor persistence.xml beigelegt, der Konfigurationsdaten enthält. Zusätzlich wird die erstellte CounterEntity-Klasse mit der Marker-Schnittstelle Serializable versehen, so dass diese serialisiert und übertragen werden kann. Mit der Merge-Methode des EntityManagers können detached Entities in den PersistenceContext einer anderen Applikation eingebunden werden. Um den Zustand des CounterService zu migrieren, werden dem Web Service zwei Operationen hinzugefügt. Mit einer Operation wird der Zustand exportiert, mit der anderen Operation wird dieser importiert. Die zweite Implementierung des CounterService erfolgt mit Apache Muse. Das Programmiermodell von Apache Muse fasst Fähigkeiten von Ressourcen in Capabilities zusammen. Apache Muse unterstützt die Generierung von Muse-Services mit einem WSDL2Java-Tool, so dass lediglich benutzerdefinierte Capabilities implementiert werden müssen. Eine Capability ist die Erhöhung des Zählers. Da Apache Muse die PutResourcePropertyDocument-Operation nicht vollständig unterstützt, müssen ein paar Dinge beachtet werden Vgl. Anhang E 70

73 Architektur 71 Kapitel 7: Architektur In Kapitel 2 wurden die Anforderungen für die Migration einer Serverapplikation beschrieben. In dem kommenden Kapitel wird eine Architektur vorgestellt, die Migrationen zulässt und dabei diesen Anforderungen gerecht wird. Die Architektur enthält drei Komponenten, die in den folgenden Abschnitten beschrieben werden. Am Ende des Kapitels wird eine Topologie vorgestellt, die diese Komponenten enthält und in der Migrationsvorgänge autonom durchgeführt werden können. 7.1 Anforderungen In Kapitel 2 wurden die Anforderungen an die Migration einer Serverapplikation bereits dargestellt. Eine Migration darf den produktiven Geschäftsablauf nicht unterbrechen oder in außerordentlichem Maße negativ beeinflussen. Diesbezüglich spielen drei Punkte eine wichtige Rolle: 1. Klientenanfragen: Während der Migration dürfen keine Klientenanfragen verloren gehen oder verworfen werden. 2. Zustandsdaten: Es reicht nicht aus die Serverapplikation auf das Zielsystem zu migrieren. Zusätzlich müssen die Zustandsdaten der Applikation vom Quellsystem übertragen werden. 3. Nutzung des Zielsystems: Es muss ein Mechanismus gefunden werden, damit Klienten bei erfolgreichem Abschluss der Migration auf die Serverapplikation des Zielsystems zugreifen. Um die genannten Anforderungen zu erfüllen, ist es sinnvoll eine Architektur zu erschaffen, in der Migrationen durchgeführt werden können, ohne dass dabei die geschäftlichen Abläufe unterbrochen werden. Wie die einzelnen Anforderungen umgesetzt werden, beschreiben die nächsten Abschnitte. 71

74 72 Architektur 7.2 Dispatcher Um die Punkte 1 und 3 aus dem vorherigen Abschnitt umzusetzen wird eine Komponente zwischen den Klienten und die Applikation eingefügt. Diese Komponente wird als Dispatcher bezeichnet. Der Dispatcher dient als Vermittlungsstelle für alle Klientenanfragen. Abbildung 7.1 zeigt rechts einen Dispatcher, der als Vermittlungsstelle zwischen Klienten und Web Services zugeschaltet wurde. Es wird deutlich, dass bei der Migration eines Web Services lediglich der Dispatcher über den geänderten Standort informiert werden muss. In der links gezeigten Variante ist es erforderlich, jeden einzelnen Klienten über die Migration zu informieren. Abbildung 7.1: Der Dispatcher als Vermittlungsstelle Ein Vorteil bei der Nutzung eines Dispatchers ist, dass dieser unter bestimmten Umständen Anfragen zurückstellen kann. Da für die Zeitdauer des Merging eine Applikation nicht verfügbar ist, kann der Dispatcher die Anfragen solange zurückhalten, bis der Merge-Vorgang abgeschlossen ist. Dann leitet er die Anfragen an die migrierte Applikation weiter. Der Klient muss in diesem Fall zwar eine verlängerte Antwortzeit in Kauf nehmen, es erfolgt jedoch keine Unterbrechung des Geschäftsablaufs. Um die genannten Anforderungen zu erfüllen, fallen dem gezeigten Dispatcher mehrere Aufgaben zu: Weiterleitung: Der Dispatcher muss dazu in der Lage sein, Anfragen einzelnen Web Services zuzuordnen und diese weiterzuleiten. 72

75 Architektur 73 Wissen über die Web Services: Der Dispatcher benötigt, um SOAP-Anfragen korrekt weiterzuleiten, Wissen über die Web Services, wie z. B. die aktuelle Serveradresse und die Verfügbarkeit. WS-Addressing: Da die eigentliche SOAP-Anfrage an den Dispatcher adressiert ist, kann es bei der Benutzung von WS-Adressing zu unerwünschten Nebeneffekten kommen. Je nach Implementierung erzeugt der Klient Message Information Headers 109, die die HTTP-URL des Dispatchers enthalten. Wird diese SOAP-Anfrage unverändert an den eigentlichen Web Service weitergeleitet, kann dieser unter Umständen die Anfrage intern nicht weiterverarbeiten. Es ist deshalb notwendig, dass der SOAP-Header untersucht wird und die entsprechenden HTTP-URLs abgeändert werden. Endpunktreferenzen in Antworten: Ähnlich verhält es sich mit Endpunktreferenzen, die Teil einer SOAP-Antwort sind, so wie es beim WS-Resource Factory Entwurfsmuster 110 der Fall ist. Der Klient kann die Endpunktreferenzen zwar problemlos verarbeiten, wenn die Systeme, auf denen sich die Web Services befinden, über das Netzwerk erreichbar sind. Wird im weiteren Programmverlauf jedoch eine solche Endpunktreferenz benutzt, dann wird der Dispatcher umgangen und im Falle einer Migration treten Probleme auf. Leistung: Da der Dispatcher eine Engstelle zwischen den Klienten und den Web Services darstellt, muss darauf geachtet werden, dass alle Aufgaben möglichst effizient und performant durchgeführt werden. Die Funktionalität des Dispatchers ähnelt sehr stark dem NAT 111 -Konzept. NAT ist ein Verfahren, um ein gesamtes Netzwerk einer einzigen IP-Adresse zuzuweisen 112. Analog dazu, ist 109 Vgl. Abschnitt Vgl. Abschnitt Network Address Translation 112 Vgl. Network Address Translation (NAT) ( ) 73

76 74 Architektur der Dispatcher ein Verfahren mit dem mehrere verteilte Web Services über einen gemeinsamen HTTP-Server erreicht werden können. 7.3 Merger Die Merger-Komponente ist für die Migration und für das Merging einer Applikation verantwortlich. Der Merger stellt eine Schnittstelle bereit, über die die Migration einer Serverapplikation ausgelöst werden kann. Die Aufgaben der Merger-Komponente sind: Auslöser für eine Migration: Der Merger löst die Migration einer Serverapplikation aus und beobachtet deren Verlauf. Er führt die für die Migration nötigen Schritte aus. Er stellt eine Schnittstelle bereit, über die eine Migration ausgelöst werden kann. Wissen über Applikation: Damit die Zustandsdaten problemlos übertragen werden können, benötigt der Merger Informationen über den Aufbau der Applikation, insbesondere über die Form der Zustandsdaten. Es gibt verschiedene Möglichkeiten, wie der Merger diese Informationen gewinnen kann. Denkbar ist, dass der Merger bei jeder Migration die Applikation untersucht und dynamisch einen dazu passenden Merging-Plan erzeugt. Andere Alternativen sind die Einführung eines weiteren XML-Deskriptors oder die einmalige Untersuchung der Applikation beim Deployment. Kooperation mit dem Dispatcher: Wenn die in Kapitel 2.2 beschriebene Zeitdauer beginnt, in der die Applikation nicht mehr verfügbar ist, dann teilt der Merger dem Dispatcher mit, dass er bis auf weiteres die Anfragen für diese Applikation zurückhalten soll. Wenn die Migration erfolgreich abgeschlossen wurde, übergibt der Merger den geänderten Standort an den Dispatcher. Nebenläufigkeit: Es ist möglich, dass zu einem Zeitpunkt mehrere Migrationen erfolgen. Dies muss bei der Entwicklung berücksichtigt werden. 74

77 Architektur 75 Abbildung 7.2: Der Merger als Migrationsauslöser In Abbildung 7.2 wird die Verwendung des Mergers beispielhaft dargestellt. In Schritt 1 wird die Migration ausgelöst. In der Grafik erfolgt die Auslösung durch die Überlastnachricht eines Applikationsservers. Die Migration kann auch auf andere Weise gestartet werden, wie z. B. über das Kommando eines Systemadministrators. In einem zweiten Schritt sucht der Merger nach einem Zielsystem für die Applikation. Dieser Schritt kann unter Umständen auch entfallen, wenn beim Aufruf des Mergers bereits ein Zielsystem angegeben wurde. Im in der Grafik dargestellten dritten Schritt führt der Merger die Operationen aus, die für die Migration der Applikation notwendig sind. Dabei handelt es sich üblicherweise um Operationen auf dem Quell- und Zielsystem, der Quell- und Zielapplikation und dem Dispatcher. 7.4 Deployer Um Applikationen auf einem Java EE Server zu installieren gibt es Deployer. Deployer sind Komponenten, mit denen Applikationen verteilt, konfiguriert und deinstalliert werden können. Konforme Java EE Server müssen einen Deployer für die in Kapitel beschriebenen Archivtypen bereitstellen. Es ist auch möglich eigene Deployer zu entwickeln. Das Deployment einer Applikation mit einem speziellen Deployer ist aus mehreren Gründen sinnvoll. Ein Grund ist die Verteilung beim initialen Deploy-Vorgang. Wenn Applikationen im Laufe der Zeit zwischen einzelnen Serversystemen zur Lastkontrolle migriert werden, dann liegt es nahe, dass Applikationen bereits bei der Erstinstallation auf das am besten geeignete 75

78 76 Architektur System verteilt werden. Abbildung 7.3 stellt dieses Prinzip dar. Ein weiterer Grund, der für die Abbildung 7.3: Der Deployer Verwendung eines speziellen Deployers spricht, sind die Informationen, die von den zuvor beschriebenen Dispatcher- und Merger-Komponenten benötigt werden. Der Dispatcher braucht für die Weiterleitung von Anfragen die Serveradresse der Applikation. Der Merger benötigt für die spätere Migration Informationen über deren Form, insbesondere über die Art der Zustandsdaten, die darin enthalten sind. Der Deployer kann die Applikation bei ihrer Verteilung einmalig untersuchen und Daten an die Merger- bzw. Dispatcher- Komponente weiterleiten. Zwar ist es auch denkbar, dass diese Informationen hartkodiert in einer XML-Datei hinterlegt werden, eine automatische Erkennung verringert jedoch den Aufwand in der Applikationsentwicklung. 7.5 Gesamtarchitektur Die in den letzten drei Abschnitten beschriebenen Komponenten besitzen alle eine Gemeinsamkeit. Sie greifen in irgendeiner Weise auf mehrere Java EE Server zu. Der Dispatcher leitet Anfragen an einen bestimmten Java EE Server weiter, nämlich denjenigen auf dem sich die Applikation befindet. Der Merger übertragt eine Applikation zwischen zwei Java EE Servern. Der Deployer installiert Applikationen auf dem am besten geeigneten Java EE Server. Abbildung 7.4 führt einen Java EE Server ein, der eine Reihe mehrerer Java EE Servern repräsentiert. Als Java EE Serversoftware wird Apache Geronimo verwendet, da Apache Geronimo frei erhältlich ist und über eine moderne Architektur verfügt. Der Zugriff auf Applikationen erfolgt für alle Klienten über den Dispatcher des Apache Geronimo Servers A. In der 76

79 Architektur 77 Abbildung 7.4: Gesamtarchitektur Grafik wird die Analogie zu NAT deutlich 113. Das Apache Geronimo Server Network entspricht dem privaten Netzwerk, Apache Geronimo Server A einem NAT-Router. Bei NAT erfolgt der Zugriff aus einem öffentlichen Netzwerk über den NAT-Router, der Datenpakete anhand einer Tabelle an einen Teilnehmer des privaten Netzwerks weiterleitet. Analog dazu verhält sich der Dispatcher, der ebenfalls eine Tabelle besitzt, durch die er Anfragen einer bestimmte Applikation auf einem bestimmten Apache Geronimo Server zuordnen kann. Die Merger- und Deployer-Komponenten können mit Managementfunktionen verglichen werden, die von einem NAT-Router bereitgestellt werden. 113 Vgl. Network Address Translation (NAT) ( ) 77

80 78 Architektur 7.6 Autonomie Der Begriff Autonomic Computing wurde von dem Unternehmen IBM 114 eingeführt. Autonomic Computing verfolgt das Ziel, dass Systeme mit autonomen Eigenschaften entwickelt werden 115. Zu diesen Eigenschaft zählt, dass sich Systeme eigenständig verwalten. IBM unterscheidet vier Unterbereiche 116 : self-configuration, self-heal, self-optimize und self-protect. Autonomic Computing ist ein Konzept, um den Verwaltungsaufwand moderner Systeme zu reduzieren. Das ist nötig, weil die Komplexität von Systemen stetig steigt und der daraus resultierende, erhöhte Verwaltungsaufwand nicht mehr in vollem Umfang durch Fachkräfte ausgeführt werden kann. Die Migration einer Serverapplikation verfolgt den Zweck, die Last gleichmäßig auf mehrere Serversysteme zu verteilen. In Abbildung 7.2 wurde dargestellt, dass jeder einzelner Java EE Server seine Last überwacht und über die Merger-Komponente die Migration einer Applikation anstößt, wenn die Last zu hoch ist. Das Gesamtsystem erkennt also die Überlast und nimmt eine Optimierung vor, indem eine Applikation auf ein anderes Serversystem verschoben wird. Dabei handelt es sich um ein autonomes Verhalten im Sinne des Autonomic Computing. 7.7 Zusammenfassung In diesem Kapitel wurde eine Architektur eingeführt, in der Migrationsvorgänge durchgeführt werden können. Es wurden drei Komponenten beschrieben, die auf einem speziellen Apache Geronimo Server lokalisiert sind. Dieser spezielle Apache Geronimo Server ist ein Container für weitere Apache Geronimo Serverinstanzen. Aus Sicht des Klienten wird dieses gesamte untergeordnete Netz durch diesen einen Geronimo-Server repräsentiert. Der Dispatcher nimmt SOAP-Anfragen entgegen und leitet diese an die eigentliche Web Service Implementierung weiter Vgl. Radtke (2004) 116 Vgl. New to Autonomic computing ( ) 78

81 Architektur 79 Der Merger kann dazu verwendet werden, um Migrationsvorgänge zu starten: entweder automatisiert, wenn ein interner Apache Geronimo Server eine Überlastnachricht erzeugt oder wenn das Kommando seitens eines Systemadministrators gegeben wird. Der Deployer dient dazu, Applikationen zu verteilen. Dabei können Informationen gewonnen werden, die von der Dispatcher- und Merger-Komponenten benötigt werden. Die in diesem Kapitel dargestellte Architektur zeigt einen Weg auf, wie Migrationen autonom zur Selbstoptimierung eines Apache Geronimo Servernetzes genutzt werden können. 79

82 80 Servicemodul Kapitel 8: Servicemodul Im letzten Kapitel wurde eine Architektur vorgestellt, innerhalb der Migrationsvorgänge autonom durchgeführt werden können. Dabei wurden Komponenten beschrieben, die für bestimmte Funktionen benötigt werden. Eine dieser Komponenten ist der Dispatcher, der SOAP-Anfragen weiterleitet. Eine andere Komponente ist der Merger, der eine Schnittstelle bereitstellt, um Migrationsvorgänge zu starten. In diesem Kapitel wird beschrieben, wie diese beiden Komponenten in Apache Geronimo über ein Modul integriert werden. Der Deployer ist nicht Teil dieser Implementierung. Stattdessen wird das Servicemodul programmatisch bzw. über eine XML-Datei beispielhaft für die in Kapitel 6 erstellten Web Services konfiguriert. 8.1 Dispatching mit einem HttpServlet Da als Transportprotokoll für SOAP in den meisten Fällen HTTP verwendet wird, kann für die Weiterleitung von SOAP-Anfragen ein HttpServlet verwendet werden. Das HttpServlet enthält Java-Code, der die vorhandenen SOAP-Header einer Nachricht untersucht und abändert, wenn die SOAP-Anfrage Message Information Headers 117 enthält. Das Servlet leitet eine Anfrage an eine auf einem spezifischen Server befindliche Applikation weiter, untersucht die Antwort und liefert diese an den ursprünglichen Klienten zurück. Für die Verwaltung von Applikationsinformationen, wie die aktuelle Adresse und deren Verfügbarkeit, wird ein GBean verwendet, da es leicht zu erstellen ist und problemlos von anderen Komponenten, wie z. B. der Merger-Komponente, referenziert werden kann. Die Grafik in Abbildung 8.1 zeigt die Funktionsweise des Dispatchers. Zuerst stellt der Klient die Anfrage an das DispatcherServlet. Das DispatcherServlet ist Teil einer Webanwendung, die dem Webkontext /dispatcher zugeordnet ist. Das Servlet wird über die Wildcard * auf alle HTTP-Adressen abgebildet, die mit diesem Webkontext beginnen. Das DispatcherGBean enthält Einträge mit dem die Aufrufadresse des DispatcherServlets auf die tatsächliche Adresse des Web Services abgebildet werden kann. 117 Vgl. Abschnitt

83 Servicemodul 81 Abbildung 8.1: Funktionsweise des Dispatchers Beispiel: 1. Der Klient sendet eine SOAP-Anfrage an die folgende Adresse: 2. Das DispatcherGBean enthält eine Tabelle mit einem Eintrag, der diese Dispatcheradresse in eine echte Serviceadresse umsetzen kann: service1 = 3. Das DispatcherServlet leitet die SOAP-Anfrage weiter an die Adresse: 4. Der Web Service liefert die Antwort zurück. 5. Der Dispatcher untersucht die Antwort, ändert sie gegebenfalls ab und sendet sie zurück an den Klienten. Beim Erhalt einer SOAP-Anfrage nimmt das DispatcherServlet Kontakt zum DispatcherGBean auf. Um mit dem DispatcherGBean interagieren zu können, wird im Geronimo Deployment Deskriptor der Webapplikation eine Referenz auf das DispatcherGBean festgelegt. Innerhalb des DispatcherServlet kann dann mit Hilfe von JNDI 118 auf das DispatcherGBean zugegriffen werden, um die Zieladresse herauszufinden. 118 Java Directory and Naming Interface 81

84 82 Servicemodul SOAP-Header untersuchen mit Apache Axiom AXIOM steht für AXIs Object Model. Dabei handelt es sich um ein Objektmodell, das ursprünglich für Apache Axis2 entwickelt wurde. Apache Axiom 119 baut auf der Streaming API for XML (StAX) auf. StAX 120 ist eine API, die sich mit dem Lesen und der Manipulation von XML-Daten beschäftigt und dabei die Vorteile eines baumbasierten und eines ereignisbasierten Parsers vereint. Apache Axiom ist die StAX-Implementierung der ASF und stellt Java-Klassen bereit, mit denen SOAP-Nachrichten in performanter Weise gelesen und manipuliert werden können. Verfügbarkeit prüfen Eine weitere Aufgabe des Dispatchers ist es, Abbildung 8.2: Ablaufplan vor der Weiterleitung einer SOAP-Anfrage zu prüfen, ob der Web Service zum aktuellen Zeitpunkt verfügbar ist. Dazu kooperiert das DispatcherServlet, wie für die Abbildung des Webkontexts auf die Web Service Adresse, mit dem DispatcherGBean. Ist der Web Service nicht verfügbar, dann wird eine Warteschleife ausgelöst, in der in regelmäßigen Abständen überprüft wird, ob der Web Service wieder erreichbar ist. Das ist ein äußerst kritisches Verfahren, da für die Wartedauer Serverressourcen belegt werden. Daraus resultiert das Problem, das bei längeren Wartezeiten und vielen Klientenanfragen der Server unter Umständen in die Knie gezwungen wird. Wenn Probleme bei einer Migration auftreten und die Verfügbarkeit eines Web Services nicht zurückgesetzt werden kann, dann hat das die Konsequenz, dass Klienten total 119 Vgl Streaming API for XML 82

85 Servicemodul 83 blockiert werden und Server-Ressourcen nicht mehr freigegeben werden 121. Abbildung 8.2 stellt einen vereinfachten Programmablaufplan dar. Durch das Hinzufügen eines Timeout- Mechanismus wird gewährleistet, dass nach einer bestimmten Zeitspanne eine Fehlermeldung zurückgegeben wird, falls der benötigte Web Service immer noch nicht verfügbar ist. 8.2 Dispatcher- und MergerGBean Mit Hilfe von GBeans ist es sehr einfach Systemdienste für Apache Geronimo zu erstellen. Ein Teil der Dispatcher- und die gesamte Merger-Komponente werden als GBean implementiert. Wie in Kapitel bereits beschrieben wurde, handelt es sich bei GBeans um einfache Java-Klassen, die eine getgbeaninfo-methode besitzen. Das GBeanInfo-Objekt, das von dieser Methode zurückgegeben wird, enthält Informationen zum Konstruktor, zu Operationen, zu Attributen und zu den Referenzen eines GBeans. Das DispatcherGBean ist eine einfaches GBean, das eine Struktur enthält, mit der ein String auf eine Web Service Adresse abgebildet werden kann. Dazu kommen einige öffentliche Methoden, mit denen Einträge dieser Tabelle abgefragt, hinzugefügt, geändert und gelöscht werden können. Das MergerGBean besitzt zwei öffentliche Methoden. Mit diesen Methoden ist es möglich, Migrationsvorgänge zu starten. Daneben enthält das MergerGBean eine Referenz auf das DispatcherGBean. Für beide GBeans müssen entsprechende GBeanInfo-Objekte erstellt werden, die die Konstruktoren, Methoden und Referenzen des GBeans beschreiben. Neben der korrekten Erzeugung der GBeanInfo-Instanzen ist es auch notwendig einen Deployment Deskriptor zu erstellen. Da als Dispatcher ein HttpServlet verwendet wird, ist es sinnvoll die Anwendung als Webanwendung zu archivieren. Dem Webarchiv kann der Geronimo Web Deployment Deskriptor geronimo-web.xml 122 hinzugefügt werden. Dieser enthält neben den typischen Geronimo-Deployment-Informationen auch Elemente, die die GBeans beschreiben. Die in Anhang A angeheftete CD enthält den gesamten Quellcode für das DispatcherServlet, für die beiden GBeans und den Deployment Deskriptor. 121 Anm. des Verfasser: Für den produktiven Einsatz wird deshalb empfohlen, ein anderes Verfahren einzusetzen. Eine Möglichkeit wäre beispielsweise die Verwendung einer Message Queue. 122 Vgl. 83

86 84 Servicemodul 8.3 Ablauf einer Migration Um eine Operation auszulösen stellt die Klasse MergerGBean die merge-operation zur Verfügung. Es ist möglich, diese Methoden lokal oder von einem entfernten Rechner mittels JMX aufzurufen 123. Damit mehrere Migrationsvorgänge parallel erfolgen können, muss ein Migrationsvorgang in einen separaten Thread ausgelagert werden. Wenn die merge-methode des MergerGBean aufgerufen wird, wird ein neuer Thread erzeugt und das MergerGBean bleibt nur für einen kurzen Augenblick blockiert. Der grobe Ablauf einer Migration orientiert sich an der in Abbildung 2.3 (S. 16) gezeigten Grafik. Folgende Schritte sind notwendig: 1. Deployment der Applikation auf dem Zielsystem. 2. Änderung der Dispatcher-Konfiguration, so dass Klientenanfragen für die Applikation auf dem Quellsystem zurückgestellt werden. 3. Übertragung der Zustandsdaten (für jede Applikation verschieden) 4. Änderung der Dispatcher-Konfiguration, so dass neue Klientenanfragen an die Applikation auf dem Zielsystem geleitet und die zurückgestellten Anfragen abgearbeitet werden. 5. Deinstallation der Applikation auf dem Quellsystem. Abbildung 8.3: MergeActionBuilder 123 Vgl. Kapitel 3.1.2, Kapitel

87 Servicemodul 85 Um bei der Durchführung der Schritte möglichst flexibel zu sein, wird das Builder-Entwurfsmuster 124 und Java Reflection verwendet. Abbildung 8.3 stellt das Prinzip dar. Wenn die merge-methode des MergerGBeans aufgerufen wird, benutzt das MergerGBean den MergeActionBuilder, um eine SimpleMergeAction zu erzeugen. Die SimpleMergeAction verwendet die Schnittstellen DispatchProvider, InstallProvider, TransferProvider und UndeployProvider um die zuvor aufgeführten Schritte durchzuführen. Der MergeActionBuilder liest Konfigurationsdaten aus einer XML-Datei aus, die Informationen zu den genannten Providern enthält. Dazu gehören zum Beispiel der Klassenname und Parameter, die für die Erstellung einer neuen Providerinstanz notwendig sind. Anschließend benutzt er die Klassennamen, um mit Java Reflection neue Instanzen der einzelnen Provider zu erzeugen. Diese weist er dann der SimpleMergeAction zu. Durch dieses Konzept ist es sehr einfach möglich, neue Provider in das Servicemodul zu integrieren. Auf der angehefteten CD (Anhang A) befindet sich der Quellcode für die MergeActionBuilder-, die SimpleMergeAction- und zahlreiche vorgefertigte Providerklassen, die für die Migration einer Applikation verwendet werden können. JSR-88 Deployment Für die Installation und das Undeployment von Applikationen wird in sehr vielen Fällen die in Kapitel beschriebene Java EE Deployment API verwendet. Quellcode 8.1 zeigt das Codegerüst einer Java-Klasse, in der ein DeploymentManager verwendet wird. Zuerst wird die im Server Plugin enthaltene DeploymentFactory-Implementierung für Apache Geronimo im DeploymentFactoryManager registriert. Über diesen Manager wird über eine URI 125, einen Benutzernamen und ein Passwort ein neuer DeploymentManager erzeugt. Der Deployment- FactoryManager wählt anhand des URI eine entsprechende Fabrik aus und erzeugt einen neuen DeploymentManager, mit dem JSR-88-Operationen ausgeführt werden können. Wandelt man den DeploymentManager über Casting in ein GeronimoDeploymentManager um, können zusätzlich Apache Geronimo spezifische Operationen durchgeführt werden. Eine dieser Operationen ist beispielsweise die Plugin-Installation 126. Um einen DeploymentManager für Apache Geronimo zu verwenden, wird auf jeden Fall das Server-Plugin im Klassenpfad der Java-Applikation benötigt. 124 Erbauer Pattern ( ) 125 Uniform Resource Identifier 126 Vgl. Kapitel

88 86 Servicemodul Quellcode 8.1: (Geronimo)DeploymentManager import... public class DeployTest { // register DeploymentFactory private static DeploymentFactoryManager factorymanager = DeploymentFactoryManager.getInstance(); static { factorymanager.registerdeploymentfactory(new DeploymentFactoryImpl()); }... public void usedeploymanager(string uri, String user, String pass) { // create deployment manager for destination server DeploymentManager deploymanager = null; try { deploymanager = factorymanager.getdeploymentmanager(uri, user, pass); // do something with DeploymentManager, e. g. get modules, deploy, undeploy, etc GeronimoDeploymentManager geronimodeploymanager = (GeronimoDeploymentManager)deployManager; // do a specific GeronimoDeploymentManager operation, e. g. install a plugin } } } catch (Exception exc) { // authentication failed, server offline, etc. } 8.4 Zusammenfassung Dieses Kapitel zeigte Schritte für die Implementierung eines Servicemoduls für Apache Geronimo, das die in Kapitel 7 beschriebene Dispatcher- und Merger-Komponente enthält. Um SOAP-Anfragen anzunehmen und weiterzuleiten, wird ein HttpServlet verwendet. Beim Erhalt einer Anfrage überprüft der Dispatcher, ob der gewünschte Web Service verfügbar ist; wenn nicht, dann geht die Anfrage in eine Warteschleife. Dieser auf Threads basierende Wartemechanismus ist problematisch, da für die Dauer der Warteschleife Serverressourcen verschwendet werden. 86

89 Servicemodul 87 Die Informationen über die vorhandenen Web Services verwaltet das DispatcherGBean. Es stellt eine Datenstruktur und Operationen bereit, um Einträge abzufragen, hinzuzufügen, zu bearbeiten und zu löschen. Das MergerGBean bietet eine Methode an, mit der Migrationsvorgänge gestartet werden. Es kooperiert mit dem DispatcherGBean. Einzelne Migrationsvorgänge werden in einem separaten Thread ausgeführt. Um neue Threads zu erstellen, benutzt das MergerGBean den MergeAction- Builder. Der MergeActionBuilder benutzt eine XML-Konfigurationsdatei und Java Reflection, um die Threads, Instanzen der Klasse SimpleMergeAction, anzulegen. In der Konfigurationsdatei kann für die Installation, das Dispatching, den Zustandstransfer und das Undeployment mit einem Klassennamen ein Provider festgelegt werden. Der MergeActionBuilder benutzt diesen Klassennamen um mittels Reflektion Provider-Instanzen zu erzeugen, die von der SimpleMergeAction benutzt werden, um die genannten Schritte durchzuführen. Um einen genaueren Einblick in das Servicemodul zu bekommen, kann der Quellcode auf der beigelegten CD (Anhang A) betrachtet werden. 87

90 88 Grafische Benutzeroberfläche Kapitel 9: Grafische Benutzeroberfläche Die Migration einer Serverapplikation erfolgt über das in Kapitel 8 implementierte Servicemodul. Dieses Kapitel beschreibt, wie ein grafisches Managementtool erstellt wird um mit Drag&Drop-Mitteln die Migration einer Anwendung auszulösen. 9.1 Anforderungen Das primäre Ziel der Managementapplikation, die im weiteren Verlauf die Bezeichnung MergeUI tragen soll, ist die Auslösung einer Migration über einen Drag&Drop-Mechanismus. Darüberhinaus wird mit einigen weiteren nützlichen Funktionen der Umfang von MergeUI erweitert. Zu den Features von MergeUI gehören: Auslösung einer Migration per Drag&Drop Auflistung der auf einem Apache Geronimo Server installierten Module bzw. Applikationen Integration von ASCMon in die Anwendung, um die Serverauslastung grafisch in einem Diagramm anzuzeigen Parallele Darstellung der Informationen für mehrere Apache Geronimo Server in Fenstern, die einzeln zu- und weggeschaltet werden können. Konfiguration von MergeUI Wie bei dem in Kapitel 8 erstellten Servicemodul geht es bei der Implementierung von MergeUI in erster Linie darum, ein Proof of Concept zu erstellen, in dem die Migration einer Applikation per Drag&Drop durchgeführt wird. Ziel ist es mit MergeUI eine Applikation auf ein System zu migrieren, so dass dieses überlastet ist. Durch die Darstellung der Serverauslastung in MergeUI soll anschließend verfolgt werden können, wie das System autonom agiert und eine Systemoptimierung vornimmt. 88

91 Grafische Benutzeroberfläche Aufbau Um Informationen, die mehrere Apache Geronimo Server betreffen, gleichzeitig darzustellen, muss mit Abbildung 9.1: MergeUI-Aufbau Threads gearbeitet werden. Für die Abfrage der Serverauslastung und zur Abfrage der Module wird pro dargestelltem Serverfenster ein Thread erzeugt, der die notwendigen Informationen abruft und die Benutzerschnittstelle entsprechend aktualisiert. Wird über Drag&Drop eine Migration ausgelöst, dann wird ebenfalls ein neuer Thread erzeugt, der eine Verbindung zum Merger aufnimmt und die merge-methode aufruft. Abbildung 9.1 zeigt den allgemeinen Aufbau von MergeUI. Der Kern von MergeUI ist der MergeUI Core. Der MergeUI Core besitzt Referenzen auf mehrere Manager, die die benötigten Threads zur Informationsgewinnung verwalten. Außerdem stellt er Funktionen bereit, um auf die Benutzerschnittstelle zuzugreifen. Der Zugriff erfolgt dabei über die Schnittstelle UserInterface. Beim Aufbau der Benutzerschnittstelle wurde vor allem Wert auf die Übersichtlichkeit gelegt. Bei Abbildung 9.2 handelt es sich um eine Bildschirmaufnahme der MergeUI-Anwendung. Das Hauptfenster wird links angezeigt. Es besitzt eine kleine Werkzeugleiste, die Schaltflächen enthält um Server-Zugangsdaten hinzuzufügen, zu ändern oder zu löschen, MergeUI zu konfigurieren, ein Hilfedialog anzuzeigen oder die Anwendung zu beenden. Die konfigurierten Server werden in einem JTree angezeigt. Mit einem Doppelklick auf einen Eintrag wird ein Fenster geöffnet, das Informationen über den Apache Geronimo Server anzeigt. Zwei dieser Fenster werden rechts dargestellt. Neben den Verbindungsdaten enthält das Fenster ein JPanel, das den Verlauf der Serverauslastung darstellt. In einer JList werden außerdem die installierten Module angezeigt. Es ist möglich, ein Module zu markieren und mit einer Mausbewegung auf die JList eines anderen Fensters zu ziehen. Beim Loslassen der Maustaste wird ein neuer Thread gestartet, in dem die Migration auf dem entsprechenden Apache Geronimo Server gestartet wird. 89

92 90 Grafische Benutzeroberfläche Abbildung 9.2: MergeUI-Screenshot 9.3 Features Die folgenden Paragraphen heben die Besonderheiten von MergeUI hervor. Drag&Drop Drag&Drop ist ein intuitives Nutzungskonzept von modernen Benutzerschnittstellen. Mit Drag&Drop ist es möglich Informationen zwischen Komponenten, Java-Applikationen oder einer Java-Applikation und einer anderen Anwendung zu transferieren 127. Um Drag&Drop in einer Java Anwendung anzubieten, kann Java Swing verwendet werden. MergeUI erlaubt den Transfer von Modulen zwischen zwei JLists. Um dies zu bewerkstelligen, muss zunächst mit der Methode setdragenabled das Draggen aus Modul-JLists erlaubt werden. In einem 127 Vgl. Introduction to Drag and Drop and Datatransfer ( ) 90

93 Grafische Benutzeroberfläche 91 weiteren Schritt wird eine TransferHandler-Klasse erzeugt und den Modul-JLists zugewiesen. Der TransferHandler enthält die Logik, die ausgeführt wird, sobald der Mauszeiger die Komponente betritt oder die Maustaste über der Komponente losgelassen bzw. gedropped wird. Integration von ASCMon ASCMon ist ein Tool, das im Sommersemester 2007 von mehreren Studenten im Rahmen eines Semesterprojektes an der FH Furtwangen, erstellt wurde 128. ASCMon bietet eine grafische Oberfläche an, die den Verlauf der Auslastung eines Apache Geronimo Servers anhand eines sogenannten H-Values darstellt. Der H-Value wird von einem Geronimo-Servicemodul nach bestimmten Richtlinien berechnet und über einen Web Service bereitgestellt. MergeUI verwendet ASCMon-Komponenten, um den Verlauf der aktuellen Serverlast darzustellen. Konfiguration Um MergeUI effektiv zu nutzen sind Kenntnisse über die Konfigurationsmöglichkeiten notwendig. Neben einfachen Konfigurationseinstellungen, die über die entsprechende Option in der Werkzeugleiste des Hauptfensters einsehbar sind, erlaubt MergeUI das Hinzufügen, Editieren und Löschen von Apache Geronimo Server Einträgen. Die Einträge werden hierarchisch in einer Baumstruktur im Hauptfenster angezeigt, die die in Kapitel 7 beschriebene Topologie widerspiegeln soll. Gespeichert werden die Daten in einer XML-Datei im Hauptverzeichnis der Anwendung. MergeUI unterstützt zwei Arten von Migrationen. Bei der ersten Variante wird die Migration auf einem Geronimo Server durchgeführt. Dies ist dann der Fall, wenn ein Modul zwischen zwei Geronimo Servern mit Drag&Drop verschoben wird, die in der Baumansicht des Hauptfenster denselben übergeordneten Geronimo Server besitzen. Zusätzlich muss in den Optionen die Einstellung do JMX-Remote merging when possible aktiviert sein. Im zweiten Fall führt MergeUI die Migration lokal durch. Dazu verwendet es wie das Geronimo Servicemodul einen MergeActionBuilder und entsprechende Konfigurationsdateien Vgl. Dietrich/Jordan/Pelzer et al. (2007) 129 Vgl. Abschnitt

94 92 Grafische Benutzeroberfläche 9.4 Zusammenfassung MergeUI ist ein Tool mit dem Migrationen per Drag&Drop lokal oder auf einem entfernten Geronimo Server durchgeführt werden können. Es stellt die Last eines Geronimo Servers mit Hilfe des Tools ASCMon dar. 92

95 Messungen 93 Kapitel 10: Messungen In diesem Kapitel werden ein paar einfache Testszenarien durchgespielt Testaufbau Abbildung 10.1 zeigt den Testaufbau an. Es werden zwei Ein-Prozessor-Systeme verwendet, die mittels einer 100MBit-Ethernet-Verbindung aneinander angeschlossen sind. Abbildung 10.1: Testaufbau Da lediglich zwei Systeme zur Verfügung stehen, wird das Servicemodul auf einem der beiden Systeme installiert, zwischen denen die Migrationen stattfinden sollen. Die angedachte Variante mehrere Instanzen eines Apache Geronimo Servers auf einer Maschine zu betreiben ist praktisch (noch) nicht umsetzbar. Apache Geronimo erlaubt es zwar, mehrere lokale Geronimo-Instanzen und dazugehörige Repositories zu erstellen, diese unterstützen jedoch nicht die gesamte Geronimo-Funktionalität wie beispielsweise Plugins. 93

96 94 Messungen 10.2 JSR-88 vs Plugin Deployment Um Serveranwendungen zu migrieren Abbildung 10.2: JSR-88 vs Plugin Deployment werden sie zuerst auf dem Zielsystem installiert. Für diesen Vorgang wurden bereits zwei Verfahren 130 beschrieben. Mit JSR-88 werden Module standardisiert über ein Archiv auf einem Java EE Server installiert. Der andere Mechanismus installiert ein Geronimo Plugin, welches sich auf einem anderen Apache Geronimo Server befindet. Abbildung 10.2 zeigt die Zeitdauer an, die für die Migration einer einfachen Webapplikation 131 benötigt wird. Die Installation mittels Plugin nimmt etwas mehr Zeit in Anspruch, da insgesamt mehr Schritte durchgeführt werden müssen. Die angegebene Zeitdauer beinhaltet die Installation (mit JSR-88 oder mittels Plugins), das Dispatching und das Undeployment mittels JSR Zurückstellung von Klientenanfragen Die Dispatcher-Komponente des Apache Geronimo Servicemoduls benutzt einen auf Threads basierenden Mechanismus, um Klientenanfragen für eine bestimmte Zeitdauer zurückzustellen. Mit Apache JMeter 132 ist es möglich einen Apache Tomcat 133 Server zu überwachen Vgl. Abschnitt bzw. 8.3, Abschnitt Webarchiv mit einfachen HTML-Dateien 132 Werkzeug der ASF, um die Performanz von (Server-)Anwendungen zu messen, vgl Anm. des Verfassers: In der Standalone-Version wird Apache Tomcat mit Manager-Servlets ausgeliefert, mit denen die Serverauslastung in Apache JMeter grafisch dargestellt werden. Das mit Apache Geronimo ausgelieferte Tomcat enthält diese Servlets nicht. Sie müssen zuerst installiert werden. Auf der in Anhang A angehefteten CD befinden sich eine Webapplikation, die die Servlets enthält. 94

97 Messungen 95 Abbildung 10.3: Apache Tomcat Monitoring mit Apache JMeter Abbildung 10.3 zeigt einen Graphen an, der die Auslastung eines Apache Geronimo Tomcat- Servers darstellt. In dem Graphen werden die Auslastung, der Speicherverbrauch, die Thread-Anzahl und das Allgemeinbefinden des Apache Tomcat Servers angezeigt. Apache JMeter wird so konfiguriert, dass pro Sekunde eine SOAP-Anfrage generiert und an die URL des Dispatchers gesendet wird. Der Dispatcher leitet die Anfrage an den in Abschnitt 6.2 beschriebenen CounterService auf das zweite System weiter. Zum markierten Zeitpunkt (1) werden die Anfragen für eine Dauer von ca. 90 Sekunden zurückgestellt. Daraufhin steigt die Zahl der von Apache Tomcat verwalteten Threads um je 1 Thread pro Sekunde (pro Anfrage) an. Nach den 95 Sekunden wird der Dispatcher zurückgesetzt, so dass die zurückgestellten Anfragen abgearbeitet werden. Dieser Vorgang erfolgt relativ rasch innerhalb von wenigen Sekunden. An dem mit (2) markierten Zeitpunkt wird der Dispatcher wiederum umkonfiguriert, so dass Klientenanfragen zurückgestellt werden. Nach der Zeitdauer von ca. 195 Sekunden gibt Apache Tomcat für jede weitere Anfrage einen Ausnahmefehler aus 135. Wird der Dispatcher anschließend wieder zurückgesetzt, werden die Anfragen abgearbeitet. Daraufhin steigt für die Zeitdauer der Abarbeitung der Speicherverbrauch kurzfristig an. 135 Anm. des Verfassers: Standardmäßig ist Apache Tomcat für eine maximale Anzahl von 200 Threads konfiguriert. 95