Bedeutung und Qualitätseigenschaften des Enterprise Service Bus im Kontext von serviceorientierten Architekturen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Aufbau
1.3 Einordnung
1.4 Fazit

2 Der ESB aus Sicht der Forschung
2.1 Herangehensweise
2.2 Definition des ESB in der Forschung
2.2.1 Definition nach Schulte (Gartner)
2.2.2 Definition nach Kischel (OBJEKTspektrum)
2.2.3 Definition nach Chappell
2.2.4 Definition nach Dostal/Jeckle/Melzer/Zengler
2.2.5 Definition nach Lorenzelli-Scholz (OBJEKTspektrum)
2.2.6 Definition nach Rieks (IM)
2.2.7 Definition nach Tieke (InformationWeek)
2.2.8 Definition nach Vollmer/Gilpin (Forrester)
2.3 Vergleich der Definitionen
2.4 Fazit

3 Der ESB aus Sicht der Softwareindustrie
3.1 Herangehensweise
3.2 JBI Spezifikation
3.3 ESB nach Progress Software (ehemals Sonic Software)
3.4 ESB nach Fiorano
3.5 ESB nach Cape Clear
3.6 ESB nach BEA
3.7 ESB nach Oracle
3.8 ESB nach MuleSource
3.9 ESB nach Microsoft
3.10 ESB nach Sun Microsystems
3.11 ESB nach Red Hat (JBoss)
3.12 Vergleich der ESB-Implementierungen
3.13 Fazit

4 Qualitätseigenschaften des ESB
4.1 Herangehensweise
4.2 Allgemeine Qualitätseigenschaften
4.3 Spezielle Qualitätseigenschaften
4.4 ESB-Qualitätsmodell
4.4.1 Performanz
4.4.2 Sicherheit
4.4.3 Funktionsumfang/Funktionalität
4.4.4 Benutzbarkeit
4.4.5 Testbarkeit, Integrierbarkeit
4.4.6 Wartbarkeit
4.4.7 Plattformunabhängigkeit/Portierbarkeit
4.4.8 Skalierbarkeit
4.4.9 Wiederverwendbarkeit
4.4.10 Standardunterstützung
4.4.11 Routingfähigkeiten
4.4.12 Transformationsfähigkeiten
4.5 Zusammenfassung

5 Bewertung von verfügbaren ESB-Implementierungen
5.1 Herangehensweise
5.2 Anwendung des Qualitätsmodells
5.2.1 Performanz
5.2.2 Sicherheit
5.2.3 Funktionsumfang
5.2.4 Benutzbarkeit
5.2.5 Testbarkeit, Integrierbarkeit
5.2.6 Wartbarkeit
5.2.7 Plattformunabhängigkeit/Portierbarkeit
5.2.8 Skalierbarkeit
5.2.9 Wiederverwendbarkeit
5.2.10 Standardunterstützung
5.2.11 Routingfähigkeiten
5.2.12 Transformationsfähigkeiten
5.3 Vergleich

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
6.2 Ausblick

A Transformation von Schnittstellenbeschreibungen

B Standards

C ESB-Anbieter

D Marktstudien nach Forrester

E Event Stream Processing

F Anwendung des ESB-Qualitätsmodells

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

2.1 Enterprise Service Bus nach Kischel

2.2 Enterprise Service Bus nach Chappell

2.3 Föderierter ESB nach Chappell

2.4 Inkrementelle Anpassung an den ESB nach Chappell

2.5 Integrationsansätze nach Chappell

2.6 Deployment-Szenarien des ESB nach Lorenzelli-Scholz

2.7 ESB-Service-Container nach Chappell . .

3.1 Service-Container nach JBI

3.2 Sonic ESB Produktfamilie

3.3 Sonic ESB-Architektur

3.4 Sonic ESB Beispiel

3.5 Fiorano SOA Plattform

3.6 Fiorano Enterprise Service Bus

3.7 Cape Clear ESB Pattform

3.8 Cape Clear Sicherheitsframework

3.9 BEA AquaLogic Data Services Platform . .

3.10 BEA AquaLogic Service Bus

3.11 Oracle Web Services Manager

3.12 Mule ESB

3.13 Mule UMO-/Service-Container

3.14 Mule Nachrichtentransport

3.15 Aufbau des Open ESB

D.1 Forrester Wave: Enterprise Service Bus, ESB Suites, Q4 ’05 .

D.2 Forrester Wave: Enterprise Service Bus, Comprehensive ESB Suites, Q4 ’05

D.3 Forrester Wave: Enterprise Service Bus, Q2 ’06

E.1 Aufbau und Bestandteile einer ESP-Engine nach Palmer

E.2 Einbettung einer ESP-Engine nach Palmer

F.1 Deployment-Topologie des gewählten Szenarios

F.2 Interaktion eines Aufrufs

F.3 Screenshot von JMeter

F.4 Antwortzeiten (AZ) im Vergleich

F.5 Anzahl paralleler Prozesse (PP) im Vergleich

F.6 Nachrichtendurchsätze (ND) im Vergleich

F.7 FU im Vergleich

F.8 BE im Vergleich

F.9 TI im Vergleich

F.10 PU und PUG im Vergleich

F.11 ST im Vergleich

F.12 Häufigkeitsverteilung der Qualitätsmetriken

Tabellenverzeichnis

3.1 Vergleich der ESB-Implementierungen

4.1 Betriebssysteme

4.2 Zusammenfassung der Qualitätsmaße/-metriken

5.1 Qualitätsmaße und -metriken der untersuchten ESB-Implementierungen

B.1 Web Service Standards (WS-Standards)

B.2 XML-basierte Standards

B.3 Protokoll Standards

B.4 Java-basierte Standards

B.5 Proprietäre Standards

B.6 Sonstige Standards

B.7 Standardkategorien

C.1 ESB-Anbieter und -Produkte

C.2 ESB-Anbieter Unternehmensdaten

F.1 Plattformeigenschaften des gewählten Szenarios

Listingverzeichnis

A.1 IDL-Datei

A.2 WSDL-Datei

