Vorwort und Danksagung

Die vorliegende Masterarbeit ist im Rahmen meiner T¨ atigkeit bei dem Deutschen Zentrum f¨ ur Luft- und Raumfahrt in Berlin entstanden.

Ich war in dem Institut f¨ ur Verkehrssystemtechnik besch¨ aftigt. Diese Arbeit ist Teil meines Studiums der Informatik an der Technischen Universit¨ at in Berlin. Mein erster Dank geht an Herrn Professor Dr. habil. Odej Kao f¨ ur die Themenstellung und die fachliche Betreuung seitens der Universit¨ at. An dieser Stelle m¨ ochte ich mich auch beim Herrn Prof. Dr. Hans-Ulrich Heiß f¨ ur die Begutachtung dieser Masterarbeit bedanken. Mein Dank gilt ebenfalls dem gesamten Team des Fachgebietes Komplexe und Verteilte IT-Systeme der Technischen Universit¨ at Berlin, die mir stets das notwendige Equipment f¨ ur eine effektive Bearbeitung dieser Arbeit bereitgestellt haben. Ein besonderer Dank richtet sich an Dr. Andr´ e H¨ oing und Dr. Matthias Hovestadt, die meine Arbeit betreut haben. Ihre vorbildliche und kontinuierliche Unterst¨ utzung hat wesentlich zum Gelingen dieser Masterarbeit beigetragen. Meinen Dank m¨ ochte ich ebenfalls an allen Mitgliedern des DLR-Institutes f¨ ur Verkehrssystemtechnik, die mich weitestgehend unterst¨ utzt und beraten haben.

Besonderer Dank geht an Herrn Dipl.-Ing. Louis Calvin Touko Tcheumadjeu, meinem fachlichen Betreuer am Institut. Ich danke ihm f¨ ur die vielseitige Unterst¨ utzung, seine Geduld und sein Engagement.

Zu guter Letzt m¨ ochte ich mich bei meiner gesamten Familie f¨ ur deren volle Unterst¨ utzung bedanken.

ii

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 Auspr¨ agung betrachtet. Heutzutage wird ein ESB entweder unabh¨ angig 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 m¨ oglich. Aufgrund dessen erscheint der Gedanke an ein Konzept zur Integration eines ESB in einer elastischen infrastructure-as-a-service Umgebung als notwendig.

Eine m¨ ogliche Umsetzung dieses Konzepts setzt eine Clusterbarkeit des ESB voraus. Die Anzahl der ESB-Cluster-Mitglieder, wird in Abh¨ angigkeit zum Ressourcenverbrauch, 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 Elastizit¨ at kann man flexibel auf Lastspitzen reagieren und schnelle Antwortzeiten gew¨ ahrleisten.

Inhaltsverzeichnis

Inhaltsverzeichnis   iii

1  Einleitung  1

1.1  Motivation  1

1.2  Ziele  2

1.3  Aufbau der Arbeit  3

2  Grundlagen  4

2.1  Service Orientierte Architekturen  4

2.1.1  Definition und Prinzipien  4

2.1.2  Dienst und SOA-Referenzarchitektur  5

2.1.3  Komposition von Diensten  6

2.1.4  Technische Umsetzung  6

2.2  Enterprise Service Bus  7

2.2.1  Definition und Aufgaben  7

2.2.2  ESB Architekturen  7

2.3  Darbietung von bekannten OpenSource ESB Produkten  9

2.3.1  JBoss ESB  10

2.3.2  Mule ESB  10

2.3.3  Sun Open ESB (GlassFish ESB)  11

2.4  JBoss ESB Clustering und Dienstverwaltung  13

2.4.1  Dienstverwaltung in JBoss ESB  13

2.4.2  JGroups und Clustering in JBoss AS  15

2.5  Cloud Computing und IaaS  16

2.5.1  Cloud Computing: Definition, Eigenschaften und Einsatzsze-  

narien   16

2.5.2  Cloud Computing: Vor- und Nachteile  18

2.5.3  Cloud Computing BigPlayers  19

2.5.4  Infrastructure-as-a-Service(IaaS)  20

2.6  Verwandte Arbeiten  21

2.6.1  Unterst utzung von ESB-Clustering  21

2.6.2  Unterst utzung von Cloud Computing  23

ii

