Seminararbeit. Enterprise Service Bus Die Basis von SOA. Wirtschaftsinformatik Hochschule München

Transkript

1 Seminararbeit Enterprise Service Bus Die Basis von SOA Wirtschaftsinformatik Hochschule München vorgelegt von: Julian Harrer vorgelegt am: Dozent: Dipl. Inf. Michael Theis Veranstaltung: Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen

2 Inhaltsverzeichnis: 1.Einleitung Herausforderung bei der Integration heterogener Systeme Verschiedene Integrationsarchitekturen Point-to-Point Hub-and-Spoke / Message Broker Enterprise Message Bus Anforderungen an eine Integrationslösung SOA Enterprise Service Bus Architekturmerkmale Nachrichtenorientierter Kern: Service Container und Endpoints Kanonisches Datenformat Integrationsdienste Verteilte ESB Knoten Konfiguration Aufgaben des Enterprise Service Bus Service Binding Service Routing Transfomation Fazit...19 i. Abbildungsverzeichnis:...20 ii. Quellenverzeichnis:...21 iii. Abkürzungesverzeichnis:...22

3 Enterprise Service Bus Die Basis von SOA Einleitung Die Integration heterogener Systeme in eine große, meist firmenübergreifende Systemlandschaft ist in heutigen Großunternehmen eine zeit- und kosten-kritische aber auch unvermeidbare Aufgabe geworden. Innerhalb dieser Unternehmen ist der Betrieb von weit über 100 unterschiedlichen Applikationen keine Seltenheit. Zwar gibt es ERP-Systeme wie SAP, die eine allumfassende Lösung für die meisten Problemstellungen eines Unternehmens versprechen, jedoch werden diese Produkte den spezifischen Anforderungen der einzelnen Unternehmen oftmals nicht gänzlich gerecht. Aus diesem Bedarf heraus entstehen riesige Systemlandschaften mit unterschiedlichen Anwendungen, die weder auf der selben Plattform betrieben werden, noch einheitliche Kommunikationswege in Anspruch nehmen. Die Vernetzung dieser unterschiedlichen Anwendungen ist die Aufgabe eines Integrationsarchitekten. Bei der Lösung dieser komplexen Aufgabe kommen Integrationsarchitekten in der Regel mit einer Vielzahl an verschiedenen Technologien, Protokollen und Nachrichtenformaten in Kontakt, wodurch sich die Einhaltung eines einheitlichen Integrationsansatzes sehr schwierig gestaltet. Der vielversprechenste Architekturansatz moderner Großunternehmen sind so genannte serviceorientierte Anwendungen (SOA). Bei diesem Ansatz wird die gesamte Geschäftslogik eines Unternehmens in feingranulare Dienste unterteilt, die dem gesamten Unternehmen aber auch Partnern außerhalb der Unternehmensgrenzen zur Verfügung gestellt und zu größeren Geschäftsprozessen aggregiert werden können. Hierbei steht die lose Kopplung und Wiederverwendbarkeit der einzelnen Dienste im Vordergrund. Solch eine SOA wird in der Praxis mit Hilfe von standardisierten Technologien wie Beispielsweise SOAP über HTTP für den Nachrichtenaustausch oder WSDL als Interfacetechnologie betrieben. Ein zentraler Bestandteil einer solchen serviceorientierten Anwendung ist für gewöhnlich der Enterprise Service Bus kurz ESB, der als eine Art Vermittler zwischen Service-Konsumenten und Service-Anbietern agiert und Aufgaben wie die Transformation von Nachrichten, Servicerouting und Servicebinding übernimmt. Der ESB vereint bewährte Pattern der Systemintegration mit standardisierten Technologien und bildet somit einen stabilen Kern innerhalb einer serviceorientierten Architektur. Der ESB ermöglicht den integrierten Anwendungen eine ereignisgesteuerte und vor allem sichere Kommunikation über verschiedene Protokolle und Interfacetechnologien. Diese Arbeit verdeutlicht die Aufgaben eines Enterprise Service Bus innerhalb einer serviceorientierten Architektur. Obwohl es keine einheitliche Übereinstimmung darüber gibt, was für Funktionen ein Produkt besitzen muss um sich als ein ESB bezeichnen zu können werden in dieser Arbeit allgemein annerkannte Konzepte erläutert, die von jeder ESB-Implementierung unterstützt werden sollte. Manche der Aufgaben des ESB werden mit Hilfe von kurzen Beispielen verdeutlicht.