F.1 WSDL-Schnittstellenbeschreibung

F.2 SOAP-Nachricht (Anfrage)

F.3 SOAP-Nachricht (Antwort)

F.4 Testplan des Lasttreibers

Kapitel 1

Einleitung

1.1 Motivation

In den letzten Jahren hat sich das Konzept der serviceorientierten Architektur (SOA) zu dem entscheidenden Ziel für moderne Geschäftsanwendungen entwickelt und glaubt man verschiedenen Softwareherstellern, so ist eine SOA bereits heute realisierbar. Den Kern einer solchen Architektur sollen Web Services und der so genannte Enterprise Service Bus (ESB) bilden. Hat sich die Web Service Technologie bereits über mehrere Jahre hinweg entwickelt und etabliert, so steckt der ESB hingegen noch in den Kinderschuhen. Dennoch sehen Ana- lysten aber auch die Industrie selbst den ESB als zukünftige Schlüsseltechnologie für den Aufbau einer SOA.

Mittlerweile hat sich ein umfangreicher Markt an ESB-Produkten entwickelt, die alle ge- geneinander konkurrieren. Gepriesen wird - neben seinem im Vergleich zu traditionellen Integrations-Frameworks¹ geringeren Preis - vor allem seine Fähigkeit, Schwachstellen bis- heriger Integrationsansätze zu überwinden. Für Kunden oder potenzielle Käufer stellt sich die Frage, was ihnen ein ESB bietet bzw. leisten kann und in wieweit verschiedene ESB- Produkte in Hinblick auf ihre Qualitätseigenschaften miteinander verglichen werden können.

Im Rahmen dieser Arbeit soll daher geklärt werden, was genau unter einem ESB zu verste- hen ist und welche möglichen Unterschiede dabei zwischen Forschung und Industrie bestehen. Darüber hinaus sollen in der Softwareindustrie eingesetzte ESB-Implementierungen auf ihre Qualitätseigenschaften hin untersucht werden. Basierend darauf ist ein Modell zur Beurtei- lung von Qualitätseigenschaften für ESB zu entwickeln und dieses für frei verfügbare ESB- Implementierungen anzuwenden.

1.2 Aufbau

Der Aufbau dieser Arbeit gliedert sich in mehrere Kapitel, wobei dieses Kapitel dazu dient, das Thema zu motivieren und im Weiteren eine grundlegende Einordnung zu liefern. Im Zentrum stehen dabei die SOA sowie dieser vorausgegangene bzw. sich anlehnende, aktuel- le Konzepte. Damit sollen Entwicklungen und Parallelen aufgezeigt werden, die helfen, das Konzept des ESB zu verstehen und gleichfalls eine Beschreibung seines Umfeldes liefern. Im zweiten Kapitel geht es um den Begriff ESB und was darunter zu verstehen ist. Da- bei interessieren vor allem die Ansichten aus Kreisen der Forschung und damit verbundene Begriffsdefinitionen. Von besonderer Bedeutung sind in diesem Zusammenhang die Fragen nach Aufbau, Eigenschaften und Funktionalitäten eines ESB. Daran anlehnend erfolgt im nächsten Kapitel eine umfangreiche und detaillierte Betrachtung von angebotenen ESB-Pro- dukten. Hierbei soll gezeigt werden, was seitens der Softwareindustrie unter dem Begriff ESB verstanden wird und welche Technologien konkret zum Einsatz kommen. Gleichfalls herauszuarbeiten sind Parallelen sowie mögliche Differenzen zwischen den Sichtweisen in der Forschung und in der Industrie. Das folgende vierte Kapitel konzentriert sich auf die Be- trachtung der Qualitätseigenschaften eines ESB. Im Rahmen eines zu erarbeitenden ESB- Qualitätsmodells werden hier allgemeine wie spezielle Qualitätseigenschaften aufgestellt und Kriterien zu deren Bewertung beschrieben. Die Anwendung des ESB-Qualitätsmodells auf frei verfügbare ESB-Implementierungen erfolgt im fünften Kapitel und endet mit einem ab- schließenden Vergleich. Den Schluss dieser Arbeit bildet eine zusammenfassende Betrachtung der gewonnenen Erkenntnisse sowie ein Ausblick auf zukünftige Entwicklungen und Themen- stellungen im Kontext des ESB.

1.3 Einordnung

Im Rahmen einer ersten Einordnung erfolgt an dieser Stelle eine kurze Einführung in das Umfeld heutiger Geschäftsanwendungen und mit ihr verbundener Technologien wie Konzep- te.

Rückblickend betrachtet, kann vor allem der Schritt hin zur objektorientierten Program- mierung als ein Meilenstein angesehen werden und soll als Ausgangspunkt für die weiteren Betrachtungen dienen. Nicht nur, dass die objektorientierte Programmierung andere Para- digmen vor allem die funktionsorientierte Programmierung weitestgehend abgelöst hat, sie führte auch im Rahmen des Softwareengineerings zu neuen, objektorientierten Konzepten (bspw. der UML² ). Die wesentlichen Eigenschaften, die für eine objektorientierte Program- mierung sprechen und letztlich zu ihrem Durchbruch führten, sind (vgl. [Hei03], S. 8; [Som01], S. 270):

- bessere Beherrschbarkeit von komplexen Softwaresystemen durch Abstraktion, Kapselung und Vererbung,
- höhere Wiederverwendung,
- Vermeidung von redundantem Programmcode (bspw. durch Vererbung),
- daraus resultierend eine bessere Wartbarkeit.

Charakteristisch für dieses Paradigma ist die Zerlegung der Software in Objekte³, die über Schnittstellen (Methoden genannt) miteinander kommunizieren. Ein Großteil dessen, was für die Entwicklung moderner Geschäftsanwendungen notwendig ist, steht damit zur Verfügung. Dennoch machte die Entwicklung nicht halt, was nicht zuletzt auf die Defizite des einfachen objektorientierten Paradigmas zurückzuführen ist.