3 Analyse und Konzept 24

3.1 Distributed Service Bus (DSB) . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1 Central-based-Management Distributed Service Bus . . . . . . 25 3.1.2 Peer-To-Peer basierter DSB . . . . . . . . . . . . . . . . . . . 27 3.1.3 Auswertung und Vergleich . . . . . . . . . . . . . . . . . . . . 29 3.1.4 Eigenes Konzept . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Integration eines ESBs in einer elastischen Umgebung (IaaS) . . . . . 30 3.2.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.2 Aufbaum¨ oglichkeiten . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Automatisches Abfangen der Anfrage-Lastspitzen in SOA anhand von Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1 Vorstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.2 Arbeitsweise des LoadMonitoringFrameworks (LMF) . 37

4 Implementierung 39

4.1 Realisierung vom Clustered JBoss ESB . . . . . . . . . . . . . . . . . 39 4.2 Einstellungen zur Integration vom JBoss ESB in einer IaaS . . . . . . 43 4.3 Erzeugung von der JBoss ESB-AMI . . . . . . . . . . . . . . . . . . . 46 4.4 Umsetzung des LoadMonitoringFrameworks . . . . . . . . . . . . . . 50 4.5 Schwierigkeiten bei der Umsetzung . . . . . . . . . . . . . . . . . . . 55

5 Evaluation anhand einer Fallstudie: DLR-Traffic Data Platform/FCD-Prozessierungsmodul 56

5.1 Einf¨ uhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.1 Vorstellung des DLRs und des DLR-TSs . . . . . . . . . . . . 56 5.1.2 Beschreibung der Traffic-Data-Platform . . . . . . . . . . . . . 58 5.1.3 Vorstellung vom FCD-Processierungsmodul (oder FCD-Kette) 59 5.2 SOA-m¨ aßiger Aufbau der FCD Kette . . . . . . . . . . . . . . . . . . 60 5.2.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.2.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 Simulation des automatischen Abfangens der Lastspitzen basierend auf Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Zusammenfassung 71

Anhang i

iii

Kapitel 1

Einleitung

1.1 Motivation

Auf einem sich stark ¨ andernden Markt, m¨ ussen Unternehmen zur Sicherung ihrer Existenz konkurrenzf¨ ahig sein. Hierzu geh¨ ort u.a. eine flexible Reaktion und verantwortungsbewusstes Handeln in Bezug auf Kundenbed¨ urfnisse. So kommt es i.d.R. bei besonderen Ereignissen oder auch bei einer Vergr¨ oßerung des Unternehmens 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 F¨ allen m¨ ussen die Unternehmen die Quality-of-Service kontinuierlich beibehalten k¨ onnen und die an die IT-Systeme gestellten Anforderungen wie Kosteneffizienz und kurze Antwortzeiten, erf¨ ullen.

Dies stellt eine enorme Herausforderung f¨ ur Unternehmen dar, so dass auf die Erweiterung der IT-Infrastruktur zur¨ uck gegriffen werden muss. In Bezug auf die Hardware m¨ ussen beispielsweise die Anzahl der zum Einsatz kommenden Server erh¨ oht werden, die Qualit¨ at der Rechner verbessert, das Netzwerk und dessen Bandbreite vervielf¨ altigt und wenn n¨ otig, in Data-Center oder in Supercomputer investiert werden. Bei der Software hingegen, m¨ ussen die IT-Systeme ¨ uber besondere

Eigenschaften verf¨ ugen. Besonders wesentlich erscheint die F¨ ahigkeit auf mehreren Rechnern gleichzeitig und synchron arbeiten zu k¨ onnen ¹ .

Um erfolgreich auf solche Szenarien einwirken zu k¨ onnen, ist das Vorhandensein von Eigenschaften wie Lastverteilung und Clusterbarkeit erforderlich. Zudem tr¨ agt eine flexible und automatische Verteilung der Software zu Kostenersparnissen bei. Außerdem erm¨ oglichen ¨ Uberwachungsans¨ atze wie Monitoring und Logging die Beobachtung des Softwareverhaltens und demzufolge die rechtzeitige Entdeckung und

¹ In diesem Zusammenhang sind zahlreiche Aspekte der verteilten Systeme enthalten, die im weiteren Verlauf vorgestellt werden

1