4 Enterprise Service Bus Die Basis von SOA Herausforderung bei der Integration heterogener Systeme Die Tätigkeit unterschiedliche Applikationen miteinander zu verbinden nennt sich in der Informationstechnik (IT) Systemintegration. Es ist die Aufgabe der Systemintegration den Datenaustausch heterogener Systeme zu gewährleisten um die Dienste einzelner Unternehmensanwendungen dem gesamten Unternehmen oder sogar Partnern ausserhalb des Unternehmens bereitzustellen. Die Schwierigkeit bei der Verbindung solcher Unternehmensanwendungen liegt unter anderem in der Verschiedenartigkeit der einzelnen Applikationen. So muss es beispielsweise dem Abrechnungssystem innerhalb eines Unternehmens ermöglicht werden Daten aus einem veralteten Kundenverwaltungssystem abzurufen, obwohl dieses möglicherweise an einem anderen Ort, auf einem anderen Betriebssystem betrieben wird und ursprünglich vielleicht überhaupt nicht für den Datenaustausch mit anderen Systemen konzipiert wurde. Des Weiteren werden Anwendungen mit Hilfe verschiedener Anwendungsplattformen wie der Java Enterprise Edition (JEE) oder mit Hilfe der.net Plattform implementiert und kommunizieren über unterschiedliche Protokolle und Nachrichtenformate, was die Kommunikation zwischen den Applikationen erheblich erschwert. Unternehmensanwendungen sind zudem häufig auf verschiedene Standorte verteilt und müssen über weite geographische Distanzen und Firewallgrenzen hinweg miteinander kommunizieren. Die Dienste innerhalb einer serviceorientierten Architektur sind meist Teil von erfolgskritischen Geschäftsprozessen, weshalb Unternehmen großen Wert auf die Zuverlässigkeit bei der Kommunikation zwischen den einzelnen Anwendungen legen. Daher sollten bei der Integration der verschiedenen Anwendung Punkte wie eine sichere Nachrichtenübermittlung und Fehlerbehandlungen beachtet werden. Außerdem sollte ein Austausch einzelner Dienste oder die Anpassung bestimmter Geschäftsprozesse möglichst schnell umgesetzt werden können um flexibel auf Unternehmensentscheidungen reagieren zu können. 1.2 Verschiedene Integrationsarchitekturen Um den komplexen Aufgaben der Systemintegration gerecht zu werden entwickelten sich in der Vergangenheit eine Vielzahl an Lösungsansätzen für die Umsetzung von verteilten Anwendungen. Keiner der Ansätze, die in den folgenden Abschnitten dargestellt werden, bewährten sich jedoch in der Praxis als Universallösung für jede Problemstellung Point-to-Point Der einfachste und zugleich intuitivste Lösungsansatz ist der Point-to-Point Ansatz. Bei diesem Integrationsansatz werden alle Systeme, die miteinander kommunizieren wollen mit einem individuellen Kommunikationskanal verbunden. Bei einer geringen Anzahl an Systemen innerhalb eines Integrationsprojekts ist dieser Ansatz durchaus eine akzeptable Wahl. Wächst jedoch die Anzahl der Systeme innerhalb der Systemlandschaft wird das Gesamtsystem durch die steigende Zahl an Kommunikationskanälen sehr unübersichtlich und erschwert die Wartung der einzelnen Systeme.

5 Enterprise Service Bus Die Basis von SOA Abbildung 1 Point-to-Point Integration Die folgende Gleichung verdeutlicht das Wachstum der Kommunikationskanäle (Nc) bei steigender Anzahl an Systemen (n). Quelle[1] Nc = n² n Bei dieser Formel wird angenommen, das jedes System mit jedem anderen System innerhalb des Unternehmens kommunizieren muss. Dies ist zwar in der Praxis eher selten der Fall, aber auch wenn nur die Hälfte der Anwendungen des Gesamtsystems untereinander Daten austauschen müssen, gestaltet sich die Verwaltung und Wartung des gesamten Integrationsprojekts sehr problematisch. Weitere Nachteile dieses Architekturansatzes ist einerseits, die feste Verdrahtung der einzelnen Systeme über die Kommunikationskanäle und zum anderen die Auslagerung der Integrationslogik in die Anwendungen. Über die festen Abhängigkeiten der Anwendungen wird die Einführung oder der Austausch einer neuen Anwendung erschwert. Auch die Wiederverwendbarkeit eines Dienstes kann nur über neue Kommunikationskanäle geregelt werden. Häufig wachsen Integrationsprojekte im laufe der Zeit, wodurch verschiedene Entwickler mit der Implementierung von neuen Kommunikationskanälen beauftragt werden. Daraus resultieren oftmals riesige Integrationsbaustellen mit uneinheitlichen Implementierungsansätzen und unübersichtlicher Dokumentation. Eine Integrationslösung sollte daher die Logik die dafür verwendet wird Daten von einem Dienst zu einem anderen zu transportieren aus der Anwendungsschicht entfernen und in eine eigene Integrationsschicht auslagern um die einzelnen Dienste voneinander kapseln zu können.

6 Enterprise Service Bus Die Basis von SOA Hub-and-Spoke / Message Broker Ein weiter Lösungsansatz ist der Hub-and-Spoke Ansatz der auch als Message Broker bezeichnet wird. Der Message Broker übernimmt bei der Kommunikation zwischen den Anwendungen die Rolle eines zentralisierten Nachrichtenvermittlers zwischen den einzelnen Systemen. Bei diesem Ansatz ist also die Integrationslogik anders als beim Point-to-Point Ansatz aus den Anwendungen ausgelagert. Ein System das seine eigenen Dienste bereitstellen will oder die Dienste anderer Anwendungen nutzen will muss sich lediglich über einen einzigen Kommunikationskanal am Message Broker anmelden und wird somit Teil des Gesamtsystems. Ein weiterer Vorteil dieses Ansatzes gegenüber dem Point-to-Point Ansatz ist das intelligente Routing, welches von dem zentralen Hub aus verwaltet werden kann. Über das Routing kann der Hub entscheiden an welchen Dienst eingehende Nachrichten versendet werden, die Anwendungen selbst müssen sich somit nicht mehr um die Adressierung ihrer Kommunikationspartner kümmern. Abbildung 2 Hub-and-Spoke Integration Obwohl der Message-Broker einige der Probleme des Point-to-Point Ansatzes löst bewährte sich auch dieser Ansatz in der Praxis nicht für alle Problemstellungen. Der Message Broker stellt durch seine zentralisierte Lage innerhalb des Unternehmens eine Art Single Point Of Failure dar. Der Ausfall des Message Brokers verhindert somit die Kommunikation aller Unternehmensanwendungen. Zwar wurden für diesen Fall Lösungen wie beispielsweise Clusterverfahren entwickelt, über die mehrere Instanzen eines Brokers parallel gestartet werden können, jedoch entspricht das zentralisierte Verhalten des Message Brokers nicht der verteilten Natur heutiger Unternehmensanwendungen. Weiterhin gibt es hauptsächlich proprietäre Message Broker die keine standardisierten Kommunikationswege besitzen und somit nicht zueinander kompatibel sind.