Ein wesentlicher Kritikpunkt ist die Wiederverwendbarkeit, die nicht in dem Maße erreicht wurde, wie man sich das ursprünglich vorgestellt hat. Ursache dafür ist die hohe Granularität der Objekte, die eine Wiederverwendung auf Objektebene erschwert. Darüber hinaus haben sich verschiedene objektorientierte Programmiersprachen etabliert. Kann man auf Objekte ein und derselben Programmiersprache problemlos zugreifen, so ist dies für Objekte ver- schiedener Programmiersprachen oder unterschiedlicher Architekturen nicht ohne weiteres möglich. Middleware, die zur Behebung dieser Defizite entwickelt wurde wie etwa die Com- mon Object Request Broker Architecture (CORBA), führte zu Verbesserungen und einer gewissen Programmiersprachenunabhängigkeit, änderte aber nichts an der Objektgranulari- tät und den damit verbundenen Problemen (vgl. [Som01], S. 319; [SP01], S. 42 f.).

Ein Konzept, das bessere Wiederverwendungseigenschaften anstrebt, ist die komponenten- basierte Softwareentwicklung⁴. Was im Falle der objektorientierten Softwareentwicklung das Objekt, ist hier die Komponente. Der Begriff der Komponente ist jedoch im Gegensatz zu dem des Objekts wesentlich vielschichtiger. Es lässt sich bspw. bei Siedersleben eine Unter- teilung in fachliche⁵ und technische Komponenten⁶ finden. Definiert werden kann der Begriff Komponente, als eine unabhängige, ausführbare Entität, die über wohldefinierte Schnittstel- len eine bestimmte Funktionalität bzw. Dienst anbietet (vgl. [Som01], S. 320). Weiterhin bestehen Komponenten in der Regel aus kleineren Entitäten, wie etwa Objekten oder Mo- dulen und haben daher typischerweise den Charakter von Aggregaten (vgl. [Som01], S. 321; [Sie03], S. 100). Dies unterstreicht ebenso die Definition nach Szyperski, der eine Softwa- rekomponente als eine Komposition mit vertraglich vereinbarten Schnittstellen ansieht, die unabhängig eingesetzt werden kann und Gegenstand weiterer Kompositionen durch Dritte ist (vgl. [SGM02], S. 41)⁷. Diese Eigenschaft ist es auch, die das Problem der feingranularen Ob- jektstrukturen und der damit verbundenen Wiederverwendungsdefizite behebt. Ein weiterer Unterschied zur objektorientierten Programmierung liegt darin, dass der Fokus bei Kompo- nenten weniger auf dem Nachempfinden realweltlicher Objekte liegt, als vielmehr auf dem Schaffen von Softwarebausteinen bestimmter Funktionalität. Die Anforderungen, die dabei an Komponenten gestellt werden, sind (vgl. [GT00], S. 10 ff.; [Dum02]; [Dum03], S. 351):

- wohldefinierter Zweck,
- Kontextunabhängigkeit,
- Portabilität,
- Unabhängigkeit von der Umgebung (Hard- und Software),
- Ortstransparenz,
- Trennung von Schnittstelle und Implementierung,
- Selbstbeschreibungsfähigkeit,
- problemlose sofortige Nutzbarkeit,
- Integrations- und Kompositionsfähigkeit,
- Wiederverwendbarkeit,
- Konfigurierbarkeit/Anpassbarkeit,
- Austauschbarkeit,
- Bewährtheit,
- Vermarktbarkeit.

Mit diesen Zielen verband sich die Vision, dass Software zukünftig aus bereits vorhandenen Komponenten zusammengesetzt, quasi komponiert wird und diese auf eigenen Komponenten- marktplätzen gehandelt werden. Dank der geforderten Architektur- bzw. Implementierungs- unabhängigkeit wären Komponenten einfach integrierbar und gegeneinander austauschbar.

Wenngleich die komponentenbasierte Softwareentwicklung einige Wiederverwendungsdefizite beheben und sich verschiedenste Komponenten-Frameworks wie Component Object Model (COM), Enterprise JavaBeans (EJB) und .NET durchsetzen konnten, so wurden dennoch wesentliche Ziele und Visionen nicht oder nur teilweise erreicht. Ein Problem dabei waren die bereits angesprochenen Komponenten-Frameworks selbst, die einen Framework-übergrei- fenden Komponenteneinsatz kaum unterstützten. Komponenten eines Frameworks konnten nicht problemlos in ein anderes Framework integriert werden und waren somit nicht, wie ursprünglich gefordert, umgebungsunabhängig, austauschbar und problemlos nutzbar. Dies führte dazu, dass sich kaum Komponentenmarktplätze bildeten oder gar etablierten⁸. Eine Vermarktung von Komponenten fand in der Regel nicht statt. Ein weiteres Defizit der kom- ponentenbasierten Softwareentwicklung war die fehlende Integrationsmöglichkeit von Altan- wendungen, die ein aufwändiges Software Reengineering (Reverse Engineering und Reimple- mentierung) erfordert hätte. Dies führte in der Summe dazu, dass auch die komponenten- basierte Softwareentwicklung nicht das Maß an Wiederverwendbarkeit erreichte, wie einst prophezeit.

Einen anderen Ansatz verfolgt die Enterprise Application Integration (EAI), die folgende Kernziele benennt:

- anwendungsübergreifende Integration,
- Integration von Altanwendungen,
- Geschäftsprozessorientierung der Unternehmens-IT⁹.

So vielfältig wie das Feld der EAI-Produkte und EAI-Anbieter, ist auch das der Definitionen dieses Begriffs. Die folgenden beiden Definitionen sollen dies veranschaulichen.

„ EAI-Produkte sind Software, die es erlaubt, die Anwendungen eines Unterneh- mens zu integrieren. Der Begriff wurde gepr ä gt durch das Bem ü hen, viele An- wendungen, die nicht f ü r eine Zusammenarbeit entworfen wurden und auch nur Teilaufgaben von Gesch ä ftsprozessen abdecken, dazu zu bringen, in einheitlichen Gesch ä ftsprozessen zusammenzuspielen. Es geht also darum, heterogene Anwen dungen eines Unternehmens so zu integrieren, dass sie sich m ö glichst so ver halten, als w ä ren sie von Anfang an daf ü r entworfen worden, die aktuellen Ge sch ä ftsprozesse eines Unternehmens zu unterst ü tzen. “, [Kel02].