schnelle Behebung von St¨ orungen.

F¨ ur die Realisierung von flexiblen IT Landschaften, ist der Einsatz von Architekturen wie service-oriented-architecture (SOA) empfehlenswert. Als m¨ ogliche technische Auspr¨ agung f¨ ur SOA kommt der Enterprise Service Bus (ESB) in Betracht. F¨ ur den Einsatz vom ESB stehen verschiedene Szenarien zur Verf¨ ugung. So kann dieser unabh¨ angig bei einem Rechner eingesetzt werden, bei Rechnerfarmen oder auch auf einem physikalischen LAN ² geclustert werden. Beim letzten Szenarium, laufen mehrere Instanzen vom ESB auf viele Rechnern und arbeiten zusammen, um eine Aufgabe zu erledigen. Allerdings erm¨ oglichen 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 elastischen Infrastructure as a Service Umgebung- n¨ aher zu kommen, werden im Rahmen dieser Masterarbeit folgende Aspekte untersucht werden:

1. Es wird untersucht, wie ein Enterprise Service Bus in einer infrastructure-asa-service integriert werden kann. Hierzu sollen zun¨ achst die Anforderungen an dieser Integration festgelegt werden. Danach m¨ ussen eine Darbietung und ein Vergleich der m¨ oglichen Szenarien erfolgen.

2. Es sind die Voraussetzungen, die eine elastische Skalierbarkeit des Enterprise Service Bus nach oben oder nach unten erm¨ oglichen, zu definieren. 3. Die Erarbeitung eines Konzepts zum automatischen Abfangen potentieller Lastspitzen in einer infrastrucutr-as-a-service (iaas) Umgebung ist notwendig.

4. Es erfolgt die Entwicklung eines SOA-m¨ aßigen Prototyps f¨ ur die FCD-Kette der DLR-Traffic-Data-Platform.

5. Es muss die Prototypische Umsetzung des Konzepts zum automatischen Abfangen der Lastspitzen in einer iaas Umgebung erfolgen. 6. Abschließend ist die Simulation einer ¨ Uberlast beim FCD-Prozessierungsmodul durchzuf¨ uhren.

² Local Area Network

2

1.3 Aufbau der Arbeit

In Kapitel 2 werden die Grundlagen n¨ aher er¨ ortert. Zun¨ achst werden die notwendigen Begriffe von service-oriented-architecture erl¨ autert und dann die grundlegenden Konzepte eines Enterprise Service Bus geschildert. Zudem werden die bekanntesten OpenSource Produkte vom ESB vorgestellt. Danach erfolgt die Darstellung der wesentlichen Merkmale vom JBoss ESB wie Clustering und Dienstverwaltung, die f¨ ur den weiteren Verlauf dieser Arbeit relevant sind. Anschließend wird das Cloud Computing pr¨ asentiert und ausf¨ uhrlicher 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 M¨ oglichkeiten zur Realisierung eines ESB-Clusters analysiert, verglichen, und darauf basierend ein eigenes Konzept erstellt, dass alle an das System gestellten Anforderungen herleitet, um ein entsprechendes Verfahren f¨ ur die Integration eines ESB in einer elastischen iaas Umgebung zu erstellen. Danach wird die Strategie zum automatischen Abfangen von Lastspitzen einer SOA-m¨ aßigen Anwendung in einer iaas erarbeitet. Unter Kapitel 4 erfolgt die technische Umsetzung des unter Kapitel 3 entwickelten Konzepts. Zun¨ achst werden die notwendigen Konfigurationen f¨ ur das Deployment eines JBoss ESB-Clusters erl¨ autert. Anschließend folgen die technischen Details zur Integration eines ESBs in einer elastischen iaas und deren Verkn¨ upfung mit einem Cluster-ESB. Zudem wird die Implementierung von einem Last¨ uberwachung-Framework verdeutlicht.

Im Rahmen des Kapitels 5, erfolgt zu Beginn eine kurze Vorstellung des DLRs und des Instituts f¨ ur Verkehrssystemtechnik. Anschließend werden die Traffic-Data-Platform und das Floating-Car-Data-Prozessierungsmodul (FCD) er¨ ortert. Daraufhin folgt die Gestaltung und Umsetzung eines auf SOA basierenden Systems des FCD-Prozessierungsmoduls. Anschließend wird eine ¨ Uberwachung der FCD-Kette durchgef¨ uhrt, beobachtet sowie analysiert und gegebenenfalls bei vorhandener ¨ Lastspitzen automatisch in einer iaas