7 Enterprise Service Bus Die Basis von SOA Enterprise Message Bus Der Enterprise Message Bus bezeichnet einen Integrationsansatz, der eine nachrichtenorientierte Kommunikation zwischen verschiedenen Anwendungen über einen plattformneutralen Nachrichtenbus ermöglicht. Anwendungen senden lediglich ihre formatierten Nachrichten an den Message Bus und dieser leitet sie beispielsweise über einen Publish-and-Subscribe Mechanismus an verschiedene Konsumenten weiter. Auch hierbei übernimmt die Integrationslösung die Aufgabe des Routing. Der Vorteil des Message Bus gegenüber dem Message Broker ist die lose Kopplung der einzelnen Systeme. Ein System sendet lediglich eine Nachricht an den Bus ohne zu wissen welche Empfänger es für diese Nachricht gibt. Abbildung 3 Message Bus Integration Der Message Bus Ansatz besitzt viele Gemeinsamkeiten mit einem Enterprise Service Bus, der ebenfalls nachrichtenorientiert arbeitet und plattform- sowie sprachunabhängig ist. Ein großer Nachteil des einfachen Message Bus ist jedoch, dass es keine Schnittstellenbeschreibungen der einzelnen Dienste gibt, die Anwendungen müssen schon im vornherein wissen welches Format die Nachrichten besitzen müssen um von einem Konsumenten interpretiert werden zu können. (Mehr unter Quelle[2]) 1.3 Anforderungen an eine Integrationslösung Eine Integrationslösung sollte in der Lage sein die Dienste verschiedener Anwendungen in einer lose gekoppelten Weise miteinander zu verbinden. Lose gekoppelt bedeutet in diesem Zusammenhang das Applikationen, welche andere Dienste inanspruch nehmen, nicht wissen mit welchen konkreten Diensten sie kommunizieren. Dadurch können Dienste relativ einfach in das Gesamtsystem aufgenommen werden oder bei Bedarf mit einem anderen Dienst ersetzt werden. Einem Konsumenten eines Dienstes sollte lediglich die abstrakte Schnittstelle des Serviceanbieters bekannt sein ohne die konkrete Lage oder Implementierung des Service zu kennen. Des Weiteren sollte die Wiederverwendbarkeit der einzelnen Dienste über die Integrationslösung erleichtert werden um nicht wie bei einer Point-to-Point Lösung unzählige individuelle Kommunikationskanäle für jeden Konsumenten implementieren zu müssen. Da viele Anwendungen wie beispielsweise Third-Party-Applikationen oder Anwendungen von Partnerunternehmen bei ihrer Integration in eine SOA meist nicht anpassbar sind, ist es die Aufgabe einer Integrationslösung die Kommunikation über die Protokolle und Nachrichtenformate der zu integrierenden Anwendung zu gewährleisten. Ein Serviceprovider

8 Enterprise Service Bus Die Basis von SOA muss sich somit beispielsweise nicht mehr darum kümmern die Nachrichtenformate oder Protokolle anderer Konsumenten zu unterstützen, dies übernimmt die Integrationslösung. Die Nachteile des Hub-And-Spoke Ansatz haben gezeigt, das eine einzige zentralisierte Insel der Integration fehleranfällig ist und den Anforderungen großer Unternehmen nicht immer gerecht wird. Da die Applikationen verschiedener Abteilungen eines großen Unternehmens meist über verschiedene Länder und Kontinente verteilt sind, liegt es nahe eine Integrationslösung einzusetzen, die es ermöglicht mehrere Knotenpunkte auf verschiedenen Standorten zu verteilen. Dadurch soll es den einzelnen Abteilungen ermöglicht werden die Dienste und Prozesse, für die sie verantwortlich sind selber zu verwalten. Des weiteren sollte eine Integrationslösung die Integration der Anwendungen über eine Konfiguration wie beispielsweise einer XML-Datei abwickeln. Dadurch können Abläufe und Integrationsdetails konfiguriert werden anstatt sie mit Hilfe von kompilierten Code zu implementieren. Eine Integrationslösung sollte alle genannten Anforderungen erfüllen um eine erfolgreiche Umsetzung einer SOA zu gewährleisten.

9 Enterprise Service Bus Die Basis von SOA SOA Das Konzept der serviceorientierten Architekturen unterstützt Unternehmen bei der Entwicklung und dem Betrieb einer einheitlichen und verteilten IT-Infrastruktur. Dabei werden verschiedene Aufgaben in feingranulare Diensten geteilt und über das Netzwerk bereitgestellt. Diese Dienste können dann in Form einer Prozessmodellierung zu größeren Geschäftsprozessen aggregiert und innerhalb des Unternehmens oder über dessen Grenzen hinaus bereitgestellt werden. Da ein Unternehmen selten in der Lage ist alle Anwendungen und deren Dienste innerhalb ihrer IT-Infrastruktur selber zu implementieren sind viele dieser Dienste in Third-Party Applikationen ausgelagert, welche meist nicht angepasst oder verändert werden können aber dennoch in die Geschäftsprozesse der Unternehmen integriert werden müssen. Die folgende Grafik zeigt das klassische SOA-Dreieck, welches verdeutlicht wie ein Serviceaufruf innerhalb einer serviceorientierten Architektur abläuft. Abbildung 4 SOA Dreieck In der Grafik werden drei Komponenten dargestellt, welche im Ablauf eines Serviceaufrufes beteiligt sind. Ein Service Provider bietet eigene Dienste für mehrere Service Consumer an. Um diese Dienste bereitstellen zu können publiziert der Service Provider zunächst bestimmte Informationen seiner Dienste wie beispielsweise eine Schnittstellenbeschreibung über eine Service Registry. Ein Service Consumer verwendet diese Service Registry um bestimmte Dienste über die bereitgestellten Informationen zu finden. Nach dem Auffinden eines passenden Dienstes kann der Service Consumer eine Anfrage an den Provider senden und erhält darauf ggf. eine Antwort. Ein klassischer Serviceaufruf innerhalb einer SOA läuft in der Regel synchron ab.

