Analyse und Konzept zur Integration eines Enterprise Service Bus in elastischen Infrastructure as a Service Umgebungen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Ziele
1.3 Aufbau der Arbeit

2 Grundlagen
2.1 Service Orientierte Architekturen
2.1.1 Definition und Prinzipien
2.1.2 Dienst und SOA-Referenzarchitektur
2.1.3 Komposition von Diensten
2.1.4 Technische Umsetzung
2.2 Enterprise Service Bus
2.2.1 Definition und Aufgaben
2.2.2 ESB Architekturen
2.3 Darbietung von bekannten OpenSource ESB Produkten
2.3.1 JBoss ESB
2.3.2 Mule ESB
2.3.3 Sun Open ESB (GlassFish ESB)
2.4 JBoss ESB Clustering und Dienstverwaltung
2.4.1 Dienstverwaltung in JBoss ESB
2.4.2 JGroups und Clustering in JBoss AS
2.5 Cloud Computing und IaaS
2.5.1 Cloud Computing: Definition, Eigenschaften und Einsatzsze- narien
2.5.2 Cloud Computing: Vor- und Nachteile
2.5.3 Cloud Computing BigPlayers
2.5.4 Infrastructure-as-a-Service(IaaS)
2.6 Verwandte Arbeiten
2.6.1 Unterstutzung von ESB-Clustering
2.6.2 Unterstutzung von Cloud Computing

3 Analyse und Konzept
3.1 Distributed Service Bus (DSB)
3.1.1 Central-based-Management Distributed Service Bus
3.1.2 Peer-To-Peer basierter DSB
3.1.3 Auswertung und Vergleich
3.1.4 Eigenes Konzept
3.2 Integration eines ESBs in einer elastischen Umgebung (IaaS)
3.2.1 Anforderungen
3.2.2 Aufbaumoglichkeiten
3.3 Automatisches Abfangen der Anfrage-Lastspitzen in SOA anhand von Cloud Computing
3.3.1 Vorstellung
3.3.2 Arbeitsweise des LoadMonitoringFrameworks (LMF)

4 Implementierung
4.1 Realisierung vom Clustered JBoss ESB
4.2 Einstellungen zur Integration vom JBoss ESB in einer IaaS
4.3 Erzeugung von der JBoss ESB-AMI
4.4 Umsetzung des LoadMonitoringFrameworks
4.5 Schwierigkeiten bei der Umsetzung

5 Evaluation anhand einer Fallstudie: DLR-Traffic Data Platform/FCD- Prozessierungsmodul
5.1 Einftihrung
5.1.1 Vorstellung des DLRs und des DLR-TSs
5.1.2 Beschreibung der Traffic-Data-Platform
5.1.3 Vorstellung vom FCD-Processierungsmodul (oder FCD-Kette)
5.2 SOA-mafiiger Aufbau der FCD Kette
5.2.1 Konzept
5.2.2 Umsetzung
5.3 Simulation des automatischen Abfangens der Lastspitzen basierend auf Cloud Computing

6 Zusammenfassung

Anhang

Vorwort und Danksagung

Die vorliegende Masterarbeit ist im Rahmen meiner Tatigkeit bei dem Deutschen Zentrum fur Luft- und Raumfahrt in Berlin entstanden.

Ich war in dem Institut fur Verkehrssystemtechnik beschaftigt. Diese Arbeit ist Teil meines Studiums der Informatik an der Technischen Universitat in Berlin.

Mein erster Dank geht an Herrn Professor Dr. habil. Odej Kao fur die Themen- stellung und die fachliche Betreuung seitens der Universitat.

An dieser Stelle mochte ich mich auch beim Herrn Prof. Dr. Hans-Ulrich Heifi fur die Begutachtung dieser Masterarbeit bedanken.

Mein Dank gilt ebenfalls dem gesamten Team des Fachgebietes Komplexe und Verteilte IT-Systeme der Technischen Universitat Berlin, die mir stets das notwendi- ge Equipment fur eine effektive Bearbeitung dieser Arbeit bereitgestellt haben.

Ein besonderer Dank richtet sich an Dr. Andre Hoing und Dr. Matthias Ho- vestadt, die meine Arbeit betreut haben. Ihre vorbildliche und kontinuierliche Un- terstutzung hat wesentlich zum Gelingen dieser Masterarbeit beigetragen.

Meinen Dank mochte ich ebenfalls an allen Mitgliedern des DLR-Institutes fur Verkehrssystemtechnik, die mich weitestgehend unterstutzt und beraten ha­ben.

Besonderer Dank geht an Herrn Dipl.-Ing. Louis Calvin Touko Tcheumadjeu, meinem fachlichen Betreuer am Institut. Ich danke ihm fur die vielseitige Un- terstutzung, seine Geduld und sein Engagement.

Zu guter Letzt mbchte ich mich bei meiner gesamten Familie fur deren volle Unterstutzung bedanken.

Zusammenfassung

Ein moderner Einsatz zur Realisierung von flexiblen IT Landschaften sind Service- orientierte Architekturen (SOA). Hierzu wird ein Enterprise Service Bus (ESB) als eine technische Auspragung betrachtet. Heutzutage wird ein ESB entweder un- abhangig bei einem Rechner, oder auch bei Rechnerfarmen eingesetzt, das jedoch nicht elastisch ist. Daher ist eine schnelle und einfache Skalierbarkeit nach oben oder nach unten nicht moglich. Aufgrund dessen erscheint der Gedanke an ein Konzept zur Integration eines ESB in einer elastischen infrastructure-as-a-service Umgebung als notwendig.