„ EAI ist kein Produkt, sondern ein Ansatz zur Entwicklung integrierter Anwen- dungssysteme. Dieser Ansatz ist eine Kombination aus Architektur, Technologie und Methodik. Er ist gepr ä gt durch die Verf ü gbarkeit von Softwareprodukten, die vorgefertigte Integrationsl ö sungen bereitstellen. EAI fokussiert sich auf die Inte- gration von Gesch ä ftsprozessen und Daten, w ä hrend traditionelle Methoden oft nur datenorientiert sind. EAI beinhaltet die Ziele der Wiederverwendung sowie der Verteilung von Prozessen und Daten. EAI erm ö glicht es Nutzern, Anwendun- gen auch nahezu ohne Kenntnis der technischen Details zu integrieren. “, [Kai02].

EAI ist folglich kein Produkt, sondern vielmehr ein Konzept, das softwaregestützt umgesetzt werden kann. EAI-Software/-Frameworks sollen dabei helfen, verschiedenste Anwendungen zu verknüpfen und auf diesem Wege das Problem der Architektur- und Implementierungs- abhängigkeit zu lösen. Darüber hinaus wird erstmals der Gedanke der (Geschäfts-)Prozess- orientierung in den Aufbau der Unternehmens-IT integriert. Weiterhin sollten u. a. noch vorhandene Offline-Schnittstellen, Redundanzen im Bereich von Daten und Funktionalitä- ten sowie bestehende Wiederverwendungsdefizite endgültig beseitigt werden (vgl. [Sch05a], S. 11).

Bei näherer Betrachtung von EAI stellt sich die Frage, warum sich daneben noch ein an- deres Konzept nämlich SOA etablieren konnte und heute droht, EAI nahezu vollständig zu verdrängen. Sind mit EAI nicht sämtliche Integrations- und Wiederverwendungsprobleme gelöst? Leider nein. Trotz des enormen Integrationspotenzials, das sich mit EAI verbindet, ist die Umsetzung dieses Konzepts problembehaftet (vgl. [Cha05a], S. 17; [Sch05a], S. 3):

- EAI-Projekte sind sehr umfangreich und benötigen damit enorme Budgets.
- EAI hat eine zu grobe Granularität für eine effektive Wiederverwendung.
- EAI-Software/-Frameworks sind sehr teuer und basieren im Wesentlichen auf eigenen, proprietären Standards.
- Die Realisierung von EAI mittels monolithisch aufgebauter und in Form einer Hub- and-Spoke Topologie¹⁰ angeordneter Integrationsserver kann sich mit Blick auf Skalie- rungsproblematiken als Flaschenhals für steigende Leistungsanforderungen erweisen.

Wurden in Unternehmen EAI Produkte verschiedener Anbieter verwendet, führte dies auf- grund proprietärer Standards und Protokolle in der Regel zu Integrationsinseln, d. h. Grup- pen aus jeweils miteinander integrierten Anwendungen und im schlimmsten Fall zu einer Vielzahl von Punkt-zu-Punkt Verbindungen¹¹. Die Beschränkung auf einen einzelnen An- bieter wiederum führte zu Abhängigkeiten und einer fehlenden Flexibilität. Darüber hinaus erfordern proprietäre Standards Spezialwissen, welches oftmals teuer erworben oder einge- kauft werden muss. Abgesehen von den konzeptionellen Zielstellungen von EAI liegt es gerade auch an diesen Defiziten, dass sich EAI für eine unternehmensübergreifende Integration kaum eignet und typischerweise mit sehr hohen Kosten verbunden ist (vgl. [Cha04a], S. 6; [PT05], S. 59 ff.).

Als logisch nächster Schritt aller vorangegangenen Konzepte entstand in den letzten Jahren die serviceorientierte Architektur. Die Überschneidungen, die dabei mit den bereits genannten Konzepten allen voran der komponentenbasierten Softwareentwicklung bestehen, zeigen sich in den folgenden Definitionen:

„ Service-orientierte Architekturen, kurz SOA, sind das abstrakte Konzept einer Software-Architektur, in deren Zentrum das Anbieten, Suchen und Nutzen von so genannten Diensten ¹² ü ber ein Netzwerk steht. Dabei werden Dienste fast aus- schlie ß lich von Applikationen oder anderen Diensten genutzt. Hierf ü r ist es un- erheblich, welche Hard- oder Software, Programmiersprache oder Betriebssystem die einzelnen Beteiligten verwenden. Unter anderem durch einheitliche Standards sollte es m ö glich sein, Dienste durch entsprechende Suchfunktionen zu finden, die von einem Anbieter genauso einfach publiziert werden k ö nnen. [. . . ] Im Idealfall ist sogar eine einfache Integration ganzer Anwendungen m ö glich. “, [DJMZ05], S. 7.

„ Unter einer SOA versteht man eine Systemarchitektur, die vielf ä ltige, verschie- dene und eventuell inkompatible Methoden oder Applikationen als wiederverwend- bare und offen zugreifbare Dienste repr ä sentiert und dadurch eine plattform- und sprachenunabh ä ngige Nutzung und Wiederverwendung erm ö glicht. “, [DJMZ05], S. 11.

„ Grundlegendes Prinzip einer SOA ist es, Funktionalit ä t als modulare und wie- derverwendbare Services zur Verf ü gung zu stellen. Neue Anwendungen k ö nnen, dann aus bereits existierenden Services „ zusammengesetzt “ werden. Man spricht dabei auch von einer losen Kopplung, da es keine starken logischen oder physi- schen Abh ä ngigkeiten gibt, und zwar weder zwischen den Services untereinander, noch zwischen den Services und den Anwendungen, in denen sie genutzt wer- den. Somit ist es auch leicht m ö glich, laufende Anwendungen durch Austausch einzelner Services zu modifizieren, zu erweitern oder zu optimieren. “, [Sch05a], S. 8.