10 Enterprise Service Bus Die Basis von SOA Die verbreitetste Technologie, die für die Realisierung der Dienste einer serviceorientierten Architekturen eingesetzt wird sind Webservices. Webservices verwenden standardisierte Schnittstellen in Form von WSDL-Dokumenten und kommunizieren über SOAP-Messages. Die Schnittstellenbeschreibung besteht dabei aus einem abstrakten und einem konkreten Teil. Der abstrakte Teil enthält Informationen über die Funktionalität eines Services wie beispielsweise Input- und Requestnachrichtentypen. Der konkrete Teil des WSDL-Dokuments enthält dagegen Informationen über den Zugriff auf den Service wie das verwendete Protokoll oder die Adresse des Service. Eine SOAP-Message besteht aus bestimmten Metadaten und einem Body mit der eigentlichen Nachricht in XML-Format. Mit Hilfe dieser plattformunabhängigen Standards ist es möglich Anwendungen verschiedener Programmiersprachen miteinander zu verbinden. Im laufe der Zeit entwickelten sich eine Vielzahl von weiteren Webservice-Standards, welche für diese Arbeit jedoch nicht relevant sind und daher nicht weiter beschrieben werden. Das folgende Kapitel verdeutlicht welche unterstützende Rolle der Enterprise Service Bus innerhalb einer servicorientierten Architektur annim

11 Enterprise Service Bus Die Basis von SOA Enterprise Service Bus Das Konzept des Enterprise Service Bus entstand aus dem Bedarf der Industrie nach einem neuen Integrationsansatz, der die Mängel vorhergehender Ansätze beseitigt und neue Wege in Richtung lose gekoppelte Systeme bereiten sollte. Der Enterprise Service Bus ist keine wirkliche Technologieinnovation, er ist vielmehr eine neue Herangehensweise an bekannte Integrationsprobleme über standardisierten Technologien. Er vereint bewährte Integrationspattern mit etablierten Standards und entfernt sich somit von proprietären Lösungen der Message-Broker. Die meisten der Integrationspattern, die innerhalb des ESB bereitgestellt werden stammen aus dem Buch Enterprise Integration Pattern (Quelle[3]). Der Enterprise Service Bus hat sich bereits in vielen internationalen Unternehmen bewährt und ist Teil der meisten SOA-Lösungen wie der Oracle SOA Suite oder der IBM Websphere Produktlinie. Innerhalb von serviceorientierten Anwendungen dient der Enterprise Servicebus als eine Art Nachrichtenvermittler und übernimmt dabei viele Integrationsaufgaben wie das Service Binding oder Service Routing sowie die Transformation von Nachrichten. Der ESB ermöglicht durch seine nachrichtenorientierte Natur die Implementierung von ereignisgesteuerten serviceorientierten Architekturen. Über ereignisgesteuerte serviceorientierte Architekturen können Ereignisse wie beispielsweise die Änderungen von Kundendaten per Echtzeit an alle interessierten Systeme übermittelt werden. Da der gesamte Nachrichtenverkehr über den ESB abgewickelt wird, ist er ebenfalls ideal für das Logging und Monitoring des gesamten Nachrichtenverkehrs. Der folgenden Abschnitte erläutern verschiedene Architekturmerkmale des Enterprise Service Bus. 3.1 Architekturmerkmale Dieses Kapitel beschreibt gängige Architekturmerkmale die den Enterprise Service Bus von anderen Integrationslösungen abgrenzt. Diese Merkmale verdeutlichen die Funktionsweise eines ESB s und erläutern die wichtigsten Komponenten innerhalb eines ESB s Nachrichtenorientierter Kern: Der Enterprise Service Bus besteht im inneren aus einem nachrichtenorientierten Kern welcher auch als Message Oriented Middleware (MOM) bezeichnet wird. Das Konzept der MOM ist nicht ESB-spezifisch, sondern beschreibt im Allgemeinen einen Nachrichtenbus, der eine asynchrone Nachrichtenkommunikation ermöglicht. Der ESB-Kern sorgt für eine garantierte Nachrichtenübertragung und stellt innerhalb einer SOA Mechanismen bereit wie eine Point-to-Point Übertragung oder eine Art Broadcasting über das Publish-and-Subscribe Modell die im folgenden kurz beschrieben werden. Point-to-Point Nachrichtenübertragung: Bei der Point-to-Point Nachrichtenübertragung werden die zu verarbeitenden Nachrichten von einem Messageproducer in eine Message Queue übergeben, welche die Nachrichten zunächst speichert und dann an genau einen Messageconsumer übermittelt. Dabei muss es sich nicht unbedingt um genau einen Konsumenten handeln, es ist durchaus möglich, das sich mehrere

12 Enterprise Service Bus Die Basis von SOA konkurrierende Konsumenten an einer Queue anmelden. Wichtig bei der Point-to-Point Nachrichtenübermittlung ist nur, dass eine Nachricht immer nur einmal von einem Messageconsumer verarbeitet wird. Es gibt viele verschiedene Variationen oder Pattern beim Einsatz einer Point-to-Point Nachrichtenübertragung wie beispielsweise der Concurrent Consumer Ansatz bei dem sich wie oben beschrieben mehrere Konsumenten an einer Messagequeue auf Nachrichten warten. (Mehr unter Quelle[3]) Abbildung 5 Point-to-Point Messaging Publish-and-Subscribe Bei der Nachrichtenübertragung über das Publish-and-Subscribe Modell können sich verschiedene Messageconsumer an einem Topic registrieren, welches Nachrichten von einem oder mehreren Messageproducern erhält. Der Unterschied zur Point-to-Point Nachrichtenübertragung ist, dass beim Publish-and-Subscribe Modell jeder der Konsumenten eine Instanz der publizierten Nachricht erhält. Es ist außerdem möglich ganze Topichierachien aufzubauen damit sich Konsumenten für bestimmte Bereiche innerhalb dieser Hierachie als Subscriber anmelden können. Abbildung 6 Publish-and-Subscribe Messaging