abgefangen. Abschließend werden unter Kapitel 6 die erzielten Ergebnisse zusammengefasst sowie ein Ausblick auf weiterf¨ uhrende Entwicklungsm¨ oglichkeiten gegeben.

3

Kapitel 2

Grundlagen

Im vorliegenden Kapitel werden die Grundlagen n¨ aher er¨ ortert. Zun¨ achst werden die notwendigen Begriffe von service-oriented-architecture erl¨ autert 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 f¨ ur den weiteren Verlauf der Analyse gew¨ ahlt und genauer unter die Lupe genommen wird. Anschließend wird der Begriff Cloud Computing eingef¨ uhrt, definiert und Vor- und Nachteile er¨ ortert. Danach wird ausf¨ uhrlicher auf die Infrastructure-as-a-Service (IaaS) eingegangen. Abschließend 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 unabh¨ angige Services mit wohldefinierten, aufrufbaren Schnittstellen vorliegen, so dass eine Auswahl -in einer sinnvollen Reihenfolge aufgerufen- einen Gesch¨ aftsprozess abdecken”[RB07a].

Das SOA-Referenzmodell des Standardisierungsgremiums OASIS ¹ definiert SOA als

“ein Paradigma f¨ ur die Organisation und Verwendung verteilter F¨ ahigkeiten,

¹ OASIS: Organization for the Advancement of Structured Information Standards

4

die unter der Kontrolle verschiedener Besitzerdom¨ anen stehen k¨ onnen” [ELMT09].

Durch die Separation von datenorientierten Gesch¨ aftsdiensten, -prozessen, -regeln und Integrationslogik werden die Flexibilit¨ at und die Wiederverwendbarkeit von Diensten erm¨ oglicht. Außerdem wird durch die asynchrone Kommunikation die lose Kopplung (Entkopplung) ausgel¨ ost, welches ein wesentliches Merkmal der SOA darstellt [Fin]. Zudem bestehen weitere zahlreiche Prinzipien und Aspekte, wie Erweiterbarkeit, 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 folgendermaßen definiert:

“In der Serviceorientierten Architektur (SOA) wird ein Dienst bzw. Service als eine Software-Komponente bezeichnet, die eine wohl definierte Funktionalit¨ at ¨ uber eine standardisierte Schnittstelle anderen Services oder Anwendungen zur Verf¨ ugung stellt”

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

Dienste werden von Dienstanbieter (engl. service provider ) in einem Dienstverzeichnis (engl. Service Registry) ver¨ offentlicht. Ein Dienstnutzer (engl. service consu-

5

mer ) fragt stetig beim Dienstverzeichnis nach einem Service und bekommt dementsprechend 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 F¨ ahigkeiten von SOA stellt die Service-Komposition dar. Dank der losen Kopplung, standardisierten und wohldefinierten Service-Schnittstellen, k¨ onnen Dienste in beliebigen Gesch¨ aftsprozessen integriert werden. Diese k¨ onnen entweder atomare oder aber auch komplexe Dienste sein. Somit bilden sich neue komplexe Dienste mit standardisierten Schnittstellen. Die Service-Komposition wird h¨ aufig in EAI ² und B2B-Integration ³ Szenarien eingesetzt. Defaultm¨ aßig sind zwei Kategorien der Service-Komposition vorhanden ⁴ :

ˆ Orchestrierung (engl. Orchestration): Bei dieser Kategorie wird diese Komposition durch einen Koordinator (engl. Orchestrator) gesteuert. Mehrere Services werden in einem Gesch¨ aftsprozess integriert. Die Reihenfolge der Ausf¨ uhrung wird vom Orchestrator bestimmt [RB07c].

ˆ Choreographie (engl. Choreography): In diesem Szenarium werden die Sequenz und die Bedingung definiert, unter denen mehrere kooperierende unabh¨ angige Dienste Nachrichten austauschen, um eine Aufgabe auszuf¨ uhren und dadurch ein Ziel zu erreichen [IMC05].

2.1.4 Technische Umsetzung