Wie in den Definitionen bereits zum Teil schon enthalten, verbinden sich mit einer SOA Zielstellungen wie (vgl. [NL04], S. 54; [PT05], S. 51 f.; [Sch05a], S. 10 f.):

- höhere Wiederverwendung,
- Vermeidung von redundanten Daten und Funktionalitäten,
- Unabhängigkeit von der Umgebung (Hard- und Software),
- Integration von Anwendungen und Diensten,
- lose Kopplung,
- einheitliche Standards,
- Vermarktbarkeit von Services,
- an Geschäftsprozessen und deren Änderungen orientierter Aufbau.

Bemerkenswert ist, dass diese Ziele nicht neu sind, sondern schon seit langem existieren. Dennoch sind sie hoch aktuell, was nicht zuletzt auf Defizite der bisherigen Konzepte zu- rückzuführen ist.

Insgesamt soll SOA zu einer technischen Infrastruktur führen, die es ermöglicht, sich schnell neuen Geschäftsanforderungen anzupassen. Egal ob es sich um Individual- oder Standard- software handelt, alles soll sich miteinander integrieren lassen und so Integrationsinseln und Anbieterabhängigkeiten endgültig beseitigen. Nicht zuletzt besteht die Vision von kommerzi- ellen Diensten, die flexibel konsumiert und gegeneinander ausgetauscht werden können. Das Resultat ist eine schon lange angestrebte kosteneffiziente Unternehmens-IT (vgl. [NL04], S. 54).

Neben den bereits genannten Konzepten, bestand schon mit der Entwicklung erster Netz- werke die Notwendigkeit, Programme auch verteilt ablaufen zu lassen. Dies war die Geburts- stunde der Middleware, das heißt Software, die bildlich gesprochen in der Mitte zwischen zwei typischerweise verteilten Softwarekomponenten steht. Sie wird oft auch als glue¹³ (Kle- ber/Kleister) bezeichnet, da sie ähnlich wie dieser Anwendungen verbindet. Als eine erste Middleware entstand der Remote Procedure Call (RPC), der sich, wie sein Name schon sagt, noch stark an der prozeduralen Programmierung orientiert. Mit der objektorientier- ten Softwareentwicklung folgten auch auf dem Gebiet der Middleware neue Konzepte. Es entstand die objektorientierte Middleware. Vertreter dafür sind CORBA und die Remote Method Invocation (RMI). Eine andere Herangehensweise verfolgt die nachrichtenorientierte Middleware (MOM¹⁴ ), die aufgrund ihrer Bedeutung im Kontext von EAI und SOA etwas ausführlicher beschrieben werden soll.

MOM unterscheidet sich von den bereits genannten Middleware-Ansätzen neben einer auf Nachrichten aufgebauten Kommunikation vor allem durch die Fähigkeiten, Nachrichten spei- chern und verteilen zu können. Die Speicherung von Nachrichten lässt zu, dass Sender und Empfänger nicht notwendigerweise zum selben Zeitpunkt mit dem Netzwerk verbunden sein müssen, d. h. es wird eine asynchrone Kommunikation unterstützt. Mittels Routing¹⁵ können dabei Verbindungen zu einem (unicast) aber auch mehreren (multi- bzw. broadcast) Empfän- gern aufgebaut werden. Folgende Kommunikationsprotokolle werden von MOM unterstützt (vgl. [Cha04b], 84 ff.):

- Message Passing (Point-to-Point) - direkte Kommunikation zwischen zwei Endpunkten,
- Message Queueing (Store and Foreward) - indirekte Kommunikation über eine Nachrichtenwarteschlange (Queue),
- Publish-and-Subscribe¹⁶ - der Erzeuger (Publisher) stellt (typischerweise mehreren) Konsumenten (Subscriber) Nachrichten über Topics zur Verfügung.

Ein wesentlicher Vorteil, der sich aus diesen Eigenschaften ergibt, ist die Möglichkeit zu einer asynchronen, lose gekoppelten und durch entsprechende Mechanismen dennoch zuverlässigen Kommunikation. Damit verbunden ist eine parallele Verarbeitung und dadurch eine verbesserte Systemverfügbarkeit (vgl. [Cha04b], S. 5, S. 84 ff.).

Einen weiteren Ansatz stellt komponentenbasierte Middleware dar, allen voran die auf der Java 2 Enterprise Edition (J2EE) fußenden EJB. Diese orientiert sich einerseits am Komponentengedanken, übernimmt aber andererseits auch Fähigkeiten nachrichtenbasierter Konzepte. Ihre Bedeutung liegt vor allem im Bereich professioneller¹⁷ Unternehmensanwendungen. Sehr gut unterstützt wird dabei vor allem der Aufbau verteilter, weniger jedoch die Integration bereits bestehender Anwendungen.

Die in dieser Kette wohl jüngste Middleware-Technologie stellen Web Services (WS) dar. Diese basieren im Kern auf folgenden Standards (vgl. [NL04], S. 20 ff.):

- Simple Object Access Protocol (SOAP),
- Web Services Description Language (WSDL),
- Universal Description Discovery and Integration (UDDI).

Die Aufgaben gliedern sich wie folgt. SOAP, ein auf der Extensible Markup Language (XML) und dem Hypertext Transfer Protocol (HTTP) bzw. Simple Mail Transfer Protocol (SMTP) basierendes Protokoll, dient der Übertragung von Nachrichten¹⁸. Die Schnittstellen zum Sen- den und Empfangen von Nachrichten werden dabei mittels WSDL (ebenfalls XML-basiert) beschrieben. Dritter wesentlicher Baustein ist ein Verzeichnisdienst zum Eintragen und Fin- den von Diensten, der so genannte UDDI. Gestützt auf diese Technologien, ermöglichen Web Services die Realisierung einer (vgl. [NL04], S. 20 ff.; [DJMZ05], S. 27 ff.):

- standardbasierten,
- herstellerunabhängigen,
- in Bezug auf Firewalls problemarmen,
- offenen,
- flexiblen Middleware.