13 Enterprise Service Bus Die Basis von SOA Ein Providerdienst hat entweder die Möglichkeit, beispielsweise über JMS, direkt mit dem Messaging System zu kommunizieren oder er verwendet eine andere Serviceschnittstelle wie beispielsweise eine Webserviceschnittstelle, wobei sich der ESB um das Publizieren der Nachricht kümmert. Die Sicherheit der Nachrichtenübermittlung über eine Message Queue oder ein Topic wird über den Quality of Service kurz QoS festgelegt. Der QoS beschreibt also die Qualitätsanforderungen an die Nachrichtenübertragung eines Topics oder einer Queue. Beispielsweise kann ein Topic mit dem QoS exactly once konfiguriert werden, bei dem eine Nachrichtenübermittlung sogar bei einem Systemausfall zugesichert wird. Hierbei werden die Nachrichten vor dem Versand zunächst persistiert und dann weitergeleitet. Ein weiterer Vorteil des nachrichtenorientierten Ansatzes des ESB ist, dass ein Message Provider nicht wissen muss welche Consumer an seiner Nachricht interessiert ist und die Consumer auf der anderen Seite wissen ebenfalls nicht wer die empfangene Nachricht produziert hat. Die Dienste sind somit lose gekoppelt. Es können jederzeit Konsumenten hinzugefügt oder entfernt werden ohne Änderungen an den anderen beteiligten Komponenten tätigen zu müssen. Diese Messaging Funktionalität ermöglicht eine asynchrone Reaktion mehrerer Unternehmensanwendungen auf beliebige Ereignisse innerhalb eines Unternehmens. Der nachrichtenorientierte Kern eines ESB dient also als Grundlage einer ereignisgesteuerten SOA. Für die asynchrone und ereignisgesteuerte Benachrichtigung auf Webservice Ebene wird in der Praxis beispielsweise der WS-Notification Standard verwendet. Es ist zudem anzumerken das der ESB neben der asynchronen Nachrichtenübermittlung ebenfalls die synchrone Kommunikation unterstützt Service Container und Endpoints Der Enterprise Service Bus kann über die unterschiedlichsten Protokolle oder Technologien mit anderen Diensten innerhalb einer SOA kommunizieren. Der Apache Servicemix ESB unterstützt beispielsweise die Kommunikation über FTP, HTTP, XMPP, JMS und vielen weiteren Anbindungsmöglichkeiten. Externe Anwendungen kommunizieren mit dem ESB über bestimmte Endpoints, die vom ESB selbst bereitgestellt werden. Jeder Endpoint ist an ein bestimmtes Protokoll oder eine bestimmte Technologie gebunden. Ein Endpoint ist also eine Art Andockstelle für externe Anwendungen an den ESB. Da sich der Ablauf der Kommunikation über die verschiedenen Protokolle unterscheidet, stellt der ESB für jede Art von Endpoint einen Service Container bereit. Der Service Container kann als eine Art Systemprozess angesehen werden, der für das Betreiben der einzelnen Servicekomponenten verantwortlich ist. Er kümmert sich beispielsweise um den Lebenszyklus der einzelnen Komponenten und das Empfangen und Weiterleiten von Nachrichten über die Endpoints. (Mehr unter Quelle[1]) Kanonisches Datenformat Die verschiedenartigen Anwendungen innerhalb eines Unternehmen besitzen meist unterschiedliche Nachrichtenformate wie XML, CSV oder EDI. Das verbreitetste Format moderner SOA-Anwendungen ist jedoch XML. Das XML-Format ist ideal für den Datenaustausch heterogener Systeme, denn es ist einfach lesbar und kann über verschiedene Parser interpretiert und everrweitert werden. Des weiteren gibt es unzählige Bibliotheken auf

14 Enterprise Service Bus Die Basis von SOA den verschiedenen Plattformen für die Erstellung, Bearbeitung und Validierung von XML- Dateien. Dennoch ist der Einsatz von XML durch den Overhead bei dessen Verarbeitung nicht für jede Art von Kommunikation geeignet. Müssen viele Daten über einen kurzen Zeitraum verarbeitet werden wie es bei ETL-Prozessen der Fall ist, sollten die Daten nicht erst geparst werden müssen um sie verarbeiten zu können. Auch wenn alle Anwendungen innerhalb eines Gesamtsystems über das XML-Format kommunizieren bedeutet dies nicht, dass jede Anwendung das gleiche Nachrichtenschema für eine gleichartige Nachricht verwendet. In der Industrie haben sich verschiedene Standards für die Darstellung von Unternehmensdaten wie das XCBL oder cbxml Format entwickelt. In der Regel halten sich Unternehmen innerhalb der eigenen Systeme an eines dieser Standardformate. Es ist jedoch beispielsweise möglich das ein Unternehmen intern das cbxml Format verwendet und mit einem Partnerunternehmen kommunizieren muss, welches das XCBL Format für den Nachrichtenaustausch von Unternehmensdaten verwendet. Für einen solchen Fall verwendet der ESB Transformatoren, die es ermöglichen ein fremdes Nachrichtenformat in das Format des ESB zu verwandeln. Innerhalb des Enterprise Servicebus läuft die Kommunikation jedoch über ein festgelegtes kanonisches Nachrichtenformat. Welches Format innerhalb des ESB verwendet wird entscheidet ein Unternehmen selber. Viele ESB Implementierungen wie Apache Servicemix erlauben nur XML als internes Austauschformat. Mehr über die Verwendung und den Einsatz von Transformatoren wird in Punkt erläutert Integrationsdienste Neben der Bereitstellung von externen Services über das Servicebinding (Siehe Punkt 3.2.1) bieten ESB Implementierung interne Dienste wie Transformations- und Routing Dienste an. Diese Integrationsdienste werden innerhalb des ESB betrieben und dienen innerhalb der Prozesslogik einer SOA als Bindeglieder zwischen den einzelnen Services. In der Praxis stellen ESB Implementierungen weiter Integrationsdienste für das Validieren von Nachrichten oder Loggingdienste bereit. Über Dienste wie diese entstanden neben den üblichen Integrationspattern weitere ESB-Pattern wie das VETO Pattern oder dessen Erweiterung das VETRO Pattern, die im folgenden kurz erläutert werden. VETO/VETRO Pattern Das VETO Pattern steht für Validate, Enrich, Transform, Operate und ist eines von vielen ESB Patterns. Dieses Pattern soll die Konsistenz der Nachrichtenübertragung über bestimmte Integrationsdienste gewährleisten. Über die Validierung der einkommenden Nachrichten soll sichergestellt werden, dass ausschließlich korrekte Nachrichten weiterverarbeitet werden. Der Enrich Schritt dient der Bereicherung der Nachricht um bestimmte Informationen, die dem Empfänger hilfreich sein könnten. Die Transformation wird dazu verwendet um das Nachrichtenschema ggf. in das erwartete Schema des Empfängers umzuwandeln. Über den Operate Schritt wird letztendlich der eigentliche Empfänger Service aufgerufen. Das VETRO Pattern ist eine Erweiterung des VETO Pattern und beinhaltet einen Routing Schritt um die Nachricht an bestimmte Empfänger weiterzuleiten. Quelle[1]