Es k¨ onnen unterschiedliche Technologien bei der Umsetzung von SOA zum Einsatz kommen. In Betracht kommen u.a. .Net, CORBA ⁵ , XML-RPC, Web Services [RB07b]. I.d.R wird SOA ¨ uberwiegend mit Web-Services verbunden. Da SOA in

den meisten F¨ allen in heterogenen, verteilten Umgebungen eingesetzt wird, ist die Nutzung einer Integrationsl¨ osung von großer Bedeutung. Allgemein spricht man von einem Software-Bus, der die Integration zwischen verteilten, nicht kompatiblen Anwendungen anstrebt. Ein Beispiel hierf¨ ur ist der Enterprise Service Bus (ESB), der die technische Infrastruktur einer SOA auszeichnet.

² Enterprise Application Integration

³ Business-to-business

⁴ In der Realit¨ at gibt es auch eine andere Kategorie: Konversation, die aber selten verwendet wird

⁵ CORBA ist eine Middleware zur Kommunikation zwischen Anwendungen, unabh¨ angig von den verwendeten Programmiersprachen, Hardware sowie Software und Netzwerken.

6

2.2 Enterprise Service Bus

2.2.1 Definition und Aufgaben

¨ Ahnlich wie bei einem Hardware-Bus, der die Integration der Hardware von verschiedenen Herstellern erm¨ oglicht [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 ⁶ wird ein ESB folgendermaßen definiert:

“Unter einem Enterprise Service Bus (ESB) versteht man ein Softwareprodukt zur Unterst¨ utzung der Integration verteilter Dienste in der heterogenen Anwendungslandschaft eines Unternehmens(...) Der ESB erlaubt, einmal erstellte Funktionalit¨ aten von Diensten f¨ ur andere Aufgaben 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 f¨ ur die reibungsfreie Kommunikation zwischen den Diensten, idealerweise sollten hierf¨ ur keine ¨ Anderungen an den Diensten der verschiedenen Anwendungen selbst n¨ otig sein” [Scm10]

Zu den wesentlichsten Aufgaben eines ESB geh¨ oren das (intelligente) Routing von Nachrichten unter Verwendung eines generischen Kommunikationsbusses ¨ uber

alle Anwendungen- und Herstellergrenzen hinweg, die Transformation von Nachrichten in unterschiedlichen Formate, sowie das Bereitstellen von verschiedenen Nachrichtenprotokollen und Routing-Mechanismen [Scm10]. Zudem soll ein ESB auf die Verteilung und die Skalierbarkeit ausgelegt sein, um sich einer st¨ andig wachsenden Anzahl von IT-Systemen und Anwendungen anpassen zu k¨ onnen [BHR07].

2.2.2 ESB Architekturen

Bei einem ESB k¨ onnen 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

⁶ Ancud IT-Beratung GmbH: http://www.ancud.de/

7

Referenz-Spezifikation angenommen. Zu dieser Gruppe geh¨ oren u.a. Produkte wie Sun Open ESB ⁷ , Apache ServiceMix, Petals Service Platform. ˆ Propriet¨ are Architektur : Wie der Begriff Propriet¨ ar schon hindeutet, besitzt jedes ESB-Produkt seine eigene Architektur. Zu dieser Kategorie geh¨ oren 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) f¨ ur ein Konzept zur Umsetzung einer Serviceorientierten Architektur entwickelt wurde. Das JCP JSR 208 ist Referenz f¨ ur JBI 1.0 und JSR 312 f¨ ur JBI 2.0 [Wik10b]. Diese Spezifikation definiert einen Standard f¨ ur 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 Br¨ ucke zwischen den anderen JBI Komponenten, den Binding-Components (BC) und den Service-Engines (SE). Der NMR ist zust¨ andig f¨ ur das Vermitteln (engl. Routing) der zu bearbeitenden Nachrichten zur Zielkomponente.

ˆ (eine oder mehrere) Binding-Components (BC): Diese dienen als Adapter, damit die Inkonsistenz zwischen den Partnern (In-und Out ESB) auf Kommunikationsebene beseitigt wird und streben nach einer einheitlichen Nachrichten-Schnittstelle f¨ ur 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): F¨ ur 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 k¨ ummert sich dieser um die Life-Cycle-Management der Komponenten (Start/Stop). Außerdem erm¨ oglicht dieser das Deployment von Componenten-Artifacts in vorhandenen SE und BC. Ein Beispiel hierf¨ ur ist die Installation neuer XSLT ⁸ Style Sheets in einer XSLT-Service Engine [WQH ⁺ 08].