Eine mogliche Umsetzung dieses Konzepts setzt eine Clusterbarkeit des ESB voraus. Die Anzahl der ESB-Cluster-Mitglieder, wird in Abhangigkeit zum Ressour- cenverbrauch, elastisch hoch und runter skaliert. Damit lassen sich signifikante und optimale Auslastungen der Ressourcen (Server...) erzielen und die Kundenanfragen auf allen ESB-Instanzen gleich gewichtig verteilen. Durch diese Elastizitat kann man flexibel auf Lastspitzen reagieren und schnelle Antwortzeiten gewaahrleisten.

Kapitel 1 Einleitung

1.1 Motivation

Auf einem sich stark andernden Markt, mtissen Unternehmen zur Sicherung ih- rer Existenz konkurrenzfahig sein. Hierzu gehort u.a. eine flexible Reaktion und verantwortungsbewusstes Handeln in Bezug auf Kundenbedurfnisse. So kommt es i.d.R. bei besonderen Ereignissen oder auch bei einer Vergrofierung des Unterneh- mens z.B. durch eine Fusion mit mehreren Firmen, zu einem drastischen Anstieg der Kundenanfragen. Hierbei kann es zu variablen Lastprofilen mit Lastspitzen, z.B. zu Weihnachten oder abends, wenn alle Feierabend haben, kommen. In solchen Fallen mussen die Unternehmen die Quality-of-Service kontinuierlich beibehalten konnen und die an die IT-Systeme gestellten Anforderungen wie Kosteneffizienz und kurze Antwortzeiten, erfuallen.

Dies stellt eine enorme Herausforderung fur Unternehmen dar, so dass auf die Erweiterung der IT-Infrastruktur zuritck gegriffen werden muss. In Bezug auf die Hardware muassen beispielsweise die Anzahl der zum Einsatz kommenden Server erhoht werden, die Qualitat der Rechner verbessert, das Netzwerk und dessen Band- breite vervielfaltigt und wenn notig, in Data-Center oder in Supercomputer inves- tiert werden. Bei der Software hingegen, mussen die IT-Systeme tiber besondere Eigenschaften verfugen. Besonders wesentlich erscheint die Fohigkeit auf mehreren Rechnern gleichzeitig und synchron arbeiten zu konnen^[1].

Um erfolgreich auf solche Szenarien einwirken zu konnen, ist das Vorhandensein von Eigenschaften wie Lastverteilung und Clusterbarkeit erforderlich. Zudem tragt eine flexible und automatische Verteilung der Software zu Kostenersparnissen bei. Aufierdem ermoglichen Uberwachungsansatze wie Monitoring und Logging die Be- obachtung des Softwareverhaltens und demzufolge die rechtzeitige Entdeckung und schnelle Behebung von Storungen.

Fur die Realisierung von flexiblen IT Landschaften, ist der Einsatz von Architek- turen wie service-oriented-architecture (SOA) empfehlenswert. Als mogliche techni- sche Auspragung fur SOA kommt der Enterprise Service Bus (ESB) in Betracht. Fur den Einsatz vom ESB stehen verschiedene Szenarien zur Verfugung. So kann dieser unabhangig bei einem Rechner eingesetzt werden, bei Rechnerfarmen oder auch auf einem physikalischen LAN^[2] geclustert werden. Beim letzten Szenarium, laufen mehrere Instanzen vom ESB auf viele Rechnern und arbeiten zusammen, um eine Aufgabe zu erledigen. Allerdings ermoglichen alle diese Einsatzszenarien nicht eine elastische Skalierbarkeit des ESB-Clusters, in der die Anzahl an ESB-Instanzen nach oben oder unten variiert werden.

1.2 Ziele

Ausgehend von dieser Problematik und um dem Ziel -Integration eines ESB in elas- tischen Infrastructure as a Service Umgebung- naher zu kommen, werden im Rahmen dieser Masterarbeit folgende Aspekte untersucht werden:

1. Es wird untersucht, wie ein Enterprise Service Bus in einer infrastructure-as- a-service integriert werden kann. Hierzu sollen zunachst die Anforderungen an dieser Integration festgelegt werden. Danach mussen eine Darbietung und ein Vergleich der moglichen Szenarien erfolgen.
2. Es sind die Voraussetzungen, die eine elastische Skalierbarkeit des Enterprise Service Bus nach oben oder nach unten ermoglichen, zu definieren.
3. Die Erarbeitung eines Konzepts zum automatischen Abfangen potentieller Lastspitzen in einer infrastrucutr-as-a-service (iaas) Umgebung ist notwen- dig.
4. Es erfolgt die Entwicklung eines SOA-mafiigen Prototyps fur die FCD-Kette der DLR-Traffic-Data-Platform.
5. Es muss die Prototypische Umsetzung des Konzepts zum automatischen Ab- fangen der Lastspitzen in einer iaas Umgebung erfolgen.
6. Abschliefiend ist die Simulation einer Uberlast beim FCD-Prozessierungsmodul durchzufuohren.

1.3 Aufbau der Arbeit

In Kapitel 2 werden die Grundlagen naher erortert. Zunachst werden die notwendi- gen Begriffe von service-oriented-architecture erlautert und dann die grundlegenden Konzepte eines Enterprise Service Bus geschildert. Zudem werden die bekanntes- ten OpenSource Produkte vom ESB vorgestellt. Danach erfolgt die Darstellung der wesentlichen Merkmale vom JBoss ESB wie Clustering und Dienstverwaltung, die ftir den weiteren Verlauf dieser Arbeit relevant sind. Anschliefiend wird das Cloud Computing prasentiert und ausfuhrlicher auf die Infrastructure-as-a-Service (IaaS) eingegangen. Zu guter Letzt wird ausgehend von den vorgestellten OpenSource ESBs einige verwandte Arbeiten vorgestellt und analysiert.