Es ist angesichts dieser Vorteile wenig verwunderlich, dass sich Web Services vor allem auf dem Gebiet der Enterprise Integration (EI) zur bevorzugten Middleware entwickeln. Sie er- möglicht eine standardbasierte Integration von Anwendungen und Diensten unterschiedlichs- ter Granularität. Eine unternehmensübergreifende Integration erscheint damit realisierbar. Nicht zuletzt ist es diese Technologie, die von Experten genannt wird, wenn es darum geht, eine SOA zu implementieren.

1.4 Fazit

Eine historische Betrachtung zeigt, dass sich das Konzept der SOA auf verschiedene, vor- ausgegangene Konzepte stützt und deren logische Weiterentwicklung darstellt. Einige we- sentliche Zielstellungen dieser Konzepte konnten jedoch nicht in dem Maße erreicht werden, wie einst vorgestellt. Nun ist es SOA, die diese jahrelang verfolgten Zielstellungen erbt und endlich ganzheitlich umsetzen soll. Der ESB wird in diesem Kontext als das technologische Fundament und zentrale Element einer SOA angesehen. Er ist es also, der das abstrakte Konzept der SOA und damit verbundene Zielstellungen wie Integration unterschiedlichster Anwendungen und Services, Realisierung einer Umgebungsunabhängigkeit (Unabhängigkeit von Hard- und Software), Verknüpfung mittels loser Kopplung und nicht zuletzt eine tatsäch- liche Wiederverwendung bestehender Software für die Praxis anwendbar machen soll. Ein weiterer wesentlicher Faktor für eine derartige Umsetzung stellen Web Services dar, die sich vor allem in den letzten Jahren rasant verbreitet haben. Im folgenden Kapitel soll gezeigt werden, was genau ein ESB ist bzw. nicht ist, welche Konzepte hinter dem ESB stehen und wie er in Bezug auf bereits existierende Technologien allen voran Web Services eingeordnet werden kann. Weitere Fragestellungen, die im Rahmen dieser Arbeit thematisiert und be- antwortet werden sollen, betreffen die Umsetzung des ESB in der Praxis, damit verbundene Technologien, seine Qualitätseigenschaften und den Grad der erfüllten Zielstellungen.

Kapitel 2 Der ESB aus Sicht der Forschung

2.1 Herangehensweise

Fast in jedem Zusammenhang wird heutzutage bei IT-Experten von SOA gesprochen und dies mancher Orten sogar als eine Revolution auf dem Gebiet der EI angesehen. Gleich im nächsten Atemzug fällt dann der Begriff ESB und es heißt, dieser sei der integrale Bestandteil beim Aufbau einer SOA. Weit weniger wortgewaltig drücken sich besagte Experten aus, wenn sie gezwungen werden, den Begriff ESB genau zu definieren oder die einfache Frage, was am ESB neu sei, zu beantworten.

Zur exakten Klärung des Begriffes ESB bedarf es einheitlicher Kriterien. Erst diese erlau- ben es, unterschiedliche Definitionen miteinander zu vergleichen und zu bewerten. Folgende Kriterien sollen beim Vergleich der anschließenden Definitionen berücksichtigt werden:

- Was ist ein ESB - ein Konzept, ein Softwareprodukt, eine Architektur oder ein Entwurfsmuster?
- Welchem Zweck dient der ESB?
- Was sind die Aufgaben bzw. Eigenschaften des ESB - wodurch wird er charakterisiert?
- Wie lässt sich ein ESB realisieren?
- Wo kommt der ESB zum Einsatz - innerhalb eines Unternehmens oder auch darüber hinaus?
- Welche Rolle spielt der ESB im Kontext von EAI und SOA und wie ist seine Umsetzung in Bezug auf Technologien wie MOM und Integrationsbroker zu sehen?

In einer ersten Annäherung soll der Begriff ESB seiner wortwörtlichen Übersetzung nach charakterisiert werden.

- Enterprise: ein Unternehmen, Betrieb oder Firma
- Service: ein Dienst
- Bus: ein Datenbus

Demnach geht es also darum, mittels eines Datenbusses Dienste für ein Unternehmen zur Verfügung zu stellen. Da dies in Bezug auf die zuvor genannten Kriterien nur wenig Aufschluss bringt, soll an dieser Stelle noch eine andere einführende Definition geliefert werden. Als eine solche kann die nach Wikipedia dienen.

„ In der Informationstechnologie bezieht sich der Begriff Enterprise Service Bus (ESB) auf eine Softwarearchitektur, die mittels standardbasierter Technologien aus dem Bereich der Middleware Infrastruktur implementiert werden kann und so grundlegende Dienste f ü r komplexere Architekturen ü ber eine ereignisgesteuerte und standardbasierte Nachrichten-Engine ¹ (dem Bus) zur Verf ü gung stellt.

Ein ESB liefert im Allgemeinen eine Abstraktionsschicht ü ber die Implemen- tierung eines Enterprise Messaging Systems, die es Integrationsspezialisten er- laubt, den Wert eines nachrichtenbasierten Systems zu nutzen ohne Programm- code schreiben zu m ü ssen. Im Gegensatz zum eher klassischen Ansatz der Enter- prise Application Integration und einem monolithischen Stack ² innerhalb einer hub-and-spoke Architektur, ist das Fundament eines Enterprise Service Bus aus grundlegenden, in ihre einzelnen Bestandteile zergliederten Funktionen aufgebaut, die soweit erforderlich oder notwendig verteilt eingesetzt und im Einklang zusam- menarbeiten k ö nnen.

Der ESB ist nicht die Implementierung einer serviceorientierten Architektur (SOA), verf ü gt aber ü ber die Eigenschaften mittels derer sich eine solche imple mentieren lie ß e. Obwohl weithin angenommen, ist der ESB nicht Web Service basiert. Der ESB sollte standardbasiert und flexibel sein und dabei viele Transport medien unterst ü tzen. Eher auf Prinzipien der Enterprise Integration als auf SOA Prinzipien basierend, versucht er die Kopplung zwischen aufgerufenem Dienst und Transportmedium zu beseitigen “, [Wik06a].