15 Enterprise Service Bus Die Basis von SOA Verteilte ESB Knoten Im Gegensatz zu den zentralisierten Message Brokern kann die Integrationslogik auf einem ESB auf verschiedene Knotenpunkte verteilt werden. Dadurch wird es den einzelnen Abteilungen eines Unternehmens ermöglicht ihre Dienste und Prozesslogik auf einem eigenen ESB-Knoten zu deployen ohne von einer zentralisierten Integrationsplattform abhängig zu sein. Der nachrichtenorientierte Kern des ESB sorgt für einen gleitenden Übergang bei der Kommunikation zwischen den Einzelnen Knotenpunkten und sorgt für eine sichere Nachrichtenübertragung. Dienste anderer Knotenpunkte innerhalb des ESBs können also genauso wie lokale Dienste verwendet werden. Abbildung 7 Verteilte ESB-Knoten Konfiguration Die Integrationslogik wie das Service Binding, Service Routing und die Nachrichtentransformation werden bei der Verwendung eines ESBs üblicherweise nicht innerhalb des Programmcodes implementiert, sondern vielmehr über Konfigurationsdateien konfiguriert. Durch die Verwendung von Konfigurationsdateien wird einerseits das Deployment der Integrationslogik auf den ESB vereinfacht und zum anderen die Lesbarkeit verbessert. In der Praxis müssen lediglich eigene Integrationsdienste oder Servicecontainer mit Hilfe von Programmcode implementiert werden, die Verbindung der einzelnen Services regelt die Konfiguration innerhalb eines ESB-Knoten. Jeder ESB-Knoten innerhalb des Gesamtsystems erhält somit eine eigene Konfiguration und bestimmt dadurch seine interne Integrationslogik. Innerhalb einer SOA bietet diese Art von Konfiguration eine Möglichkeit die Integrationslogik schnell und flexibel ändern zu können, des weiteren unterstützen die meisten ESB-Implementierungen die Fähigkeit des Hot-Deployments um die Integrationslogik per Laufzeit anpassen zu können. 3.2 Aufgaben des Enterprise Service Bus Ein Dienstaufruf innerhalb einer SOA wird traditionell über die Schritte Find, Bind und Invoke gehandhabt. Will ein Konsument einen Dienst aufrufen sendet er zunächst eine Suchanfrage an eine Service-Registry. Die Service-Registry stellt Informationen wie beispielsweise den Standort aller Dienste bereit und bietet Funktionalitäten für die Suche dieser Dienste an. Hat ein Konsument einen passenden Dienst gefunden geht er über in die Anbindung also das Binding des Dienstes, dies könnte beispielsweise das Öffnen einer Http- Verbindung zum Serviceprovider sein. Nach dem Binding folgt der eigentliche Serviceaufruf

16 Enterprise Service Bus Die Basis von SOA also der Invoke Schritt. Der Enterprise Service Bus bietet einer SOA erhebliche Unterstützung während dieser drei Schritte. Bei einem traditionellen Client-Server Modell müsste die gesamte Logik dieser drei Schritte innerhalb der Anwendungslogik der einzelnen Clients enthalten sein. Dies bedeutet das sich die gesamte Routing- und Prozesslogik innerhalb der Clients befindet. Der ESB versucht die Mängel des traditionellen Client-Server Modells über die Verwendung eines ereignisgesteuerten Nachrichtenbus zu umgehen. Ein Service innerhalb des ESB wird nicht mehr direkt von einem Konsumenten aufgerufen sondern ist eher Teil eines größeren ereignisgesteuerten Prozessablaufs. Ein Konsument sendet bei diesem Konzept lediglich eine Requestmessage an den ESB, welcher daraufhin einen einzelnen Dienst aufruft oder einen gesamten Prozess durchläuft. Der ESB übernimmt somit eine sehr wichtige Rolle beim Routing und dem Aufruf der Dienste einer SOA. (Mehr unter Quelle[1]) Abbildung 8 zeigt eine Übersicht über die zentralen Aufgaben eines ESB's innerhalb einer SOA. In der Grafik sind verschiedene Serviceprovider zu sehen, die über unterschiedliche Protokolle an den Enterprise Servicebus angebunden sind. Auf der anderen Seite sind Konsumenten dargestellt, welche die Dienste der Provider über verschiedene abstrakte Schnittstellen des ESB nutzen. Dabei ist es durchaus möglich, dass eine Anwendung beide Rollen, die eines Anbieters und die eines Konsumenten gleichzeitig besitzt. Abbildung 8 ESB Übersicht In der Grafik ist ebenfalls zu erkennen das die Konsumenten nicht die selben Schnittstellen und in manchen Fällen nicht einmal das selbe Kommunikationsprotokoll der Anbieter verwenden. Es ist die Aufgabe des ESB's die abstrakten Schnittstellen mit den konkreten Schnittstellen der Provider zu verbinden. Hierbei helfen ihm verschiedene Integrationsdienste wie beispielsweise Dienste zur Transformation von Nachrichten oder Routing-Dienste. Der ESB unterstützt bei der Nachrichtenübermittlung bewährte Integrationspattern für das Routing