Unter Kapitel 3 werden die vorhandenen Moglichkeiten zur Realisierung eines ESB-Clusters analysiert, verglichen, und darauf basierend ein eigenes Konzept er- stellt, dass alle an das System gestellten Anforderungen herleitet, um ein entspre- chendes Verfahren fur die Integration eines ESB in einer elastischen iaas Umgebung zu erstellen. Danach wird die Strategie zum automatischen Abfangen von Lastspit- zen einer SOA-mafiigen Anwendung in einer iaas erarbeitet.

Unter Kapitel 4 erfolgt die technische Umsetzung des unter Kapitel 3 entwickel- ten Konzepts. Zunachst werden die notwendigen Konfigurationen fur das Deploy­ment eines JBoss ESB-Clusters erlautert. Anschliefiend folgen die technischen De­tails zur Integration eines ESBs in einer elastischen iaas und deren Verknupfung mit einem Cluster-ESB. Zudem wird die Implementierung von einem Lastuberwachung- Framework verdeutlicht.

Im Rahmen des Kapitels 5, erfolgt zu Beginn eine kurze Vorstellung des DLRs und des Instituts fur Verkehrssystemtechnik. Anschliefiend werden die Traffic-Data- Platform und das Floating-Car-Data-Prozessierungsmodul (FCD) erortert. Daraufhin folgt die Gestaltung und Umsetzung eines auf SOA basierenden Systems des FCD- Prozessierungsmoduls. Anschliefiend wird eine Uberwachung der FCD-Kette durch- gefuhrt, beobachtet sowie analysiert und gegebenenfalls bei vorhandener Uberlast Lastspitzen automatisch in einer iaas abgefangen.

Abschliefiend werden unter Kapitel 6 die erzielten Ergebnisse zusammengefasst sowie ein Ausblick auf weiterfuhrende Entwicklungsmoglichkeiten gegeben.

Kapitel 2 Grundlagen

Im vorliegenden Kapitel werden die Grundlagen naher erortert. Zunachst werden die notwendigen Begriffe von service-oriented-architecture erlautert und dann die grundlegenden Konzepte eines Enterprise Service Bus geschildert. Zudem werden die verschiedenen OpenSource ESB Produkte, JBoss-, Mule- und Sun Open ESB vorgestellt, von denen JBoss ESB als Kandidat fur den weiteren Verlauf der Analyse gewahlt und genauer unter die Lupe genommen wird. Anschliefiend wird der Begriff Cloud Computing eingefuhrt, definiert und Vor- und Nachteile erortert. Danach wird ausfuhrlicher auf die Infrastructure-as-a-Service (IaaS) eingegangen. Abschliefiend werden verwandte Arbeiten betrachtet.

2.1 Service Orientierte Architekturen

2.1.1 Definition und Prinzipien