Hierbei wird noch nichts über die Eigenschaften eines ESB gesagt. Diese werden jedoch an späterer Stelle angeführt. Zu den Wichtigsten gehören dabei (vgl. [Wik06a]):

- Nutzung von XML,
- Unterstützung von Web Services,
- Unterstützung von nachrichtenbasierter Kommunikation (synchron, asynchron, Punktzu-Punkt und Publish-Subscribe),
- Nutzung von Standardadaptern zur Integration von Altanwendungen,
- Unterstützung von Service Orchestrierung³ und Service Choreographie⁴,
- Unterstützung von Diensten zur Transformation von gesendeten Daten,
- intelligentes⁵, inhaltsbezogenes⁶ Routing,
- Unterstützung standardisierter Sicherheitsmodelle.

Bei Anwendung der Definitionskriterien ergibt sich folgendes Bild. Ein ESB ist als erstes eine Softwarearchitektur. Der Zweck dieser Architektur liegt darin, dass sie eine Abstraktionsschicht über ein Enterprise Messaging System bildet, die einerseits die Nutzung nachrichtenbasierter Systeme erleichtern sowie andererseits die Kopplung zwischen Dienst- und Transportmedium aufheben soll. Im Vergleich zur EAI basiert der ESB nicht auf einer Huband-Spoke Architektur, sondern auf grundlegenden, in ihre einzelnen Bestandteile zergliederten Funktionen. Weiterhin ist der ESB nicht die Implementierung einer SOA, wenngleich mittels diesem eine solche implementiert werden kann.

Leider unthematisiert bleibt bei dieser Definition das Einsatzfeld des ESB. Es wird keine Aussage getroffen, ob es sich um eine Architektur handelt, die nur innerhalb eines Unternehmens Anwendung findet oder auch darüber hinaus, d. h. unternehmensübergreifend. Ansonsten stellt sich diese Definition als sehr detailliert heraus und kann daher als eine erste Referenz dienen. Wie dies an anderer Stelle, in Forschung und Industrie, gesehen wird, soll im weiteren Verlauf dieses Kapitels umfassend dargelegt werden.

2.2 Definition des ESB in der Forschung

2.2.1 Definition nach Schulte (Gartner)

Die erste Erwähnung des Begriffs ESB stammt aus dem Jahre 2002. Noch im selben Jahr lieferte Schulte (Analyst bei Gartner) diesbezüglich eine erste Definition.

„ Ein Enterprise Service Bus (ESB) ist eine neue Architektur, die Web Ser- vices, nachrichtenorientierte Middleware, intelligentes Routing und Transforma- tion nutzt. ESBs fungieren als ein leichtgewichtiges, allseits verf ü gbares Integrati- onsger ü st, durch welches Softwaredienste und Anwendungskomponenten flie ß en. “, [Far03].

Schulte sieht demnach den ESB als eine Architektur, die als ein allseits verfügbares Integra- tionsgerüst für Dienste wie auch Anwendungen dient. Bestandteile dieses Integrationsgerüsts sind Web Services, MOM, intelligentes Routing und Transformation. Sie ähnelt in diesen Punkten der Definition nach Wikipedia und sieht ebenfalls den ESB als eine Architektur.

In Bezug auf andere Kriterien, wie Technologien zur Umsetzung des ESB, Einsatzfeld, Rolle in Bezug auf EAI und SOA, gibt diese Definition nur wenig Aufschluss, weshalb sie an dieser Stelle nicht weiter diskutiert werden soll. Entschuldigende Ursachen für die angesprochenen Defizite mögen in dem Umstand liegen, dass es sich hierbei um die erste Definition die- ses Begriffs überhaupt handelt, wie auch in der Ermangelung fehlender Umsetzungen zum damaligen Zeitpunkt.

2.2.2 Definition nach Kischel (OBJEKTspektrum)

Ein erster größerer Artikel, den OBJEKTspektrum dem ESB widmete, stammt von Kischel aus dem Jahre 2003. Im Rahmen dieses Artikels gibt er die folgende Definition.

„ Der ESB ist ein messaging-basierter Softwarebus, der die Module eines Verbun- des von Anwendungen zu einer verteilten Gesch ä ftsanwendung verbindet. Seine Aufgaben sind:

- Verbinden der Anwendungsteile, der Services, zu einer verteilten Gesch ä fts- anwendung,
- Transformation und Zusammenstellen des Contents, den die Services aus- tauschen sowie
- Koordination des Verarbeitungsablaufs (BPM ⁷ ). Zentrale Elemente eines ESB sind:
- ein Messaging-System, das die physikalische Ebene des Busses realisiert und die Vielzahl der notwendigen F ä higkeiten, wie z. B. sichere und garantier- te Ü bermittlung, Persistenz bei asynchronen und lose gekoppelten Services bietet und
- ein Distributed Processing Framework (DPF), das als logische Ebene des Busses die Services verkn ü pft und die Prozesssteuerung ü bernimmt.

Der ESB erf ü llt diese Aufgaben durch eine Implementierung auf zwei Ebenen, die Transportschicht und die Prozessschicht. “, [Kis03], S. 37.

Im Kern stellt der ESB nach Kischel einen nachrichtenbasierten Softwarebus dar. Zweck dieses Softwarebusses ist es, durch Verbindung einzelner Module eines Anwendungsverbundes den Aufbau einer verteilten Geschäftsanwendung zu realisieren. Zu den weiteren Aufgaben neben dem Verbinden von Anwendungen und Services zählen Transformation und Zusam- menstellung von Servicedaten (Content) sowie die Koordination des Verarbeitungsablaufs. Im Unterschied zu Schulte aber auch zu Wikipedia wird der ESB nicht allgemein als eine Architektur definiert sondern konkreter als ein Message-basierter, d. h. nachrichtenbasierter Softwarebus. Betrachtet man die Aufgaben, die er nach Kischel zu erfüllen hat - zu ver- binden, zu transformieren und zu koordinieren -, so lassen sich diese bereits bei Wikipedia finden. Als zentrale Elemente benennt Kischel ein Messaging-System und ein so genanntes Distributed Processing Framework (DPF) (vgl. [Kis03], S. 37 f.).