17 Enterprise Service Bus Die Basis von SOA und die Nachrichtentransformation. Über die Kombination von Integrationsdiensten und Pattern können komplexe Abläufe modelliert werden. Diese Abläufe können in den meisten ESB-Implementierungen innerhalb von Konfigurationsdateien oder per Programmcode modelliert werden. Die folgenden Abschnitte erläutern die wichtigsten Aufgaben des Enterprise Service Bus innerhalb von serviceorientierten Anwendungen Service Binding Eine der wichtigsten Aufgaben des Enterprise Service Bus ist das Service Binding. Über das Service Binding bindet der ESB die Dienste externer Anwendungen an seinen nachrichtenorientierten Kern und stellt diese somit anderen Anwendungen zur Verfügung. Die einzelnen Dienste können je nach Unterstützung der ESB-Implementierung über verschiedene Protokolle oder Interfacetechnologien an den ESB gebunden werden. Das Service Binding ermöglicht beispielsweise die Anbindung eines FTP-Dienstes an den ESB. Die Konsumenten, die diesen Dienst nutzen wollen, kommunizieren mit dem ESB z.b mit Hilfe von SOAP über HTTP und wissen nicht, dass sie indirekt Daten eines FTP-Dienst erhalten. Der ESB übernimmt in einem solchen Fall die Aufgabe einer Protokolltransformation und abstrahiert die Serviceschnittstelle des FTP-Dienstes. Der Enterprise Service Bus übernimmt somit die konkrete Anbindung der Services an das Gesamtsystem und schafft somit eine lose Kopplung zwischen den einzelnen Unternehmensanwendung innerhalb einer SOA. Das folgende Beispiel zeigt die Implementierung des vorherigen Szenarios mit Hilfe der ESB- Implementierung Apache Servicemix. Beispiel eines FTP-Pollerservice und Http-Providerservice in Servicemix: Abbildung 9 FTP-Pollerservice Beispiel

18 Enterprise Service Bus Die Basis von SOA Der folgende Codeabschnitt zeigt eine Implementierung des FTP-Pollers mit Servicemix. Der FTP-Poller sucht innerhalb eines FTP-Verzeichnis das mit Hilfe des Attributs uri definiert wird nach neuen Nachrichten und übergibt diese dann einem targetservice. Der Name des Poller-Service wird innerhalb des service Attributs festgehalten. Das endpoint Attribut bestimmt den Namen dieses Endpoints. Ein Service kann mehrere Endpoints besitzen. Der targetservice ist der Name des Services an den neue Nachrichten weitergeleitet werden, in diesem Fall der HttpProviderService. <ftp:poller service="my:ftppoller" endpoint="pollerendpoint" targetservice="my:myproviderservice " targetendpoint="myhttpprovider " uri="ftp://vertjava:test@localhost/smx/test" /> Quelle[4] Der Http-Provider erhält ebenfalls einen Servicenamen und einen Endpointnamen über die beiden Attribute service und endpoint. Über das Attribut locationuri wird die Adresse des Konsumenten angegeben der die eingehenden Nachricht verarbeiten soll. Der Http- Konsument könnte ein einfacher Http-Client oder ein Webservice sein. (Für eine echte SOAP/HTTP Kommunikation werden in Servixemix weitere Komponenten angeboten) < service="my:myproviderservice" endpoint="myhttpprovider" role="provider" locationuri=" Quelle[4] Service Routing Über das Service Routing werden die Kommunikationswege zwischen den einzelnen Anwendungen festgelegt. Das Routing ist also dafür verantwortlich den Datenverkehr von einem Serviceprovider zu einem oder mehreren Serviceconsumern zu regeln. Mit Hilfe des Routings können ganze Prozessabläufe modelliert und jederzeit angepasst werden. Beim Modellieren der Abläufe werden Integrationspattern wie z.b. das Content Based Routing verwendet, die es ermöglichen nach bestimmten Gesichtspunkten das Routingverhalten zu verändern. Ein Content Based Router wird beispielsweise dazu eingesetzt eine Nachricht je nach Inhalt an einen bestimmten Konsumenten weiterzuleiten. Ein weiteres Routing-Pattern ist der Message-Filter der nur bestimmte Nachrichten an einen Konsumenten sendet. Pattern wie diese sind allgemeine Integrationspattern, die es bereits vor der Zeit des ESB gab und dafür verwendet werden bestimmte Regeln im Routing-Verhalten eines Prozesses zu definieren. Es ist die Aufgabe des ESB solche Integrationspattern bereitzustellen um die Voraussetzung für eine einfache Prozessmodellierung zu schaffen. Verschiedene Dienste können somit einfach und schnell zu großen Geschäftsprozessen zusammengestellt werden. Das folgende Beispiel zeigt einen Content Based Router in Servicemix.

19 Enterprise Service Bus Die Basis von SOA Beispiel eines Content Based Router in Servicemix: Abbildung 10 Content Based Router Beispiel Der Content-Based-Router-Service my:cbr durchsucht empfangene Nachrichten mit Hilfe von X-Path nach einem message-type element. Falls dieses element die Bezeichnung a enthält wird die Nachricht an den Service my:aservice weitergeleitet. Falls der message-type nicht die Bezeichnung a enthält wird der Service my:defaultservice aufgerufen. <eip:content-based-router service="my:cbr" endpoint="cbrendpoint"> <eip:rules> <eip:routing-rule> <eip:predicate> <eip:xpath-predicate xpath="//message-type= a "/> </eip:predicate> <eip:target> <eip:exchange-target service="my:aservice" /> </eip:target> </eip:routing-rule> <eip:routing-rule> <eip:target> <eip:exchange-target service="my:defaultservice" /> </eip:target> </eip:routing-rule> </eip:rules> </eip:content-based-router> Quelle[4] Die Routinglogik ist ein zentraler Bestandteil einer serviceorientierten Architekturlösung. Hier findet die Modellierung der einzelnen Geschäftsprozesse statt. Der Enterprise Servicebus unterstützt die SOA hierbei indem er die Aufgabe des Routing selber übernimmt und somit aus der Anwendungslogik der Dienste kapselt. Des weiteren bietet er eine Vielzahl an Routing-Pattern an, welche die Implementierung einer ereignisgesteuerten SOA-Lösung ermöglicht.