⁷ derzeit auch Glassfish ESB genannt

⁸ Extensible Stylesheet Language Transformation

8

ˆ External JMX-based Admin Tools: Ein Remote JMX-based Client ist f¨ ur die Kommunikation mit dem Management Modul zust¨ andig, der somit einen ortsunabh¨ angigen Zugriff auf dem MM erm¨ oglicht. Abbildung 2.2 gibt einen zusammenfassenden ¨ Uberblick ¨ uber alle Komponenten eines JBI Systems in einem Top-Level View.

2.2.2.2 Propriet¨ are 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 erf¨ ullt. Es sind sowohl Engines zur Nachrichten-Transformation als auch Adapter zur Unterst¨ utzung unterschiedlicher Transportprotokolle vorhanden.

2.3 Darbietung von bekannten OpenSource ESB Produkten

Die Auswahl an verf¨ ugbaren OpenSource Enterprise Service Bus Systemen ist sehr groß, weshalb sich die Darbietung auf die folgenden drei bekannten ESB Produkte beschr¨ ankt: ˆ JBoss ESB ˆ Mule ESB

9

ˆ 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 [R¨ uc08]. JBoss ESB unterst¨ utzt zahlreiche Transportprotokolle wie HTTP, JMS, Socket... Ab dem Release 4.2 ist eine Distribution von JBoss ESB-Instanzen ¨ uber mehrere (physikalische oder virtuelle) Knoten m¨ oglich (Clustering-Aspekt von ESB). Die Architektur vom JBoss ESB wird durch die Abbildung 2.3 verdeutlicht.

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 ¨ uber Mule ESB.

10

Bei stetig wachsender Anzahl an Services und damit verbundener Auslastungen verh¨ alt sich Mule ESB flexibel und stabil. Tats¨ achlich wird dieser ESB nach dem Modell SEDA (staged event-driven Architecture) aufgebaut [BHR07]. Diese Architektur erm¨ oglicht es, eine große Anzahl an gleichzeitigen Verbindungen zu bew¨ altigen, indem der ESB in einzelnen Teilen (sog. Stages) aufgeteilt wird. Diese Stages werden durch Message-Queues miteinander verbunden [BHR07]. Somit ist eine hohe Entkopplung und effiziente Skalierbarkeit der Mule-ESB-Komponenten gew¨ ahrleistet. Mule ESB unterst¨ utzt viele Protokolle und kann in verschiedenen Szenarien ein-

gesetzt werden. Außerdem stehen zahlreiche Adapter f¨ ur Standard-Softwares zur Verf¨ ugung, 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 unterst¨ utzten 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 aufgekauft). 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 NetBeans IDE gebunden. Somit ist eine ausf¨ uhrliche und umfangreiche Plattform f¨ ur die Entwicklung SOA-f¨ ahiger Anwendungen bereitgestellt.

11

Nachfolgend erfolgt eine Aufz¨ ahlung der Komponenten, die Open ESB verwenden kann:

1. Binding Components: U.a. werden folgende Binding Components unterst¨ utzt: ˆ e-Mail BC: Anbindung f¨ ur das Senden und das Empfangen von E-mails ˆ File BC: Anbindung an das Dateisystem

ˆ HTTP BC: JBI Anbindung f¨ ur das Senden und das Empfangen von Nachrichten ¨ uber HTTP Protokolle

ˆ Database BC: Anbindung f¨ ur das Lesen (bzw. das Schreiben) von Nachrichten aus (bzw. in) einer Datenbank anhand JDBC ˆ SAP BC: Anbindung f¨ ur SAP

2. Service Engine: U.a. werden folgende Service Engines unterst¨ utzt: ˆ BPEL SE: WS-BPEL 2.0 f¨ ahige Engine f¨ ur Business Process Orchestration

ˆ Scripting SE: erlaubt das Scripting und Deployment in ESB ˆ Notfication SE: Unterst¨ utzung von WS-Notification ˆ XSLT SE: XSLT Transformation Engine

12