Das Messaging-System bildet in diesem Zusammenhang die Transportschicht des ESB und damit die physikalische Ebene zur Realisierung des Busses. Zum Einsatz kommt dabei auf Standards basierende MOM. Als wichtige Standards nennt Kischel Java Message Service (JMS), J2EE Connector Architecture (JCA), SOAP (sowohl SOAP über JMS als auch SOAP über HTTP) und Java Database Connectivitiy (JDBC). Neben diesen Standards besteht die Notwendigkeit, Funktionen aus bestehenden Paketen und Anwendungen heraus zu publizie- ren und in den ESB einzuhängen. Hierzu müssen Services definiert werden, die dann die Schnittstelle zu den jeweiligen Anwendungen bilden. Dafür ist es unabhängig, aus welchen Quellen (Java, C/C++, Microsoft COM/ActiveX) die Daten stammen.

[...]

---

¹ Framework bezeichnet eine Rahmenstruktur bzw. ein Gerüst, das als Grundlage für weitere Entwicklungen dient.

² UML – Unified Modelling Language

³ Ein Objekt kann definiert werden als eine Entität, die einen Zustand (Menge von Attributen), ein Verhalten (Zustandsänderungen, d. h. Änderungen an den Attributen) und eine Identität besitzt (vgl. [Som01], S. 271; [SP01], S. 35 f.).

⁴ Auch als Component-Based Software Engineering (CBSE) bezeichnet.

⁵ Komponenten, die Dienste betrieblicher Anwendungsdomänen implementieren (vgl. [Sie03], S. 99 f.).

⁶ Komponenten, die Dienste technischer Anwendungsdomänen implementieren und in der Regel zur Unterstützung von Fachkomponenten dienen (vgl. [Sie03], S. 99 f.).

⁷ Noch weitere bei Szyperski zu findende Definitionen anderer Autoren sind von gleichbedeutendem Inhalt (vgl. [SGM02], S. 195 ff.).

⁸ Derartige Komponentenmarktplätze sind bspw. ComponentSource (www.componentsource.com) oder Fashline (www.flashline.com) (vgl. [SGM02]).

⁹ IT - Informationstechnologie

¹⁰ Der Begriff Hub-and-Spoke Topologie beschreibt eine Netzwerktopologie bestehend aus Nabe und Speiche. Mehrere Knoten eines Netzwerks (Spoke/Speiche) sind dabei mit einem zentralen Knoten verbunden (Hub/Nabe). Sie entspricht vom Aufbau her einer Sterntopologie.

¹¹ Van Huizen und andere sprechen in diesem Zusammenhang auch von einer Architektur des Zufalls (Accidental Architecture), die geprägt ist von Eigenentwicklungen, eingekauften wie übernommenen Anwendungen und Systemen sowie einzelnen Integrationsprojekten (vgl. [Cha04b], S. 28 ff.; [Hui03], S. 28).

¹² Die Begriffe Dienst und Service werden in der Literatur synonym verwendet und sind daher gleichzusetzen.

¹³ Zu finden bei Schmietendorf ([Sch05b], S. 8), Chappell ([Cha04b], S. 36) u. a.

¹⁴ MOM - Message Oriented Middleware

¹⁵ Unter Routing wird die Wegewahl von Nachrichtenströmen zur Nachrichtenübermittlung verstanden.

¹⁶ Eine Begriffsunterscheidung, die in diesem Zusammenhang vorgenommen wird, betrifft die Nachrichtenwarteschlangen. Diese werden bei unicast verschickten Nachrichten als Queues und bei mulit- oder broadcast verschickten Nachrichten als Topics bezeichnet.

¹⁷ Unter professionell sind hier höchste Anforderungen an Performanz, Sicherheit und Zuverlässigkeit zu ver- stehen.

¹⁸ Es ist anzumerken, dass SOAP nicht zwangsläufig an HTTP oder SMTP gebunden ist und deshalb, wie später gezeigt werden wird, auch andere Protokolle als Grundlage dienen können. Jedoch geht eine derartige Verwendung von SOAP über den Kontext von Web Services hinaus und wird aus diesem Grund hier nicht weiter thematisiert.

¹ Unter einer Engine (wörtlich Motor, Antrieb) wird der ausführende Teil einer Software (Ausführungskomponente) verstanden.

² Der Begriff Stack bezeichnet in diesem Zusammenhang eine über mehrere Schichten verteilte Menge von Technologien.

³ Unter Service Orchestrierung kann die Steuerung von Diensten gemäß übergeordneter Geschäftsprozesse und Prozessmodelle verstanden werden.

⁴ Der Begriff Service Choreographie überschneidet sich zum Teil mit dem der Service Orchestrierung, befasst sich jedoch weniger mit Abläufen gemäß von Prozessmodellen und dafür stärker mit der Steuerung und Koordination des notwendigen Nachrichtenflusses. Die Choreographie von Services ist daher eine wichtige Grundlage für deren Orchestrierung innerhalb von (Geschäfts-)Prozessen.

⁵ Nach Chappell können unter intelligentem Routing sämtliche auf Inhalt, Kontext, Geschäftsprozessen oder Prozessorchestrierung basierenden Formen von Routing verstanden werden (vgl. [Cha04b], S. 101). Aufgrund einer fehlenden genaueren Definition seitens Wikipedia kann ein möglicherweise abweichendes Begriffsver- ständnis nicht geklärt werden.

⁶ Inhaltsbezogenes Routing, auch Content Based Routing (CBR) genannt, meint das Routing einer Nachricht gemäß ihrem Inhalt.

⁷ BPM steht für Business Process Management, zu deutsch (Geschäfts-)Prozessmanagement und umfasst u. a. die Modellierung, Gestaltung, Steuerung, Verwaltung und Verbesserung von (Geschäfts-)Prozessen.