Der Begriff SOA hat in den letzten Jahren sehr viel Aufmerksamkeit im Bereich des Softwaredesigns auf sich gezogen. Eine Serviceorientierte Architektur (engl. service- oriented-architecture ) wird definiert als “eine Anwendungsarchitektur, in (der alle Funktionen als unabhangige Services mit ujohldefinierten, aufrufbaren Schnittstellen vorliegen, so dass eine Auswahl -in einer sinnvollen Reihenfolge aufgerufen- einen Geschaftsprozess abdecken ”[RB07a].

Das SOA-Referenzmodell des Standardisierungsgremiums OASIS ^[1] definiert SOA als “ein Paradigma fur die Organisation und Verwendung verteilter Fahigkeiten, die unter der Kontrolle verschiedener Besitzerdomanen stehen konnen” [ELMT09].

Durch die Separation von datenorientierten Geschaftsdiensten, -prozessen, -regeln und Integrationslogik werden die Flexibilitat und die Wiederverwendbarkeit von Diensten ermbglicht. Aufierdem wird durch die asynchrone Kommunikation die lo­se Kopplung (Entkopplung) ausgelost, welches ein wesentliches Merkmal der SOA darstellt [Fin]. Zudem bestehen weitere zahlreiche Prinzipien und Aspekte, wie Er- weiterbarkeit, Skalierbarkeit, Verteilbarkeit, Komponierbarkeit, Wartung sowie das Anbieten, Suchen und Nutzen von Diensten, die das SOA-Profil ausmachen.

2.1.2 Dienst und SOA-Referenzarchitektur

Ein Dienst stellt die Kernkomponente einer SOA dar. Es kapselt eine Funktion ab und besitzt eine wohldefinierte Schnittstelle. Ein Dient wird folgendermafien defi- niert:

“In der Serviceorientierten Architektur (SOA) wird ein Dienst bzw. Ser­vice als eine Software-Komponente bezeichnet, die eine wohl definierte Funktionalitat uber eine standardisierte Schnittstelle anderen Services oder Anwendungen zur Verfugung stellt”

[RB07a]. Die SOA stellt eine Vielzahl voneinander unabhangiger, lose gekoppelter Dienste dar. Die SOA-Referenzarchitektur baut auf drei Saulen auf und kann als Dreieck dargestellt werden (vgl Abbildung 2.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Dreieck SOA-Referenzarchitektur [Gom10]

Dienste werden von Dienstanbieter (engl. service provider) in einem Dienstver- zeichnis (engl. Service Registry) veroffentlicht. Ein Dienstnutzer (engl. service consu­mer) fragt stetig beim Dienstverzeichnis nach einem Service und bekommt dement- sprechend die notwendigen Informationen (Adresse, Policy...). Daraufhin stellt der Client eine direkte Anfrage (engl. service request) an diesem Dienst und bekommt die entsprechende Antwort (service response) vom Anbieter. Diese Operationen werden als Publish-Find-Bind-Execute Modell bezeichnet [Wik10a].

2.1.3 Komposition von Diensten

Eine der hervorragendsten Fahigkeiten von SOA stellt die Service-Komposition dar. Dank der losen Kopplung, standardisierten und wohldefinierten Service-Schnittstellen, konnen Dienste in beliebigen Geschaftsprozessen integriert werden. Diese konnen entweder atomare oder aber auch komplexe Dienste sein. Somit bilden sich neue komplexe Dienste mit standardisierten Schnittstellen. Die Service-Komposition wird haufig in EAI^[2] und B2B-Integration^[3] Szenarien eingesetzt. Defaultmafiig sind zwei Kategorien der Service-Komposition vorhanden^[4]:

- Orchestrierung (engl. Orchestration): Bei dieser Kategorie wird diese Komposi­tion durch einen Koordinator (engl. Orchestrator) gesteuert. Mehrere Services werden in einem Geschaftsprozess integriert. Die Reihenfolge der Ausfuhrung wird vom Orchestrator bestimmt [RB07c].
- Choreographie (engl. Choreography): In diesem Szenarium werden die Sequenz und die Bedingung definiert, unter denen mehrere kooperierende unabhangige Dienste Nachrichten austauschen, um eine Aufgabe auszufuhren und dadurch ein Ziel zu erreichen [IMC05].

2.1.4 Technische Umsetzung

Es konnen unterschiedliche Technologien bei der Umsetzung von SOA zum Ein- satz kommen. In Betracht kommen u.a. .Net, CORBA^[5], XML-RPC, Web Services [RB07b]. I.d.R wird SOA liberwiegend mit Web-Services verbunden. Da SOA in den meisten Fallen in heterogenen, verteilten Umgebungen eingesetzt wird, ist die Nutzung einer Integrationslosung von grofier Bedeutung. Allgemein spricht man von einem Software-Bus, der die Integration zwischen verteilten, nicht kompatiblen An- wendungen anstrebt. Ein Beispiel hierfur ist der Enterprise Service Bus (ESB), der die technische Infrastruktur einer SOA auszeichnet.

2.2 Enterprise Service Bus

2.2.1 Definition und Aufgaben

Ahnlich wie bei einem Hardware-Bus, der die Integration der Hardware von ver- schiedenen Herstellern ermaglicht [KBS07], strebt ein ESB nach standardisierten Vorgehensweisen, Softwarekomponenten lose miteinander zu koppeln [BHR07]. Ein ESB wird auch als eine Kombination von traditionellen Middleware Technologien, XML und Webservices betrachtet [WQH+08].

In einer Vergleichstudie der AncudIT^[6] wird ein ESB folgendermafien defi- niert:

“ Unter einem Enterprise Service Bus (ESB) versteht man ein Software- produkt zur Unterstutzung der Integration verteilter Dienste in der he- terogenen Anwendungslandschaft eines Unternehmens(...) Der ESB er- laubt, einmal erstellte Funktionalitaten von Diensten fur andere Aufga­ben wieder zu verwenden. Dadurch verringert sich sukzessive der Ent- wicklungsaufwand bei der Erstellung weiterer Dienste im Sinne einer Serviceorientierten Architektur (SOA). Ein ESB fungiert also eine Art Dolmetscher zwischen Diensten verschiedener Hersteller, die ggf. unter Verwendung verschiedenster Technologien realisiert wurden. Der ESB sorgt fur die reibungsfreie Kommunikation zwischen den Diensten, idea- lerweise sollten hierfur keine Anderungen an den Diensten der verschie- denen Anwendungen selbst notig sein” [Scm10]

Zu den wesentlichsten Aufgaben eines ESB gehoren das (intelligente) Routing von Nachrichten unter Verwendung eines generischen Kommunikationsbusses liber alle Anwendungen- und Herstellergrenzen hinweg, die Transformation von Nachrich­ten in unterschiedlichen Formate, sowie das Bereitstellen von verschiedenen Nach- richtenprotokollen und Routing-Mechanismen [Scm10]. Zudem soll ein ESB auf die Verteilung und die Skalierbarkeit ausgelegt sein, um sich einer standig wachsenden Anzahl von IT-Systemen und Anwendungen anpassen zu konnen [BHR07].

2.2.2 ESB Architekturen

Bei einem ESB konnen unterschiedliche Architekturen zum Einsatz kommen. Im Allgemeinen wird zwischen den zwei folgenden Architekturen differenziert:

- Standard Architektur: Bei dieser wird die Java Business Integration(JBI) als Referenz-Spezifikation angenommen. Zu dieser Gruppe gehoren u.a. Produkte wie Sun Open ESB^[7], Apache ServiceMix, Petals Service Platform.
- Proprietare Architektur: Wie der Begriff Proprietar schon hindeutet, besitzt jedes ESB-Produkt seine eigene Architektur. Zu dieser Kategorie gehoren u.a. JBossESB, WSO2 ESB.

2.2.2.1 Standard Architektur

Der Enterprise Service Bus folgt der Java Business Integration(JBI). JBI ist eine Spezifikation, die unter Java Communtiy Process (JCP) fur ein Konzept zur Um- setzung einer Serviceorientierten Architektur entwickelt wurde. Das JCP JSR 208 ist Referenz fur JBI 1.0 und JSR 312 fur JBI 2.0 [Wik10b]. Diese Spezifikation definiert einen Standard fur eine Integrationsplattform und basiert auf einem lose gekoppelten Integrationsmodell, das den Aufbau einer Integrationsplattform erlaubt [Tro05].

Jeder JBI-basierter ESB besteht allgemein aus folgenden Komponenten [THW05]:

- Normalized Message Router (NMR): Dieser fungiert als Briicke zwischen den anderen JBI Komponenten, den Binding-Components (BC) und den Service- Engines (SE). Der NMR ist zustandig fur das Vermitteln (engl. Routing) der zu bearbeitenden Nachrichten zur Zielkomponente.
- (eine oder mehrere) Binding-Components (BC): Diese dienen als Adapter, da- mit die Inkonsistenz zwischen den Partnern (In-und Out ESB) auf Kommuni- kationsebene beseitigt wird und streben nach einer einheitlichen Nachrichten- Schnittstelle fur den NMR.
- (ein oder mehrere) Service Engine (SE): Ein Service-Engine ist the business logic driver eines JBI-Sytsems [THW05]. Es kann einfache Dienste wie XSLT- Transformation bei XSLT-Service Engine anbieten oder komplexe Aufgaben wie Service Komposition bei einem BPEL-Service Engine ubernehmen.
- Management Modul (MM): Fur die Administration der JBI Node und deren Komponente (BCs und SEs) werden verschiedene Typen von Management- Beans (MBean) definiert. Das Management Modul stellt Schnittstellen zur Installation von SEs und BCs bereit. Zudem kummert sich dieser um die Life­Cycle-Management der Komponenten (Start/Stop). Aufierdem ermoglicht die­ser das Deployment von Componenten-Artifacts in vorhandenen SE und BC. Ein Beispiel hierfur ist die Installation neuer XSLT^[8] Style Sheets in einer XSLT-Service Engine [WQH+08].
- External JMX-based Admin Tools: Ein Remote JMX-based Client ist fur die Kommunikation mit dem Management Modul zustandig, der somit einen orts- unabhangigen Zugriff auf dem MM ermoglicht.

Abbildung 2.2 gibt einen zusammenfassenden Uberblick uber alle Komponenten eines JBI Systems in einem Top-Level View.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Ansicht einer JBI Architektur
[THW05]

2.2.2.2 Proprietare Architektur

In diesem Kontext hat jeder ESB seine eigene Architektur. Allerdings existieren Komponente, die denen der Standard-Architektur ahneln. Hierbei befindet sich bei jedem Produkt eine Messaging-Router Komponente, die dieselben Aufgaben eines NMR erfullt. Es sind sowohl Engines zur Nachrichten-Transformation als auch Ad­apter zur Unterstutzung unterschiedlicher Transportprotokolle vorhanden.

2.3 Darbietung von bekannten OpenSource ESB Produkten

Die Auswahl an verfugbaren OpenSource Enterprise Service Bus Systemen ist sehr grofi, weshalb sich die Darbietung auf die folgenden drei bekannten ESB Produkte beschrankt:

- JBoss ESB
- Mule ESB
- Sun Open ESB

2.3.1 JBoss ESB

JBoss ESB JBoss ESB ist ein Produkt der Firma JBoss, die von Redhat im Jahre 2006 ubernommen wurde. Zu Beginn wurde es als Rosetta ESB von Aviva Canada auf den Markt gebracht [Ruc08]. JBoss ESB unterstutzt zahlreiche Transportpro- tokolle wie HTTP, JMS, Socket... Ab dem Release 4-2 ist eine Distribution von JBoss ESB-Instanzen uber mehrere (physikalische oder virtuelle) Knoten moglich (Clustering-Aspekt von ESB). Die Architektur vom JBoss ESB wird durch die Ab- bildung 2.3 verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Architektur von JBoss ESB [Ruc08]

2.3.2 Mule ESB

Mule ESB ist ein Produkt der Firma MuleSoft. Nach eigenen Angaben, bezeichnet sich, als der weltweit meist eingesetzte OpenSource ESB mit mehr als 1.5 Millionen Downloads [Mul10b]. Mule ESB wird bei vielen bekannten Firmen eingesetzt wie z.B Siemens, HP, Credit Suisse [BHR07]. Abbildung 2.4 gibt einen Uberblick liber Mule ESB.

Bei stetig wachsender Anzahl an Services und damit verbundener Auslastungen verhalt sich Mule ESB flexibel und stabil. Tatsachlich wird dieser ESB nach dem Mo- dell SEDA (staged event-driven Architecture) aufgebaut [BHR07]. Diese Architektur ermoglicht es, eine grofie Anzahl an gleichzeitigen Verbindungen zu bewaltigen, in- dem der ESB in einzelnen Teilen (sog. Stages) aufgeteilt wird. Diese Stages werden durch Message-Queues miteinander verbunden [BHR07]. Somit ist eine hohe Ent- kopplung und effiziente Skalierbarkeit der Mule-ESB-Komponenten gewahrleistet. Mule ESB untersttitzt viele Protokolle und kann in verschiedenen Szenarien ein-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Mule ESB: Uberblick [Mul10b]

gesetzt werden. Aufierdem stehen zahlreiche Adapter fur Standard-Softwares zur Verfugung, die jedoch mit einer kostenpflichtigen-Version verbunden sind. Allerdings ist eine eigene Entwicklung von Adaptern anhand des Mule-IDE-Plugins machbar [BHR07]. Abbildung 2.5 stellt u.a. die unterstutzten Transportprotokolle, Frame­works und Webservice-Standards dar.

2.3.3 Sun Open ESB (GlassFish ESB)

Open ESB ist ein Produkt der Firma Sun Microsystems (wurde von Oracle auf- gekauft). Es implementiert die Java Business Integration (JBI) Spezifikation. JBI ist ein Standard, um einen Enterprise Service Bus mit Hilfe von Java aufzubauen. Das Konzept sieht einen Container vor, der uber definierte Plugin-Schnittstellen erweitert werden kann [BHR07].

Open ESB ist eng mit dem Sun GlassFish Applikation Server und die NetBe- ans IDE gebunden. Somit ist eine ausfuhrliche und umfangreiche Plattform fur die Entwicklung SOA-fahiger Anwendungen bereitgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Technische Spezifikation von Mule ESB [Mul10b]

Nachfolgend erfolgt eine Aufzahlung der Komponenten, die Open ESB verwenden kann:

1. Binding Components: U.a. werden folgende Binding Components untersttitzt:

- e-Mail BC: Anbindung fur das Senden und das Empfangen von E-mails
- File BC: Anbindung an das Dateisystem
- HTTP BC: JBI Anbindung fur das Senden und das Empfangen von Nach- richten uber HTTP Protokolle
- Database BC: Anbindung fur das Lesen (bzw. das Schreiben) von Nach- richten aus (bzw. in) einer Datenbank anhand JDBC
- SAP BC: Anbindung fur SAP

2. Service Engine: U.a. werden folgende Service Engines unterstutzt:

- BPEL SE: WS-BPEL 2.0 fahige Engine fur Business Process Orchestra­tion
- Scripting SE: erlaubt das Scripting und Deployment in ESB
- Notfication SE: Unterstutzung von WS-Notification
- XSLT SE: XSLT Transformation Engine
- Data Mashup: Aufbau eines Data Mashup Systems

3. Shared Libraries: Folgende Shared Libraries sind u.a. derzeit verftigbar:

- sun-encoder-library
- sun-shared-util-library
- sun-transform-library
- sun-wsdl-library

2.4 JBoss ESB Clustering und Dienstverwaltung

2.4.1 Dienstverwaltung in JBoss ESB

In der Welt von JBoss ESB werden lediglich Nachrichten und Dienste definiert. Tatsachlich folgt JBoss ESB eine Message-driven-Pattern fur die Verwaltung der In­teraction zwischen Kunden und Diensten [mas10]. Diese Interaktion wird als Folge von Anfragen und Antworten durchlaufen. Jede registrierte Service wird benachrich- tigt, wenn eine neue Nachricht fur sie eintrifft.

Prinzipiell erkennt JBoss ESB zwei Kategorien von Nachrichten an:

- Externe Nachrichten: Diese sollen von Systemen, die sich aufierhalb vom ESB befinden, geschickt werden. Ein Beispiel hierfur sind die Kundenanfragen.
- Interne Nachrichten (auch als ESB-Aware-Message bezeichnet): JBoss ESB definiert seinen eigenen Nachrichtenformat fur die interne Bearbeitung. Eine ESB-Aware Nachricht besteht aus einem Header, einem context, einem Body und aus einem Attachment. Der Body Teil beinhaltet die nutzlichen Daten. Diese werden als (<keys>-<values>) Mengen dargestellt. Abbildung 2.6 gibt einen allgemeinen Uberblick uber den Aufbau einer ESB-Aware Nachricht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Uberblick uber den Aufbau einer ESB-Aware-Message [JBo10a]

Intern besteht ein Dienst aus einer Kette von Aktionen, die die ankommenden Nachrichten nacheinander bearbeitet. Die Kette wird standardgemafi als Action-Pipeline bezeichnet [mas10]. Die Logik einer Aktion hangt von der Implementierung ab. So kann zum Beispiel eine Aktion fur die Transformation des Nachrichtenformats von CSV zu XML zustandig sein, wahrend eine andere fur die Aktualisierung einer Da- tenbank, beispielsweise durch das Hinzufugen neuer Daten, verantwortlich ist. Ab- bildung 2.7 zeigt ein solches Beispiel fur eine Action-Pipeline.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Beispiel einer Actions-Pipeline [mas10]

Jedem Dienst steht eine Nachritenwarteschlange (engl. message-queue) zur Verfugung. Diese werden vom Messaging-System des JBoss Application Servers (JBoss AS) zur Nutzung bereitgestellt. In diesen werden die eintreffenden Nachrichten erstmals ge- speichert, bevor sie bearbeitet werden, um die Uberlastung von Diensten -soweit wie moglich- zu verhindern. Sollten freie Ressourcen ausreichend zur Verfugung stehen, dann wird die Nachricht bearbeitet.

Ein Dienst kann beliebig viele Listeners definieren. Diese stehen als Inbound- Router fur den Dienst zur Verfugung [JBo10a] und kummern sich um das Routen von ankommenden Nachrichten an die Action-Pipeline. Diese Listeners werden -einmal der Service in ESB deployed - als Endpoints in der vom JBoss ESB bereit- gestellten Registry gespeichert.

JBoss ESB unterscheidet zwischen zwei Kategorien von Listeners [JBo10a]:

- Gateways Listeners: Diese stellen Gateway Endpoints bereit und sind zustandig fur die Normalisierung von externen Nachrichten durch deren Transformation (engl. Wrapping) zu einer ESB-Aware Nachricht.
- ESB-Aware Listeners: Diese stellen ESB-Aware Endpoints bereit, die dem Austausch von ESB-Aware Nachrichten zwischen den ESB-Aware Komponen- ten dienen.

Da Dienste nur ESB-Aware-Nachrichten bearbeiten kdnnen, benotigen diese fur die Bearbeitung von Nachrichten, die Aufienseiters des JBoss ESBs ankommen, Gateways. Abbildung 2.8 stellt einen Beispiel von Interaktion zwischen einen ESB- Service und eienem JMS-Klient.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Interaktion zwischen einen ESB-Dienst und einen JMS-Klient [mas10]

2.4.2 JGroups und Clustering in JBoss AS

Anforderungen wie Ausfallsicherheit, Lastverteilung und Skalierbarkeit konnen durch Cluserting entsprochen werden. Im Fall des JBoss Application Servers (JBoss AS), be- steht ein Cluster aus einer Menge von untereinander vernetzten JBoss AS, die als ein Computer angesehen werden konnen. Jeder Cluster-Instanz kennt den Zustand von anderen Mitgliedern. Wenn ein Cluster-Mitglied ausfallt, konnen andere Mit- glieder die noch offenen Aufgaben ubernehmen [Mol10]. Ein Cluster ist meist fur den Klient transparent, d.h. er weifi nicht ob die eingesetzte Anwendung geclustert oder ungeclustert ist [Mol10].

Zu den Nachteilen eines Clusters gehort eine nicht lineare Skalierbarkeit. Hierbei wird mit zunehmender Anzahl der Knoten auch der Verwaltungsaufwand hoher, was sich negativ auf die Performance der geclusterten Anwendung auswirkt [Mol10].

Prinzipiell sind drei Kategorien des Clusterings vorhanden [Mol10]:

- Vertikaler Cluster: Bei diesem Typ laufen alle JBoss AS-Instanzen auf dersel- ben Maschine, welche physischer oder virtueller Natur sein kann.
- Horizontaler Cluster: Bei diesem Clustertyp werden die Cluster-Mitglieder auf unterschiedliche Maschinen verteilt.
- Misch-Cluster: Dieser stellt eine Kombination der beiden oben genannten Clustertypen.

Die Cluster-Kommunikation soll mittels JavaGroups (auch JGroups genannt) Fra­mework erfolgen, welche eine zuverlassige Multicast - (bzw. Unicast) Kommunikati- on und Auto-Discovery anbietet [Mol10]. JavaGroups ist ein Java-basiertes-Toolkit fur zuverlassige Gruppenkommunikation. Dieses Toolkit ermoglicht das Senden und Empfangen von Nachrichten von und zu allen Gruppenmitglieder. Zudem sichert dieser, dass alle Knoten die gleichen Nachrichten-Sequenzen in der gleichen Reihen- folge erhalten [Ban10a].

JGroups definiert zwei Hauptkomponenten und zwar:

- Channels: Diese ahneln den BSD Sockets. Beim Verbinden mit einem Channel gibt jedes Mitglied den Namen der Gruppe an, an die er sich anschliefien will, um Nachrichten senden und empfangen zu konnen. Zudem wird diese uber den Status aller Clustermitglieder benachrichtigt, das bedeutet, diese hat einen Uberblick daruber wer gerade an der Gruppe angeschlossen ist und wer nicht [Ban10a].
- Protocol Stack: Dieser besteht aus mehreren Schichten, von denen jede ein Protokoll abbildet, welches nicht zwangslaufig auch ein Netzwerktransport- protokoll sein muss [Mol10]. Wenn eine Nachricht versendet wird, wandert diese beim Sender den Protocol-Stack runter und beim Empfanger den Stack wieder rauf [Mol10].

Abbildung 2.9 zeigt die Architektur der JGroups.

2.5 Cloud Computing und IaaS

2.5.1 Cloud Computing: Definition, Eigenschaften und Ein- satzszenarien

Werden zehn unterschiedliche IT-Experten nach der Definition von Cloud Compu­ting gefragt, bekommt man zehn unterschiedliche Antworten. Das liegt daran, dass Cloud Computing in unterschiedlichen Einsatzszenarien verwendet werden kann. Fur den Begriff Cloud Computing gibt es derzeit noch keine eindeutige Definition, sondern viele zahlreiche Erklarungsmodelle. Einige vertreten die Ansicht, dass Cloud Computing keine neue Erfindung der IT-Welt ist, sonder viel eher ein Sammelbe- griff fur verschiedene Dienstleistungen, die uber das Internet beansprucht werden konnen [htt10]. Andere wiederum betrachten, dass Cloud Computing als eine Wei- terentwicklung bekannter Computing-Modelle: (Grid Computing - Utility Compu­ting - Application Serv. Providing (ASP) - Cloud Computing) [Emb09]. Das NIST

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: JGroups-Architektur [BGPS]

^[9] -Information Technology Laboratory stellt die folgende allgemeine standardisierte Definition ^[10] von Cloud Computing bereit:

“Cloud Computing is a pay-per-use model for enabling available, conve­nient, on-demand network access to a shared pool of configurable com­puting ressources (e.g.,networks, servers, storage, applications,services) that can be rapidly provisioned a,nd released with minimal management effort or service provider interaction.” [S.L09].

Diese Definition enthalt die funf folgenden Schltisseleigenschaften [S.L09]:

1. Auf Wunsch Bedienung (engl. On-demand self-service): Diese Eigenschaft ent- spricht der Fahigkeit der Nutzung von Rechnerressourcen ohne menschliche Interaktion mit dem Serviceprovider.
2. Allgegenwartiger Netwerkzugang (engl. Ubiquitous network access) : Diese Komponente ermoglicht Es ist mit Hilfe von standardisierten Mechanismen moglich von iiberall auf Ressourcen zuzugreifen. Der Zugriff auf Ressourcen ist von Iiberall anhand standardisierte Mechanismen moglich.
3. Aufenthaltsunabhongige Nutzung der Ressourcen (engl. Location-independant ressource pooling): Der Aufenthaltsort der Cloudressourcen ist fur den Konsu- menten transparent.
4. Schnelle Elastizitot (engl. rapid elasticity): Diese Eigenschaft ermoglicht die schnelle Bereitstellung der Ressourcen sowie die elastische Skalierung nach oben (engl. scale up) oder nach unten (engl. scale down).
5. Die verbrauchorientierte Bezahlung (engl. Pay-per-use): Vorliegend wird die Benutzung von Ressourcen mit Hilfe von metered Services durchgefuhrt.

Cloud Computing wird haufig u.a. in Szenarien eingesetzt, die eine schnelle Re- aktion auf moglichen Anderungen an den Geschoftsprozess, benotigen. Hierzu bildet die IT-Infrastruktur meistens, im Fall von z.B. einer Vergrofierung des Unternehmens durch eine Fusion, eine Singel-Point-Of-Latency ^[11]. Wohrend die Wartung und die Erweiterung der IT-Infrastruktur und der Enterprise-Infrastruktur immer schwer und manchmal unmoglich sind, ondern sich die Geschaftsprozesse kontinuierlich, weil sie von den Upturns and dowturns der Wirtschaft beeinflusst werden [S.L09]. In diesem Fall bietet Cloud Computing eine hervorragende Losung durch den Ein- satz von On-Demand Ressourcen auf allen moglichen Ebenen (IT-Infrastruktur, Software, Prozesse...) an.

2.5.2 Cloud Computing: Vor- und Nachteile

Zu den Vorteilen von Cloud Computing zaohlen das Reduzieren von Kosten, da lo- kal der Einsatz von Hardware und Software geringer ausfollt. Andere Firmen, die houfig Cloud Providers genannt werden, sorgen fur die Bereitstellung von Rechen- zentren, Storage Devices , Netzwerk Ressourcen und kaufen Lizenzen fur die notwen- digen Softwares ... Pflichtgebundene Vertrage sind nicht mehr notwendig um Dienst- leistungen von Rechenzentren in Anspruch nehmen zu konnen. Stattdessen werden neue Abrechnungsmodelle, wie Bezahlung nach Nutzung von Services (Pay-as-you- go ) eingefuhrt: bezahlt wird nur was tatsochlich beansprucht wird. IT-Abteilungen konnen sich hierdurch eher auf ihre strategischen Projekte fokussieren, anstatt deren Rechenzentren laufen zu lassen um eingebundene Probleme zu beseitigen [TJE09]. Zudem werden durch Cloud Computing neue Arbeitsformen wie Heimarbeit und Telearbeit ermoglicht [htt10].

Nichtsdestotrotz erschweren viele Nachteile die Akzeptanz von Cloud Computing. Hierzu gehoren die Sicherheitsprobleme, die durch das Befinden von unternehmens- kritischen Daten aufierhalb der eigenen Verfugungsmacht entstehen. Aufierdem stellt der Zugriff auf Cloud Computing Ressourcen einen Singel-Point-of-Failure Probleme im Fall eines Abbruchs von der Internet Verbindung dar, da dieser Zugriff nur liber das Web maglich ist. Darlber hinaus kannen Unternehmensdaten in Gefahr geraten, wenn die Leistungen des Cloud-Computing Dienstanbietres gestoppt^[12] werden, wie es beispielsweise bei einer Insolvenz der Fall ist [htt10].

2.5.3 Cloud Computing BigPlayers

Zahlreiche Firmen bieten Heutzutage sowohl Cloud-Dienste als auch Cloud-Ressourcen. Allerdings gelingt der Durchbruch als Titan nur wenigen Firmen bzw. als First Mo­vers in the Cloud. Zu denen mit den grafiten Marktanteilen gehlren Amazon, Google und Microsoft. Nachfolgend werden die sogenannten drei Big Players und deren Pro- dukte kurz beschrieben:

1. Amazon ist eine der ersten Firmen, die Cloud Dienste fur offentliche Nutzun- gen bereitgestellt hat, zu denen u.a. folgende Produkte zahlen [TJE09]:

- Elastic Compute Cloud (EC2), welches virtuelle Maschinen fur die Be- nutzer anbietet.
- Simple Storage Service (S3), welches das Speichern von Daten bis 5GB im Amazon’s virtual Storage service ermoglicht.
- Simple Queue Service (SQS), das eine zuverlassige, hochskalierbare, gehostete Warteschlange zum Speichern von Mitteilungen bietet, wahrend diese zwischen den Computern weitergeleitet werden [Web10].

Figure 2.10 stellt alle Produkte von Amazon Webservices dar.

2. Google: ermoglicht mit seinem Produkt Google’s App Engine dem Entwickler die Erstellung und das Deplyoment ihrer Webanwendungen in der gleichen Infrastruktur, in denen Google ihre eigene Anwendungen deploy und somit die Integration mit anderen Google Services vereinfacht [TJE09].

3. Microsoft: bietet eine Cloud Computing Losung in Form der Azure Services Plattform ^[13]. Diese Plattform besteht aus mehreren Diensten, die zahlreiche Leistungen anbieten, wie das User Identity Management, die Synchronisation von Daten und das Workflovj-Management.

[...]

---

^[1] In diesem Zusammenhang sind zahlreiche Aspekte der verteilten Systeme enthalten, die im weiteren Verlauf vorgestellt werden

^[2] Local Area Network

^[1] OASIS: Organization for the Advancement of Structured Information Standards

^[2] Enterprise Application Integration

^[3] Business-to-business

^[4] In der Realitat gibt es auch eine andere Kategorie: Konversation, die aber selten verwendet wird

^[5] CORBA ist eine Middleware zur Kommunikation zwischen Anwendungen, unabhangig von den verwendeten Programmiersprachen, Hardware sowie Software und Netzwerken.

^[6] Ancud IT-Beratung GmbH: http://www.ancud.de/

^[7] derzeit auch Glassfish ESB genannt

^[8] Extensible Stylesheet Language Transformation

^[9] NIST: The National Institute of Standards and Technology

^[10] Eine andere Definition laut IBM ist: Cloud Computing ist eine Form der IT-Nutzung, bei der Endbenutzer Applikationen, Daten und IT-Infrastrukturkomponenten in Form von Services uber ein Web nutzen und eine grofie Anzahl virtualisierter IT-Ressourcen so steuern konnen, dass sie vie eine einzige IT-Umgebung erscheinen. [Emb09].

^[11] Singel-Point-of-Latency: die Unfahigkeit einer IT-Infrastruktur auf einer schnelle Reaktion auf die Anderungen des Businessprozess, wobei alle anderen Abteilungen z.B sales executives, HumanRessourcen ... auf solche Anderungen flexible sind. Siehe [S.L09]

^[12] Ein gutes Beispiel hierfur ist der Fall vom WikiLeaks.org bei Amazon.

^[13]http://www.microsoft.com/windowsazure/