Bedeutung und Qualitätseigenschaften des Enterprise Service Bus im Kontext von serviceorientierten Architekturen E-Book
Steffen Hiekel
36,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Deutsch
Diplomarbeit aus dem Jahr 2007 im Fachbereich Informatik - Technische Informatik, Note: 1.7, Otto-von-Guericke-Universität Magdeburg, Sprache: Deutsch, Abstract: Thema der Diplomarbeit ist der Enterprise Service Bus (ESB) und wie mittels diesem eine service-orientierte Architektur (SOA) realisiert werden kann. Hierzu wird zunächst mit einer historischen Einordnung begonnen, die verschiedenste Konzepte und Technologien der jüngeren Vergangenheit kurz thematisiert (objektorientierte Programmierung, komponentenbasierte Programmierung, nachrichtenbasierte Middleware/MOM, EAI) und zum aktuellen Stand der Technik hingeführt (Web Services, SOA, ESB). Daran an schließt sich eine intensive Auseinandersetzung mit dem Begriff Enterprise Service Bus. Es werden verschiedene Sichtweisen aus Kreisen der Forschung vorgestellt, systematisiert und abschließend bewertet. Aufbauend auf der daraus resultierenden Begriffs¬definition, wird im weiteren Verlauf der Fokus auf die industrielle Sichtweise gelegt. Unterschiede und Gemeinsamkeiten zwischen Forschungs- und industrieller Sicht werden herausgearbeitet und einer Bewertung unterzogen. Ebenfalls sehr detailliert beschrieben werden dabei die ESB-Implementierungen namenhafter und zahlreicher Softwarehersteller sowie damit verbundene Technologien und Standards (MOM, Web Services, SOAP, UDDI, WSDL, XML, JMS, JCA, JMX, JBI, SLA, etc.). Der Leser erhält einen tiefen Einblick in den aktuellen Stand der Technik im Umfeld serviceorientierter Architekturen. Stärken und Schwächen einzelner Implementierungen (Produkte) werden klar und systematisch vermittelt und gleichsam mit dem gesamten Konzept Enterprise Service Bus auf den Prüfstand gestellt. Gestützt auf diese Betrachtungen wird nachfolgende ein Qualitätsmodell erarbeitet, das die Bewertung von ESB-Implementierungen hinsichtlich Qualität erlauben soll. Dieses Modell umfasst 12 verschiedene Qualitätskriterien (Standaradunterstützung, Routingfähigkeiten, Transfor¬mations¬fähigkeiten, Performanz, Plattformunabhängigkeit, etc.) und 25 verschiedene Qualitätsmetriken. Es ermöglicht die Durchführung von Qualitätsbewertungen für ESB-Implementierungen ohne einen größeren Aufwand und ist speziell für Evaluations- oder Erprobungsphasen geeignet. Die Anwendung dieses Qualitätsmodells wird am Beispiel von drei verschiedenen ESB-Implementierungen gezeigt und das Abschneiden dieser bezüglich der einzelnen Qualitätskriterien erläutert. Abschließend wird in einem kurzen Fazit der Inhalt und das Ergebnis der Arbeit zusammengefasst und im Rahmen eines Ausblicks auf zukünftige und noch zu erwartende Entwicklungen hingewiesen.
Die Arbeit erhielt den DASMA Diplomarbeitenpreis 2007. Die Arbeit erhielt den DASMA Diplomarbeitenpreis 2007.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2012
Ähnliche
Abkürzungsverzeichnis
INHALTSVERZEICHNIS V
INHALTSVERZEICHNIS VI
Kapitel 1
Einleitung
1.1 Motivation
Mittlerweile hat sich ein umfangreicher Markt an ESB-Produkten entwickelt, die alle ge- konkurrieren. Gepriesen wird - neben seinem im Vergleich zu traditionellen Integrations-Frameworks 1geringeren Preis - vor allem seine Fähigkeit, Schwachstellen bisheriger 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- 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 Beurteilung von Qualitätseigenschaften für ESB zu entwickeln und dieses für frei verfügbare ESB-Implementierungen anzuwenden.
KAPITEL 1. EINLEITUNG
1.2 Aufbau
1.3 Einordnung
Rückblickend betrachtet, kann vor allem der Schritt hin zur objektorientierten Program- als ein Meilenstein angesehen werden und soll als Ausgangspunkt für die weiteren Betrachtungen dienen. Nicht nur, dass die objektorientierte Programmierung andere Paradigmen vor allem die funktionsorientierte Programmierung weitestgehend abgelöst hat, sie führte auch im Rahmen des Softwareengineerings zu neuen, objektorientierten Konzepten (bspw. der UML 2). Die wesentlichen Eigenschaften, die für eine objektorientierte Programmierung 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.
KAPITEL 1. EINLEITUNG
Charakteristisch für dieses Paradigma ist die Zerlegung der Software in Objekte 3 , 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 verschiedener Programmiersprachen oder unterschiedlicher Architekturen nicht ohne weiteres möglich. Middleware, die zur Behebung dieser Defizite entwickelt wurde wie etwa die Common Object Request Broker Architecture (CORBA), führte zu Verbesserungen und einer gewissen Programmiersprachenunabhängigkeit, änderte aber nichts an der Objektgranularität und den damit verbundenen Problemen (vgl. [Som01], S. 319; [SP01], S. 42 f.).
Ein Konzept, das bessere Wiederverwendungseigenschaften anstrebt, ist die komponenten- Softwareentwicklung 4. 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 Siederslebeneine Unterteilung in fachliche 5und technische Komponenten 6finden. Definiert werden kann der Begriff
Komponente, als eine unabhängige, ausführbare Entität, die über wohldefinierte Schnittstel- 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 Modulen und haben daher typischerweise den Charakter von Aggregaten (vgl. [Som01], S. 321; [Sie03], S. 100). Dies unterstreicht ebenso die Definition nach Szyperski,der eine Softwarekomponente 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) 7. Diese Eigenschaft ist es auch, die das Problem der feingranularen Objektstrukturen und der damit verbundenen Wiederverwendungsdefizite behebt. Ein weiterer Unterschied zur objektorientierten Programmierung liegt darin, dass der Fokus bei Komponenten 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,
KAPITEL 1. EINLEITUNG4
Mit diesen Zielen verband sich die Vision, dass Software zukünftig aus bereits vorhandenen Komponenten zusammengesetzt, quasi komponiert wird und diese auf eigenen Komponentenmarktplätzen gehandelt werden. Dank der geforderten Architektur- bzw. Implementierungsunabhä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-übergreifenden 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 8. Eine
Vermarktung von Komponenten fand in der Regel nicht statt. Ein weiteres Defizit der kom- Softwareentwicklung war die fehlende Integrationsmöglichkeit von Altanwendungen, die ein aufwändiges Software Reengineering (Reverse Engineering und Reimplementierung) erfordert hätte. Dies führte in der Summe dazu, dass auch die komponentenbasierte 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 9 .
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- zu integrieren. Der Begriff wurde geprägt durch das Bemühen, viele Anwendungen, die nicht für eine Zusammenarbeit entworfen wurden und auch nur
KAPITEL 1. EINLEITUNG 5
„EAI ist kein Produkt, sondern ein Ansatz zur Entwicklung integrierter Anwen- 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 Integration 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, Anwendungen 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 Implementierungsabhängigkeit zu lösen. Darüber hinaus wird erstmals der Gedanke der (Geschäfts-)Prozessorientierung 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- 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 10angeordneter 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- proprietärer Standards und Protokolle in der Regel zu Integrationsinseln, d. h. Gruppen aus jeweils miteinander integrierten Anwendungen und im schlimmsten Fall zu einer Vielzahl von Punkt-zu-Punkt Verbindungen 11. Die Beschränkung auf einen einzelnen Anbieter wiederum führte zu Abhängigkeiten und einer fehlenden Flexibilität. Darüber hinaus
KAPITEL 1. EINLEITUNG6
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 12über ein Netzwerk steht. Dabei werden Dienste fast ausschließlich von Applikationen oder anderen Diensten genutzt. Hierfür ist es un- 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- und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare 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- 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 physischen Abhängigkeiten gibt, und zwar weder zwischen den Services untereinander, noch zwischen den Services und den Anwendungen, in denen sie genutzt werden. 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,
KAPITEL 1. EINLEITUNG7
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 zurü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 Standardsoftware handelt, alles soll sich miteinander integrieren lassen und so Integrationsinseln und Anbieterabhängigkeiten endgültig beseitigen. Nicht zuletzt besteht die Vision von kommerziellen 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- die Notwendigkeit, Programme auch verteilt ablaufen zu lassen. Dies war die Geburtsstunde der Middleware, das heißt Software, die bildlich gesprochen in der Mitte zwischen zwei typischerweise verteilten Softwarekomponenten steht. Sie wird oft auch als glue 13(Kleber/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 objektorientierten 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 14), 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 speichern 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 15 können
dabei Verbindungen zu einem (unicast) aber auch mehreren (multi- bzw. broadcast) Empfän- 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 16- der Erzeuger (Publisher) stellt (typischerweise mehreren)
Konsumenten (Subscriber) Nachrichten über Topics zur Verfügung.
KAPITEL 1. EINLEITUNG8