20 Enterprise Service Bus Die Basis von SOA Transfomation Ein weiterer wichtiger Integrationsdienst neben dem Service Binding und dem Service Routing ist die Transformation von Nachrichten. Da sich das Nachrichtenformat unterschiedlicher Anwendungen einer serviceorientierten Architektur oftmals unterscheidet bietet der ESB interne Dienste an um das Format eingehender und ausgehender Nachrichten zu transformieren. Eingehende Nachrichten werden von Transformationsdiensten zunächst in das interne Nachrichtenformat des ESB s transformiert und weiterverarbeitet. Verlässt eine Nachricht den ESB wird sie wieder in das für die Anwendung verständliche Format transformiert. Für jede unterschiedliche Nachricht müssen also zwei Transformatoren implementiert werden, eine für die Transformation in das kanonische Format (siehe Punkt Kanonisches Datenformat) und eine Transformation vom kanonischem Datenformat in das anwendungsspeziefische Format. Transformationsdienste verwenden beispielsweise Technologien wie XSTL oder XQuery um ein Nachrichtenformat in das andere zu überführen. Abbildung 11 Transformation

21 Enterprise Service Bus Die Basis von SOA Fazit Der Enterprise Servicebus ist der bisher bewährteste Integrationsansatz der Industrie. Er unterstützt Integrationsarchitekten bei der Integration unterschiedlicher Systeme über die Verwendung etablierter Standards und vielseitiger Integrationsdiensten. Durch die Erweiterbarkeit des ESB über die Implementierung weiterer Service Container scheint der ESB-Ansatz auch für zukünftige Technologien gewappnet zu sein. Obwohl der ESB in der Regel einen leichtgewichtigen Kern hat, sollten Unternehmen zunächst untersuchen ob der Einsatz eines ESB für verschiedene Projekte angemessen ist, oder beispielsweise ein Point- To-Point Lösung ausreichend ist. Für serviceorientierte Lösungen bietet der ESB nicht nur die Möglichkeit der traditionellen Client-Server Kommunikation, sondern darüber hinaus auch die Möglichkeit der asynchronen Nachrichtenübertragung und schafft somit die Grundlage einer ereignisgesteuerten SOA. Dadurch verschafft der ESB den Integrationsarchitekten neue Optionen und Herangehensweisen an die verschiedenen Problemstellungen bei der Umsetzung von serviceorientierten Anwendungen. Durch die klare Trennung von Geschäftslogik und Integrationslogik durch den ESB verläuft die Entwicklung der Dienste und modellierung der einzelnen Geschäftsprozesse reibungslos. Mit Hilfe des Enterprise Service Bus kann bei der Entwicklung einer SOA an vielen Stellen Geld und Zeit gespart werden, auch wenn der Einsatz eines Enterprise Service Bus nicht gleichbedeutend mit dem Erfolg eines SOA-Projekts ist. Die Einführung eines ESB s in eine bestehende Unternehmensarchitektur gestaltet sich durch die vielseitigen Integrationsmöglichkeiten ebenfalls relativ einfach, da der ESB zunächst auf Projektebene eingeführt werden kann. Der ESB Ansatz ist ein sehr vielversprechender und nicht zuletz interessanter Ansatz der wie es scheint optimal für aktuelle und zukünftige SOA-Projekte geeignet ist.

22 Enterprise Service Bus Die Basis von SOA i. Abbildungsverzeichnis: Abbildung 1 Point-to-Point Integration 3 Abbildung 2 Hub-and-Spoke Integration 4 Abbildung 3 Message Bus Integration 5 Abbildung 4 SOA Dreieck 7 Abbildung 5 Point-to-Point Messaging 11 Abbildung 6 Publish-and-Subscribe Messaging 11 Abbildung 7 Verteilte ESB-Knoten 14 Abbildung 8 ESB Übersicht 15 Abbildung 9 FTP-Pollerservice Beispiel 16 Abbildung 10 Content Based Router Beispiel 18 Abbildung 11 Content Based Router Beispiel 19

23 Enterprise Service Bus Die Basis von SOA ii. Quellenverzeichnis: [1] : Enterprise Service Bus David A. Chappell [2] : Service Oriented Java Business Integration Binildas C.A. [3] : Enterprise Integration Patterns Hophe, Woolf [4] : Open Source ESBs In Action Tijs Redemakers, Jos Dirksen [5] : Servicemix Homepage

24 Enterprise Service Bus Die Basis von SOA iii. Abkürzungesverzeichnis: ESB FTP HTTP JBI JEE JMS SOA SOAP WSDL XML XMPP XSLT Enterprise Service Bus File Transfer Protocol Hyper Text Transfer Protocol Java Business Integration Java Enterprise Edition Java Messag Service Serviceoriented Architecture Simple Object Access Protocol Web Service Definition Language Extensible Markup Language Extensible Messaging and Presence Protocol Extensible Stylesheet Language Transformation

25 Enterprise Service Bus Die Basis von SOA Ehrenwörtliche Erklärung Hiermit erkläre ich, dass ich die nachfolgende Arbeit selbstständig verfasst, nur die angegebenen Quellen und Hilfsmittel verwendet habe und Zitate als solche gekennzeichnet wurden. Weiterhin wurde die Arbeit noch nicht zu anderen Prüfungszwecken beim Prüfungsamt eingereicht. Ort, Datum, Unterschrift