Kurzfassung
1 Einleitung
1.1 Ziele der Arbeit
1.2 Abgrenzung
1.3 Related Work
1.4 Aufbau der Arbeit
2 Grundlagen
2.1 Cloud-Computing
2.1.1 Charakteristika
2.1.2 Servicemodelle
2.1.3 Bereitstellungsmodelle
2.2 Open Source Lizenzmodelle
2.3 Webservices
2.3.1 SOAP-Webservices
2.3.1.1 Webservice Description Language (WSDL)
2.3.1.2 SOAP
2.3.2 REST-Webservices
2.4 OAGIS
2.5 Lightening und Flattening
2.6 UN/EDIFACT
2.7 Enterprise Service Bus (ESB)
2.7.1 Architekturmodelle
2.7.2 Funktionalitäten
3 Logistics Mall - Cloud-Computing für die Logistik
3.1 Konzept
3.2 Anforderungen an den ESB
4 Marktübersicht
4.1 Produkte
4.2 Übersicht und Kenndaten
5 Vergleich nach Herstellerangaben und Eingrenzung der ESBs
5.1 Pflichtkriterien
5.1.1 Open Source
5.1.2 Programmiersprache Java
5.1.3 Betriebssystem Unix/Linux
5.2 Stufe 1: Kommerzieller Support
5.2.1 Untersuchte Teilaspekte
5.2.2 Ergebnis
5.3 Stufe 2: Dokumentation und Community
5.3.1 Untersuchte Teilaspekte der Dokumentation
5.3.2 Untersuchte Teilaspekte der Community
5.3.3 Ergebnis
5.4 Stufe 3: Vitalität/Reifegrad und Zukunftssicherheit
5.4.1 Untersuchte Teilaspekte Vitalität/Reifegrad
5.4.2 Untersuchte Teilaspekte der Zukunftssicherheit
5.4.3 Ergebnis
5.5 Stufe 4: Integrationsaspekte
5.5.1 Untersuchte Teilaspekte
5.5.2 Ergebnis
5.6 Stufe 5: Direkte Gegenüberstellung der verbleibenden ESBs
6 Praktischer Vergleich der ausgewählten ESBs
6.1 Untersuchte Aspekte
6.1.1 Installation/Einrichtung
6.1.2 Entwicklung
6.1.3 Benutzeroberfläche: Intuitiv / Übersichtlichkeit / Handhabung
6.1.4 Fehlermanagement
6.1.5 Sonstiges
6.1.6 Nicht betrachtete Aspekte
6.2 Szenario
6.2.1 Versuchsabläufe
6.2.2 Versuchsaufbau
6.2.3 Austauschformate
6.2.3.1 OAGIS
6.2.3.2 UN/EDIFACT
6.2.3.3 Custom XML
6.3 Realisierung des Testaufbaus
6.3.1 Servicebeschreibungen (WSDL)
6.3.2 Shop
6.3.3 Auftragsverwaltung
6.3.4 Lagerverwaltung Süd
6.3.5 Lagerverwaltung Nord
6.4 Einbindung ESB 1: Mule ESB
6.4.1 Route: Shop→Auftragsverwaltung
6.4.2 Route: Auftragsverwaltung→Lagerverwaltung Nord/Süd
6.4.3 Route: Lagerverwaltung Nord→Auftragsverwaltung
6.4.4 Route: Lagerverwaltung Süd→Auftragsverwaltung
6.5 Einbindung ESB 2: Talend ESB
6.5.1 Route: Shop→Auftragsverwaltung
6.5.2 Route: Auftragsverwaltung→Lagerverwaltung Nord/Süd
6.5.3 Route: Lagerverwaltung Nord→Auftragsverwaltung
6.5.4 Route: Lagerverwaltung Süd→Auftragsverwaltung
6.6 Deployment und Testdurchlauf
6.6.1 ESBs auf VM
6.6.2 Apps auf VM
6.6.3 Testdurchlauf
6.7 Ergebnis
7 Abschlussbetrachtung
7.1 Zusammenfassung aller Ergebnisse
7.2 Fazit
7.3 Ausblick
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Quellcodeverzeichnis
Literaturverzeichnis
A Anhang
A.1 Beispielnachrichten
A.1.1 OAGIS
A.1.2 UN/EDIFACT
A.1.3 Custom XML
A.2 Servicebeschreibungen
A.3 Codeausschnitte
Cloud-Computing ist aktuell ein sehr gefragtes Konzept. So wird zurzeit an den Fraunhofer Instituten für Software- und Systemtechnik (ISST) und Materialfluss und Logistik (IML) eine Cloud-basierte Logistikvertriebsplattform mit dem Namen Logistics Mall entwickelt. Damit soll es kleinen und mittleren Unternehmen möglich sein, komplexe Prozesse der Logistik durchführen zu können, ohne die dazu benötigte kostspielige und komplexe Software einkaufen zu müssen; das Mieten der Software reicht aus.
Innerhalb eines Logistikprozesses kommunizieren mehrere Systeme miteinander. Um diese Kommunikation zu ermöglichen, wird eine Middleware benötigt. Hierzu soll ein Enterprise Service Bus (ESB) eingesetzt werden. Ein ESB ist ein Konzept in der Softwarearchitektur, das zur Entkopplung von Softwaresystemen genutzt wird und jegliche Art von Kommuni- kationen zwischen diesen Systemen ermöglicht. Somit gehört zu den Kernaufgaben das Weiterleiten von Nachrichten zwischen den angebundenen Systemen. Des Weiteren sind häufig Transformationen der Nachrichten notwendig, falls die Systeme unterschiedliche Datenformate verwenden. Da es zahlreiche ESB-Produkte auf dem Markt gibt, muss ein Evaluationsprozess durchgeführt werden, um das den Anforderungen der Logistics Mall entsprechende Produkt zu finden.
In dieser Arbeit werden neun verschiedene Open Source ESBs untersucht. Zu Beginn wird ein mehrstufiger Vergleich anhand der Herstellerangaben durchgeführt, in dem sukzessive ESBs ausgeschlossen werden, die in bestimmten Aspekten hinter den Konkurrenzproduk- ten zurückliegen. Anschließend werden die beiden geeignetsten ESBs einem praktischen
Vergleich unterzogen. Hierzu wird ein praxisnahes Szenario konzipiert und realisiert, in welches beide ESBs eingegliedert werden, um anhand von vorher ausgewählten Kriterien miteinander verglichen zu werden. Zum Schluss wird eine Empfehlung ausgesprochen, wel- cher ESB hinsichtlich der genannten Anforderungen für die Logistics Mall am geeignetsten erscheint.
Die Fraunhofer Institute für Software- und Systemtechnik (ISST) und Materialfluss und
Logistik (IML) arbeiten an einer Cloud-Computing-Plattform für die Logistik (vgl. [Fra12]).
Damit soll es kleinen und mittleren Unternehmen (KMU) ermöglicht werden, spezielle
Anwendungen zu mieten, die zur Durchführung von Logistikprozessen notwendig sind. Ein solcher Logistikprozess ist sehr komplex und bedarf nicht nur einer spezifischen Software, sondern mehrerer eigenständiger Systeme. Der Vorteil einer Logistik-Plattform liegt für den Kunden darin, dass die benötigten Systeme in der Cloud vorhanden sind, sodass der Kunde sich nicht um Einkauf, Installation sowie Pflege und Wartung kümmern muss. Er bezahlt lediglich Mietgebühren für die Software, die für seine individuellen Logistikprozesse benötigt werden.
Die Logistics Mall - so der Name der Cloud-Computing-Plattform - soll also dafür eingesetzt werden, verschiedene Systeme miteinander zu koppeln und Nachrichten weiterzuleiten, damit der Logistikprozess durchlaufen werden kann. So müssen Lagerverwaltungen und Auftragsverwaltungen miteinander kommunizieren sowie Speditionen kontaktiert werden, die die Waren aus dem Lager abholen und versenden.
In der Mall soll der Aspekt der Kopplung - auch Middleware genannt - durch einen Enterprise Service Bus (ESB) realisiert werden. Dieser dient somit als zentrale Anlaufstelle für die Kommunikation zwischen allen Komponenten. Der ESB führt ein entsprechendes Routing durch, um die Nachrichten an die vorgesehene Anwendung weiterzuleiten sowie, falls notwendig, Transformationen durchzuführen, um Nachrichten zwischen Systemen austauschen zu können, die unterschiedliche Datenformate verwenden.
Es existiert eine Vielzahl an ESBs auf dem Markt. Sie haben unterschiedliche Eigenschaften und somit Vor- und Nachteile, teilweise basieren sie auf den gleichen Frameworks. Es sind zwar zahlreiche Vergleiche von ESBs verfügbar, diese sind aber meist veraltet, wurden nur oberflächlich durchgeführt oder haben einen ganz anderen Fokus. Dies erschwert den Findungsprozess für ein geeignetes Produkt für die Logistics Mall. Aus diesem Grund wird eine wissenschaftliche Untersuchung durchgeführt, um den geeignetsten Enterprise Service Bus zu bestimmen.
Damit ein geeigneter ESB für die Logistics Mall gefunden werden kann, müssen spezifische Anforderungen berücksichtigt und für eine detaillierte Evaluation einbezogen werden. Die Evaluation soll dabei nicht nur auf Produkteigenschaften beruhen, also auf den Angaben der Hersteller, sondern auch eine praktische Umsetzung umfassen.
Der Praxistest der ESBs soll auch zu ersten Erfahrungen mit den Produkten führen. Dazu soll ein logistiknahes Szenario konzipiert und umgesetzt werden, sodass anschließend die ESBs eingebunden werden können. Der Weg der Implementierung ist dafür festzuhalten und muss nachvollziehbar dokumentiert werden, um die spätere Anwendung der ESBs zu vereinfachen.
Eine der Hauptanforderungen an den ESB im Projektkontext ist die Bedienbarkeit des
Konfigurationswerkzeugs. Daher liegt der Hauptfokus dieser Arbeit auf der Usability.
Aufgrund der vielen Möglichkeiten und Funktionen, die ein ESB bietet und die jeweils separat ausführlich betrachtet werden könnten, muss diese Arbeit eingegrenzt werden. Im folgenden Abschnitt wird daher auf Aspekte eingegangen, die in dieser Evaluation nicht oder nur teilweise berücksichtigt werden.
Ein Enterprise Service Bus ist eine Sammlung unterschiedlicher Technologien und Frame- works, mit denen sich verschiedene Probleme lösen lassen. Dazu gehört zum Beispiel das Routing, das durch diverse Techniken wie zum Beispiel Content-based Routing, ermöglicht werden kann, um zum Beispiel entkoppelte Anwendungen intelligent durch den Bus zu verbinden.
In dieser Arbeit werden nur ausgewählte Eigenschaften betrachtet. Dazu werden nur die Funktionalitäten, die für ein Testszenario benötigt werden, implementiert und überprüft. Nichtfunktionale Eigenschaften wie Performanz, Zuverlässigkeit und Sicherheit sind für einen ESB aber auch sehr wichtig. Vor allem in systemkritischen Anwendungsgebieten in einem realen produktiven Einsatz muss darauf besonders Wert gelegt werden.
Grundanforderungen bedürfen einer separaten ausführlichen Evaluation. Für das in dieser Arbeit aufgestellte Szenario für den praktischen Vergleich werden sie nicht näher betrachtet, da der Fokus aus Aufwandsgründen rein auf der Machbarkeit der Umsetzung eines Szenarios sowie der Bedienbarkeit und Usability der ESBs liegt.
Viele ESBs nutzen die gleichen Frameworks als Unterbau. Dazu gehören zum Beispiel
Apache ActiveMQ (vgl. [The12a]) als Messaging-Framework und Apache Camel (vgl [The12b]) als Mediation-Framework. Deshalb würden sich im Detail diese ESBs ähnlich verhalten. Die Benutzeroberfläche, mit der die ESBs konfiguriert werden, kann sich trotz des ähnlichen Unterbaus voneinander unterscheiden. Auch aus diesem Grund wird in dieser Arbeit speziell die Usability in den Fokus gestellt.
Es existieren bereits zahlreiche ESB-Vergleiche, von denen hier einige vorgestellt werden.
An erster Stelle ist „The Forrester Wave: Enterprise Service Bus“ vom zweiten Quartal
2011 zu erwähnen (vgl. [Vol11]). In dieser Evaluation wurden Kunden und Entwickler über
den Einsatz von sieben kommerziellen und vier freien ESBs befragt. Bewertet wurden die
ESBs anhand der Marktpräsenz und der Funktionalität. Letzteres wurde aufgeschlüsselt nach Architektur, Verbindungsmöglichkeiten (Connection), Mediation, Orchestrierung und Tooling/Sicherheit (Change and control).
Einen Vergleich von zehn ESBs veröffentlichte die Firma AncudIT im Jahr 2010 (vgl. [Sch10]). Darin werden Open Source ESBs anhand ihrer technischen Möglichkeiten gegenübergestellt. Die Daten wurden in die Kategorien Systemumgebung, Kernfunktionalit ä t und Enterprise Funktionalit ä t eingeteilt.
JAXenter, ein Portal für Java, Enterprise Architekturen und SOA hat im Oktober 2011
einen Vergleich von elf ESBs durchgeführt (vgl. [WK11]). Wie auch beim Vergleich der
AncudIT werden hier tabellenartig die einzelnen Funktionalitäten und Möglichkeiten der ESBs aufgelistet.
Weniger ein direkter Vergleich von ESBs, sondern mehr eine Hilfestellung, ist das „Enterpri- se Service Bus Evaluation Framework“ der Patricia Seybold Group (vgl. [Mic05]). In diesem 21 Seiten umfassenden Bericht werden Kriterien verschiedener Kategorien vorgestellt, nach denen eine Evaluation eines ESBs durchgeführt werden kann. Dieser Katalog dient als Hilfestellung, um einen ESB nach den eigenen Anforderungen auswählen zu können. Pas-sende Kriterien können aus der Kategorien Integration Scenarios, Design Development, and
Deployment, Management and Monitoring, Architecture, Product Viability und Company
Viability entnommen werden. Für jedes Kriterium werden ferner auch Vorschläge gemacht,
wie dieser Punkt genauer untersucht werden kann und welche Aspekte dabei betrachtet werden können.
In diesen beschriebenen Vergleichen werden unterschiedliche ESBs und Versionen mit unterschiedlichen Kriterien untersucht. Sie können zur Auswahl eines ESBs nützlich sein, nehmen dem Anwender aber nicht die Arbeit ab, für das eigene System zu evaluieren. Des Weiteren wird in keiner der Arbeiten die Usability fokussiert, sowie auf die praktische Realisierung eingegangen und die ESBs anhand dessen verglichen. Mit dieser Masterarbeit soll die Lücke des praktischen Vergleichs geschlossen und anhand ausgewählter Kriterien ein weiterer Vergleich anhand der Herstellerangaben durchgeführt werden.
Kapitel 2 der Arbeit fasst Grundlagen zusammen, die benötigt werden, um den weiteren Teilen der Arbeit folgen zu können. Dazu gehört zum Beispiel das Cloud-Computing, der Enterprise Service Bus im Allgemeinen sowie unterschiedliche Datenformate, die in dieser Arbeit genutzt werden. An Stellen im Text, in denen gewisse Grundlagen vorausgesetzt werden, wird auf das entsprechende Grundlagenkapitel hingewiesen.
Kapitel 3 beschreibt die Cloud-Computing-Anwendung Logistics Mall. Es wird näher auf das allgemeine Konzept der Anwendung eingegangen und welche Akteure mit dem System interagieren. Des Weiteren werden in diesem Kapitel Anforderungen an den ESB aufgeschlüsselt, die sich aus dem Anwendungskontext ergeben und in der Evaluation berücksichtigt werden müssen.
Das anschließende Kapitel 4 bietet eine Marktübersicht über alle in dieser Arbeit unter- suchten ESBs. Die initiale Menge an Produkten ergibt sich aus den Pflichtkriterien Java, Open Source und Ausführbarkeit auf Linux/Unix-Systemen, auf die im folgenden Kapitel 5 noch näher eingegangen wird.
Nach der Vorstellung aller Produkte wird ein Vergleich anhand der Herstellerangaben und schließlich eine Eingrenzung der ESBs in Kapitel 5 durchgeführt. Dies erfolgt in mehreren Stufen. Jede Stufe befasst sich mit Kriterien aus ein bis zwei Hauptkategorien, die sich aus den Anforderungen ergeben. Somit werden die ESBs schrittweise aussortiert, die für die Logistics Mall weniger geeignet sind.
Im darauf folgenden Kapitel 6 werden die zwei geeignetsten ESBs in der Praxis evaluiert. Zu Beginn werden Kriterien vorgestellt, nach denen die ESBs bewertet werden. Anschließend
wird ein Szenario aufgebaut, in das die ESBs nacheinander integriert und somit verglichen werden können. Für dieses Szenario sind bestimmte Abläufe zwischen Anwendungen vorgesehen. Die Kommunikation erfolgt durch unterschiedliche Dialekte, die ausgetauschten Nachrichtenformate sind also untereinander nicht kompatibel. Diese Abläufe und die Dialekte werden schließlich vorgestellt. Der Aufbau des Szenarios und die Realisierung der Anwendungen, die an die ESBs angekoppelt werden sollen, ist in den darauf folgenden Abschnitten beschrieben.
Nachdem die Vorbereitung des Szenarios durchgeführt wurde, werden die ESBs nacheinander entsprechend des Szenarios konfiguriert. Im Anschluss daran wird kurz erläutert, wie die Umsetzung ausgeführt und getestet wurde. Darauf folgend wird das Ergebnis der praktischen Evaluation und somit das Endergebnis dieser Arbeit beschrieben. Zum Schluss wird in Kapitel 7 ein Fazit über die gesamte Arbeit gezogen sowie ein kurzer Ausblick gegeben, welche weiteren Forschungen angestrebt werden können.
In dieser Arbeit werden einige spezielle Konzepte und Technologien verwendet. Die Grund- lagen dazu werden in diesem Kapitel vorgestellt und dienen dem Leser zum allgemeinen Verständnis. Textstellen, an denen diese Konzepte auftreten, weisen stets eine Referenz zum entsprechenden Grundlagenkapitel auf. Somit ist es möglich, fehlende Grundlagen auch im späteren Verlauf der Arbeit nachzuschlagen.
Cloud-Computing, zu Deutsch in etwa „Rechnen in der Wolke“, steht für ein Konzept,in dem Kunden Computerressourcen von fremden Anbietern einfach und ohne große Konfiguration und Installation nutzen können. Die zugrunde liegende Hardware ist für den Kunden dabei nicht ersichtlich. Der Anbieter selbst kümmert sich um die Infrastruktur.
Der Begriff Cloud ergibt sich aus diesem Konzept: Ein Kunde greift auf Ressourcen in der
für ihn unbekannten Wolke zu, also ohne tiefer liegende Schichten kennen zu müssen.
Nach der Definition von Saugatuck Technology umfasst Cloud-Computing On-Demand- Infrastruktur im Bereich der Rechenleistung, Speicher und Netzwerktechnologie, sowie On-Demand-Software, zu der Betriebssysteme, Anwendungen, Middleware und Tools zählen.
Diese passen sich jeweils dynamisch an die Erfordernisse der Geschäftsprozesse an. Des
Weiteren ist es auch möglich, komplette Prozesse zu betreiben und zu managen (vgl.
[McN08]).
Das National Institute of Standards and Technology (NIST) hat zu dem Begriff Cloud- Computing typische Charakteristika, Servicemodelle und Bereitstellungsmodelle genauer spezifiziert (vgl. [MG11]), die im Folgenden erläutert werden.
Das NIST beschreibt für das Cloud-Computing fünf essentielle Charakteristika. Dazu gehört der On-demand self-service, mit der Aussage, dass es einem Verbraucher stets möglich sein muss, ohne die Herstellung einer menschlichen Interaktion Ressourcen beziehen zu können.
Diese Ressourcen müssen über standardisierte Mechanismen bereitgestellt werden, sodass jegliche Art von heterogenen Systemen Zugriff darauf erhalten können (Broad network access). Zu diesen Systemen gehören nicht nur große, stationäre Rechner, sondern auch mobile Geräte, Tablet PCs und Notebooks.
Eine weitere Charakteristik ist, dass die Ressourcen für den Konsumenten standortunabhängig angeboten werden. Er bekommt aus einem großen, möglicherweise verteilten Pool Ressourcen wie Speicher, Prozessorzeit und Netzwerkbandbreite angeboten (Resource pooling). Dieser Pool wird von allen Kunden des Anbieters geteilt. Dazu ist eine dynamische Zuteilung und Freigabe der Ressourcen an die Verbraucher notwendig. Welche physikalischen Medien geteilt werden, spielen für den Endkunden keine Rolle. Wichtig ist jedoch, dass stets nach tatsächlichen Bedarf dynamisch und automatisch mehr oder weniger Ressourcen bereitgestellt werden (Rapid elasticity).
Zuletzt muss beim Cloud-Computing jederzeit für Anbieter und Konsument transparent sein, in welchem Umfang die Ressourcen genutzt wurden (Measured service). Dazu müssen geeignete Methoden umgesetzt werden, um Metriken wie verbrauchten Speicher, genutzte Prozessorzeit oder ähnliches ermitteln zu können.
Beim Cloud-Computing können Ressourcen in unterschiedlich definierten Servicemodellen angeboten werden. Die Unterscheidungen werden je nach Abstraktionsgrad vorgenommen. Nach Definition des NIST gibt es drei Servicemodelle: Infrastructure-as-a-Service, Platform- as-a-Service und Software-as-a-Service.
Beim Infrastructure-as-a-Service (IaaS) steht das klassische Bereitstellen von Hardware- Ressourcen im Vordergrund. So werden Prozessorleistung, Arbeitsspeicher und Festplatten- speicher zur Verfügung gestellt. Oft richten sich diese Angebote direkt an Administratoren von Unternehmen. So können virtuelle Maschinen gemietet werden, auf denen zum Beispiel in Eigenregie Betriebssysteme installiert werden können, die von der zugrunde liegenden Hardware profitieren.
Ein an Entwickler gerichtetes Modell ist Platform-as-a-Service (PaaS). Dabei werden Laufzeitumgebungen als Service zur Verfügung gestellt, auf denen entwickelte Anwendungen deployed werden können. Die Entwickler müssen sich im Sinne des Cloud-Computing nicht um das zugrunde liegende Betriebssystem und auch nicht um die Hardware-Ressourcen kümmern. Dies liegt in der Verantwortung des Anbieters.
In einer höheren Abstraktionsschicht ist Software-as-a-Service (SaaS) angesiedelt. Bei
diesem Modell werden ganze Anwendungen als Service zur Verfügung gestellt. So kann über standardisiertem Weg über das Netzwerk auf Software zugegriffen werden, ohne sich um Installationen oder Updates Gedanken machen zu müssen.
In Abbildung 2.1 wird die Anordnung dieser drei essentiellen Modelle veranschaulicht. Je
höher der Abstraktionsgrad ist, desto mehr wird dem Konsumenten an Hardware- und Konfigurationsaufwand abgenommen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Servicemodelle beim Cloud-Computing (vgl. [Pal10])
Die Vielfalt an unterschiedlichen Angeboten auf dem Markt ist zunehmend. So entstan-
den weitere Servicemodelle wie zum Beispiel Communication-as-a-Service (CaaS) oder Monitoring-as-a-Service (MaaS), die zum Cloud-Computing hinzugezählt werden können.
Aufgrund der Vielfalt an vorhandenen Servicemodellen etabliert sich zunehmend der Begriff Everything-as-a-Service (EaaS, Xaas oder *aaS) als Sammelbegriff für verschiedene, auch kombinierte, Angebote (vgl. [RR10, S. 54]).
In der Definition des NIST werden verschiedene Bereitstellungsmodelle vorgestellt (vgl. [MG11]). Üblicherweise werden die unterschiedlichen Servicemodelle von fremden Anbietern über die öffentliche Cloud, also dem Internet, zur Verfügung gestellt. Hierbei spricht man von der Public Cloud. Somit ist es für jedermann möglich, die Services zu nutzen. Die Public Cloud wird vom NIST nochmals in zwei Bereiche unterteilt. Einmal in die Open Cloud, bei der für jeden der Zugriff auf die Ressourcen anonym möglich ist. Der zweite Bereich der Public Cloud umfasst die Angebote, die erst durch Abschließen eines Vertrags zwischen Anbieter und Konsument zustande kommen. Der als Exclusive Cloud bezeichnete Bereich ist somit nicht mehr anonym nutzbar.
Neben dem öffentlichen Zugang zu den Cloud-Angeboten ist es ferner auch möglich, eine eigene Cloud herzustellen. Die vom NIST bezeichnete Private Cloud wird in Organisationen eingesetzt, um zum Beispiel bestimmten Abteilungen dynamisch Ressourcen zur Verfügung stellen zu können, ohne manuell Eingriff in die Infrastruktur vornehmen zu müssen. Aber auch zu Testzwecken kann eine Private Cloud eingerichtet werden, um evaluieren zu
können, inwiefern zum Beispiel der Skalierungsfaktor für eigene Anwendungen einen Nutzen bringt.
Als drittes Bereitstellungsmodell für Services gibt es nach Definition des NIST die Hybrid
Cloud. Hierbei werden die beiden zuvor erläuterten Modelle der Public und Private Cloud
kombiniert. So kann zum Beispiel eine Private Cloud dynamisch als Failover-Strategie
Rechenkapazitäten aus der Public Cloud hinzuziehen, falls die eigene Hardware in der Private Cloud bei Lastspitzen nicht mehr ausreicht.
Open Source Software (OSS), oder auch „Freie Software“, hat den Grundgedanken, dass die Freiheit gegeben wird, den Quellcode für ein Programm zu bekommen sowie es verbreiten zu dürfen. Dabei soll gestattet sein, die Software zu verändern, und/oder Teile davon in neue Programme zu übernehmen.
Damit dem Entwickler der Software aber Rechte eingeräumt werden, bedarf es angepasster Lizenzen für Open Source Software. In den folgenden Abschnitten werden einige Lizenz- modelle vorgestellt, die bei den verschiedenen Produkten, die in dieser Arbeit untersucht werden, eingesetzt werden.
GNU General Public Licence (GPL)
Die GNU GPL ist die bekannteste Lizenz für Open Source Software und wurde in der
ersten Version im Jahr 1989 von Richard Stallman ursprünglich für das GNU-Projekt entworfen, einem vollständig freien Betriebssystem. Aktuell liegt die GPL in der Version 3 vor. Sie räumt dem Lizenznehmer weitreichende Rechte für die Nutzung der Software ein.
Jedem Nutzer ist es so gestattet, die Software zu vervielfältigen, zu verbreiten, öffentlich zugänglich zu machen und zu verändern (vgl. [Ins05]).
In der GPL sind aber nicht nur Rechte vorgesehen, sondern auch Verpflichtungen. Darunter fällt das Copyleft-Prinzip: Abgeleitete Programme eines unter GPL stehenden Werkes dürfen nur dann verbreitet werden, wenn sie unter gleichen Bedingungen der GPL lizenziert werden.
GNU Affero General Public Licence (AGPL)
Die AGPL ist eine von der GPL abgeleitete Lizenz die ebenfalls das Copyleft-Prinzip
enthält. Einzig der Artikel 13 der GPL wurde abgeändert. So gibt es die zusätzliche Verpflichtung zur Veröffentlichung des Quellcodes bei Anwendungen, die im engeren Sinn nicht verbreitet werden, sondern anderweitig veröffentlicht wurden. Das sind zum Beispiel Remotediense, Webapplikationen und Portale. Der Code der Applikationen wird nicht beim Nutzer ausgeführt. Somit findet keine Verbreitung in Sinne der klassischen GPL statt. Hier greift aber die AGPL ein, sodass auch Quellcode solcher entfernten Dienste veröffentlicht werden muss.
GNU Lesser General Public Licence (LGPL)
Die LGPL ist ebenfalls eine von der GPL abgeleitete Lizenz. Sie gilt als entschärfte Variante der GPL, da die Verwendung von unter dieser Lizenz stehenden Programmteilen nicht dazu verpflichtet, ebenfalls die neue Anwendung unter dieser Lizenz zu stellen. Es müssen lediglich die verwendeten Module unter dieser Lizenz stehen. Aus diesem Grund ist die LGPL besonders für Bibliotheken geeignet. Ursprünglich stand die Abkürzung LGPL auch für Library GPL. Dies wurde jedoch geändert, damit die Lizenz nicht nur beschränkt auf Bibliotheken gilt, sondern auch anderweitig eingesetzt werden kann (vgl. [Kir03]).
Mozilla Public Licence (MPL)
Diese Lizenzierung wird überwiegend bei Software des Unternehmens Mozilla eingesetzt wie zum Beispiel dem Webbrowser Firefox. Die MPL enthält ähnlich der GPL eine Copyleft- Bedingung, die aber weniger restriktiv ist. So müssen zwar geänderte oder kopierte Quell- codes weiterhin unter der MPL stehen, sie dürfen jedoch zusammen mit proprietärem Code als eine Anwendung genutzt werden. Diese Anwendung darf dann auch proprietär unter einer eigenen Lizenz veröffentlicht werden. Somit ist die MPL nicht mit der GPL kompatibel (vgl. [Moz12]).
Common Development and Distribution Licence (CDDL)
Die CDDL basiert überwiegend auf der Mozilla Public Licence und wurde von der Firma Sun Microsystems für deren Software OpenSolaris entwickelt. Lediglich kleinere Modifizie- rungen wurden vorgenommen. Darunter fallen zum Beispiel vereinfachte Erläuterungen der Klauseln, sowie eine ergänzende Klausel die klar stellen soll, was alles unter dieser Lizenz steht und was nicht. Diese Lizenz kann ebenfalls mit anderen Lizenzen kombiniert werden (vgl. [Ora09]).
Common Public Attribution Licence (CPAL)
Die CPAL basiert, wie auch die CDDL, größtenteils auf der MPL. Der wesentliche Unter-
schied ist, dass abgeleitete Anwendungen des unter dieser Lizenz stehenden Werkes „ [. . . ]
eine deutliche Anzeige der Namensnennung des urspr ü nglichen Entwicklers [. . . ] “ enthalten muss (vgl. [Ope12b]). Aus diesem Grund ist die CPAL nicht mit der GPL kompatibel.
Apache Licence
Die Apache Software Foundation hat eigens für ihre Projekte eine eigene Lizenz entworfen. Es muss explizit darauf hingewiesen werden, wenn Werke unter dieser Lizenz eingesetzt werden. Die Lizenzdatei muss bei jeder unter dieser Lizenz stehende Anwendung beiliegen. Anders als bei der GPL muss die eigene Software, unter Verwendung von Anwendungen die unter dieser Lizenz stehen, selbst nicht unter dieser Lizenz stehen. Die Apache Lizenz ist mit der aktuellen GPL in der Version 3 kompatibel, insofern das gesamte Projekt unter der GPL v3 gestellt wird (vgl. [Apa12]).
Dieser Abschnitt sowie alle Unterabschnitte sind Ausz ü ge meiner Forschungs- und Entwicklungsarbeit (vgl. [ Bd12 ]) Bei Webservices handelt es sich um modular gekapselte Dienste, die standardisiert mittels des Hypertext Transfer Protokolls (HTTP) über Netzwerke angeboten und aufgerufen werden können. Das Veröffentlichen geschieht dabei entweder über die Weitergabe der URL des Services an den entsprechenden Nutzer, oder aber durch Veröffentlichen in einen zentralen Verzeichnisdienst, wie zum Beispiel in ein UDDI-Repository (Universal Description, Discovery and Integration). Letztere Möglichkeit wurde aber von großen Unternehmen wie SAP, IBM und Microsoft zurückgezogen, da sie der Meinung sind, dass das Veröffentlichen eines Services in ein zentrales Verzeichnis nicht die Art ist, wie heutzutage Geschäfte gemacht werden (vgl. [Kri05]).
„ Needless to say, this isn ’ t how companies do business - there ’ s always a human element to establishing a relationship. As a result, the [UDDI Business Registry (UBR)] served as little more than an interoperability reference implementation.
Now that UDDI has become more of a metadata management standard for SOA, there ’ s little need for the UBR anymore. “ - Jason Bloomberg [Kri05]
Die veröffentlichten Dienste sind Schnittstellen des Systems, auf die weitere, verteilte
Systeme Zugriff haben. Durch das Komponieren von Webservices (Orchestrierung) und
durch geregelte Kommunikation zwischen mehreren Services (Choreographie) können komplexe Geschäftsprozesse abgebildet werden. Dabei gibt es verschiedene Möglichkeiten (Protokolle), diese Dienste bereitzustellen und aufzurufen. Dies ist zum einen über SOAP möglich und wird im folgenden Kapitel 2.3.1 erläutert. Die andere Möglichkeit bietet REST, das in Kapitel 2.3.2 beschrieben wird.
SOAP steht ursprünglich für Simple Object Access Protocol und bedeutete so viel wie „Protokoll für einfachen Objektzugriff“. Da SOAP allerdings gar nicht zum Zugriff auf Objekte geeignet ist und auch nicht einfach ist, wurde mit dem Erscheinen der Version 1.2 diese Abkürzung abgeschafft. SOAP ist somit ein Begriff für sich selbst (vgl. [Jos08, S. 268 f.]).
SOAP ist die erste Möglichkeit zum Aufrufen eines Webservices und stellt eine Art des Datenaustauschs dar. Grundlegend dafür ist die WSDL-Datei, die die einzelnen Operationen des Services auflistet und beschreibt, welche Parameter und Rückgabewerte diese besitzen. In Kapitel 2.3.1.1 wird auf den Aufbau der WSDL-Datei eingegangen. In Kapitel 2.3.1.2 wird schließlich der Aufbau einer SOAP-Nachricht erläutert.
WSDL steht für Webservice Description Language und stellt die Beschreibungssprache für SOAP-Webservices dar. Mit ihr kann auf standardisiertem Wege die Schnittstelle zwischen Service-Anbieter und Konsument definiert werden. WSDL wird durch die Spezifikation des World Wide Web Consortium (W3C) definiert (vgl. [W3C01] und [W3C07]). Zurzeit exis- tieren zwei wesentliche Versionen. Die am weitesten verbreitete und in diversen Werkzeugen und Technologien eingesetzte Version ist 1.1. Es gibt WSDL bereits in der Version 2.0.
Diese verfügt über einige Verbesserungen und Erweiterungen, die in folgender Auflistung aufgeführt sind (vgl. [Dhe04]).
- Das Attribut targetNamespace in WSDL 2.0 ist jetzt ein Pflichtattribut im Wurzelelement definitions
- Das message-Konstrukt wurde entfernt. In WSDL 2.0 wird direkt auf das Element types referenziert
- Operatorüberladung wird nicht mehr unterstützt
- PortTypes wurde umbenannt zu interfaces. Interface-Vererbung ist über das Attribut extend im interface Element möglich
- ports wurde umbenannt zu endpoints
In Abbildung 2.2 ist der Aufbau der unterschiedlichen Versionen gegenübergestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Aufbau einer WSDL-Datei in Version 1.1 und 2.0 (vgl. [Jos08, S. 262 f.])
Mit service und port, beziehungsweise endpoint in der neuen Version, wird der Service durch die genaue Adresse in Form einer URL mit dazugehörigem Port angegeben. Durch das binding werden dann die verschiedenen Operationen an den Service gebunden. Des Weiteren wird hier das genaue Übertragungsprotokoll festgelegt.
Innerhalb des portType beziehungsweise interface wird die Verknüpfung zwischen Ope-rationen und Request- und Responseparametern, bzw. Parameter und Rückgabewert,hergestellt. In der WSDL 1.1 Spezifikation können mit message allgemeine Datenpakete deklariert werden, die durch types mit Hilfe der XML-Schema Spezifikation exakt beschrie- ben werden. In der Version 2.0 ist dies durch direkte Referenzierung zu types möglich. Innerhalb der types werden schließlich einzelne Attribute benannt, die Häufigkeit des Auftretens sowie die Variablentypen. Es besteht auch die Möglichkeit, die XML-Schema Typenspezifikation auszulagern und innerhalb des WSDL-Dokuments zu importieren.
Die Spezifikation von SOAP beschreibt in erster Linie den Aufbau und das Format der Nachrichten, die bei einem Service-Aufruf zwischen Konsument und Serviceanbieter ausgetauscht werden. Die zu übertragenden Daten werden in einen speziellen Umschlag eingebettet, wie es in Abbildung 2.3 dargestellt ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Aufbau einer SOAP-Nachricht
Dabei wird innerhalb eines Umschlags (soap:Envelope) ein Header (soap:Header) und ein Body (soap:Body) eingefügt. Syntaktisch wird das Austauschformat mit Hilfe der Extensible Markup Language (XML) beschrieben. Im Listing Quellcode 2.1 ist eine Nachricht im XML-Format exemplarisch dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Quellcode 2.1: Aufbau einer SOAP-Nachricht in XML
Die Nutzdaten innerhalb des Body-Tags stellen den fachlichen Teil mit den wichtigen Daten dar. In dem gezeigten Beispiel ist das die Anforderung von Informationen über das Auto mit dem Kennzeichen DO-FH 123. Aus diesem Grund ist das Body-Element in einer SOAP- Nachricht Pflicht. Der Header hingegen ist obligatorisch und kann infrastrukturbedingte Informationen wie zum Beispiel Routing- und Sicherheitsparameter enthalten.
Neben SOAP gibt es noch die REST-Webservices. REST steht für Representational State Transfer und hat sich parallel zu SOAP als leichtgewichtige Variante entwickelt (vgl. [Fie00]). Architekturen, die REST-Webservices nutzen, werden auch als RESTful bezeichnet. Die Prinzipien dieser Technik werden schon längst, wenn auch vielleicht nicht bekannt,im Internet eingesetzt. Ressourcen und Methoden werden über einen Uniform Resourc Identifier (URI) angesprochen; quasi wie der Aufruf einer Webseite. Dabei kommen die Standard HTTP-Methoden GET, POST, PUT und DELETE zum Einsatz (vgl. [Löw11]).
REST-Webservices können als Kollektion von Ressourcen angesehen werden. Jede dieser Ressourcen ist durch eine Basis URI zu erreichen, gefolgt von einer eindeutigen ID, die die gewünschte Ressource identifiziert. Ein Beispiel-Webservice, über den man Informationen über ein Auto über das KFZ-Kennzeichen als ID erhalten kann, könnte wie im folgenden Listing 2.2 über die HTTP-Methode GET aufgerufen werden.
Abbildung in dieser Leseprobe nicht enthalten
Quellcode 2.2: Beispiel eines Service-Aufrufs mittels REST
Dabei stellt die URI ohne das KFZ-Kennzeichen die Kollektion aller, über diesen Ser- vice registrierten, Autos dar. Mit diesem Prinzip können schließlich Ressourcen-basiert Webservices angeboten werden. Der Rückgabewert eines REST-Aufrufs kann, anders als bei SOAP-Webservices, variieren. So kann die Antwort, wie auch bei SOAP-Webservices, im XML-Format zurückgeliefert werden aber auch Formate mit weniger Overhead, wie zum Beispiel JSON (JavaScript Object Notation) sind weit verbreitet.
Das Pendant zur WSDL-Datei ist bei RESTful-Webservices die WADL-Datei (Web Application Description Language, vgl. [Had09]). Darüber können ebenfalls Services und deren Eingabe- und Ausgabeparameter deklariert werden.
Dieser Abschnitt sowie alle Unterabschnitte sind Ausz ü ge meiner Forschungs- und Entwicklungsarbeit (vgl. [ Bd12 ])
OAGIS ist ein transaktionsorientierter Business-Standard der Open Application Group Inc.
(OAGi) für Dienste wie e-Commerce, Cloud-Computing, Service-orientierte Architekturen (SOA) und Webservices (vgl. [Ope12a]). Das Hauptproblem von verteilen und heterogenen Systemen ist die Kommunikation untereinander. Die große Herausforderung dabei ist, dass jedes System auch alle anderen Systeme „verstehen“ kann. Mit der Spezifikation der Open Applications Group wurde dazu ein Standard eingeführt, der wie eine eigene Sprache für die Systemlandschaften zu verstehen ist. So ist es auch möglich, weitere Systeme anzukoppeln, die sich an der Kommunikation beteiligen können.
Die Geschäftsdokumente, die hierbei zwischen den Geschäftspartnern ausgetauscht werden, werden Business Object Documents (BODs) genannt. Ein solches BOD ist in zwei Bereiche unterteilt. Das ist zum einen die ApplicationArea, in der nicht-fachliche Daten, die meist technischer Natur sind, untergebracht sind. Das ist zum Beispiel die eindeutige Kennung des Senders oder aber auch der Zeitpunkt der Erstellung des BODs. Zum Anderen ist in dem Dokument der fachliche Teil in der DataArea untergebracht. Dieser Bereich ist, wie auch in Abbildung 2.4 zu sehen ist, in zwei weitere Bereiche unterteilt; in Verbs und Nouns.
Ein Noun (zu deutsch: „ Nomen “) entspricht hierbei den wichtigen Geschäftsdaten, die
weitläufig auch Business Objekte genannt werden. Dazu sind von OAGIS eine Vielzahl von Business Objekten spezifiziert worden (In Version 9.5.1 existieren 84 Nouns). Darunter ist zum Beispiel ein Noun für eine Bestellung (PurchaseOrder) oder für den Status einer Bezahlung (PaymentStatus).
Innerhalb eines jeden Nouns ist des Weiteren ein Block Components zu finden, innerhalb dessen der Block Fields vorzufinden ist. Components sind modulare Basisdatenblöcke, wie zum Beispiel der Block Adressen, die von allen BODs genutzt werden. Einige der Components sind von UN/CEFACT standardisiert und aus der Core Component Library entnommen (CCL, vgl. [Row05, S. 37 ff.] und [UNE12]). Die Fields sind ausschließlich
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: Architektur der BODs nach OAGIS (vgl. [Ope11])
die elementarsten Bestandteile in OAGIS, wie zum Beispiel die Attribute description und name (vgl. [Ope11]).
Das Verb, das ebenfalls zum Datenteil eines BODs gehört, beschreibt die Geschäftsoperation,
die mit dem Business Objekt durchgeführt werden soll. Ein Beispiel für ein solches Verbist zum Beispiel Get, mit dem eine Liste von Daten (entsprechend des Nouns) angefordertwird. In einem Verb sind, im Gegensatz zum Noun, allerdings nur einige, wenige Attributedeklariert. Ein Beispiel für ein Attribut des Verbs Get ist zum Beispiel maxItems für diemaximale Anzahl der Datensätze, die zurückgeliefert werden sollen. Die Antwort auf dieseNachricht würde in diesem Fall mit dem Verb Show zurückgeliefert werden.
Durch die Kombination von Verb und Noun ergibt sich schließlich der Name des BODs. So ergibt zum Beispiel die Kombination des Verbs Get und dem Noun PurchaseOrder das BOD GetPurchaseOrder, welches mit dem BOD ShowPurchaseOrder beantwortet würde.
Ausgeliefert wird die Spezifikation von OAGi als Paket von XSD-Dateien. Jedes Noun ist dabei eine eigene XSD-Datei, die wiederum die fachlich benötigten Komponenten inkludiert. Auch vorgefertigte BODs sind in diesem Paket enthalten, also ausgewählte Kombinationen von Verbs und Nouns. Die Menge an XSD-Dateien sind nach fachlichen Bereichen modularisiert worden. So gibt es Components für verschiedenste Business-Bereiche wie zum Beispiel Finanzen (FinancialComponents.xsd) oder Logistik (LogisticsCompo- nents.xsd).
Die Nachrichten, die in Form eines BODs ausgetauscht werden, haben die Form eines XML-Dokuments. Diese Dokumente können unabhängig von den Transportprotokollen der Systeme ausgetauscht werden. Sie können zum Beispiel mit HTTP (RESTful) oder SMTP ausgetauscht werden, genauso gut aber auch in Webservice-basierte SOAP-Nachrichten gepackt werden.
Dieser Abschnitt sowie alle Unterabschnitte sind Ausz ü ge meiner Forschungs- und Entwicklungsarbeit (vgl. [ Bd12 ])
Unter Lightening und Flattening versteht man das Schmälern und Konsolidieren von XML- Schemadefinitionen. Das Lightening bezieht sich hierbei auf das Schmälern selbst. Hierbei kann eine gegebene XML-Schema-Struktur anhand einer vorgegebenen XML-Instanz auf die Elemente und Attribute der Instanz eingestampft werden. Dies ist in Abbildung 2.5 veranschaulicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5: Lightening von XML-Schemadefinitionen (vgl. [Kie12])
Durchgeführt wird das Lightening durch einen XSLT-Prozessor und einer entsprechenden XSL-Lightener Implementierung. Als Input bekommt der Prozessor die zu schmälernde XSD-Struktur sowie die XML-Instanz, zu der die neue XSD-Struktur generiert werden soll.
Als Output erhält man schließlich die neue XML-Schema Struktur, die nur die Elemente und Attribute enthält, die auch in der XML-Instanz vorhanden sind. Sinnvoll ist dies gerade
bei sehr mächtigen XML-Schemata, aus denen lediglich Teilmengen für den eigenen Bedarf benötigt werden. Dies kann zum Beispiel bei OAGIS der Fall sein, deren XSD-Strukturen sehr mächtig sind und für viele verschiedenen Einsatzvarianten ausgelegt sind (siehe Kapitel 2.4). Der Vorteil dieser Technik ist nicht nur, dass die Schemata kleiner und überschaubarer werden, sondern auch, dass XML-Instanzen der neuen XSD-Strukturen nach wie vor valide gegenüber den unberührten XSD-Strukturen sind.
Durch das sogenannte Flattening der Datenstrukturen kann eine modularisierte Struktur von vielen XSD-Dateien zu einer zusammengefassten Struktur umgewandelt werden. Dies wird in Abbildung 2.6 verdeutlicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.6: Flattening von XML-Schemadefinitionen (vgl. [Kie12])
Funktional wird jedes Inkludieren von Schemadateien aufgelöst und in die Schemadatei direkt eingefügt. Dadurch erhält man für jeden vorkommenden Namespace genau eine Schemadefinitionsdatei. Das Ziel dahinter ist, dass möglichst wenige Dateien verwaltet und veröffentlicht werden müssen, falls zum Beispiel ein Webservice bereitgestellt wird, der externe Schemadateien einbindet.
UN/EDIFACT (United Nations Electronic Data Interchange For Administration, Com- merce and Transport, vgl. [Uni11]) ist ein standardisiertes Datenformat für den Aus- tausch von einheitlichen Nachrichtentypen für Handelserleichterungen und elektronische Geschäftsprozesse. Die Standardisierung erfolgte durch die der vereinten Nationen (UN) zugehörige Einrichtung CEFACT (Centre for Trade Facilitation and Electronic Business, vgl. [Uni12a]). UN/EDIFACT ist einer der EDI-Standards für den elektronischen Datenaustausch. Der Grundgedanke hinter EDI (Electronic Data Interchange) ist der schnelle Austausch von Geschäftsdaten zwischen Informationssystemen von Unternehmen und Organisationen. Durch die Automatisierung des Nachrichtenaustauschs durch EDV-gestützte Systeme werden menschliche Fehler weitestgehend vermieden, da eingegangene Nachrichten nicht mehr manuell erfasst werden müssen, wie es bei Briefen, bei Fax und bei E-Mail der Fall ist.
2.6 UN/EDIFACT
Abbildung in dieser Leseprobe nicht enthalten
Quellcode 2.3: Aufbau einer UN/EDIFACT-Nachricht (vgl. [Uni12b])
Der EDI-Standard UN/EDIFACT wird fortlaufend erweitert und aktualisiert. Die Versionen
werden als Verzeichnis (engl. „ Directory “) angeboten, aus deren Namen der Erscheinungs-zeitpunkt ersichtlich ist. Ein Verzeichnis hat zum Beispiel den Namen D 09 B und liest sich wie „Verzeichnis aus dem Jahr 2009, zweites Release“. Der letzte Buchstabe ist fortlaufend und kennzeichnet die erschienene Version im angegebenen Jahr (vgl. [Uni10c]).
Eine Nachricht nach diesem Standard ist in unterschiedliche Segmente aufgeteilt. Jedes dieser Segmente ist durch eine eindeutige Kennzeichnung deklariert. In Listing 2.3 ist der generelle Aufbau dargestellt.
Die Segmente verhalten sich dabei wie Umschläge und kapseln somit einzelne Datenblöcke. So ist der äußerste Umschlag der sogenannte Interchange. Er beginnt mit einem Header und endet mit einem Trailer. Innerhalb dieses Umschlags gibt es optionale und erforderliche funktionale Gruppen. Darin wird die eigentliche Nachricht (Message) strukturiert gekapselt. Diese Nachricht kann wiederum nach Bedarf eigene Segmente enthalten. Zusätzlich zu diesen Umschlägen kann einer Nachricht optional der Bezeichner UNA beigefügt werden. Die damit angegebenen Zeichen legen fest, wie einzelne Segmente und Inhalte getrennt werden.
Ein Beispiel für eine Nachricht innerhalb einer UN/EDIFACT-Nachricht ist in Listing 2.4
zu sehen (Die Zeilenumbrüche dienen nur zur Verdeutlichung der Struktur). Hierbei wirdzu Beginn der Message Header mit UNH eingeleitet, gefolgt von den gewünschten Daten,die hier beispielhaft mit data angegeben sind. Das Trennzeichen „+“ separiert den Header-Deskriptor von den eigentlichen Daten. Den Abschluss eines Elements kennzeichnet dasApostroph „’“. Nach der Beschreibung des Headers folgen einige Beispiel-Segmente im UserData Segment-Bereich. Durch den Doppelpunkt mit der anschließenden Ziffer an einemBezeichner wird deklariert, ob es mehrere Vorkommen des Elements gibt. Diese werden danndurchnummeriert. So gibt es zwei BBB-Elemente, BBB:1 und BBB:2. Verschachtelte Elemente
Abbildung in dieser Leseprobe nicht enthalten
Quellcode 2.4: Beispiel UN/EDIFACT-Nachrichtsegment (vgl. [Uni12b])
können durch weitere Doppelpunkte mit dem angefügten Index des Vorgängers deklariert werden, zum Beispiel DDD:2:1 als erstes DDD-Kindelement des zweiten CCC-Elements.
In der UN/EDIFACT-Spezifikation sind vordefinierte Nachrichten für verschiedene An-wendungsfälle beschrieben. So gibt es Nachrichten, die für Rechnungsmitteilungen vor-definiert wurden, für Bestellungen, Lieferankündigungen und viele mehr. Aufgrund derVielfalt der unterschiedlichen Nachrichten wurden Teilmengen der Spezifikation für ver-schiedene Branchen eingeführt. Bekannte Vertreter der Teilmengen sind EANCOM für die Konsumgüterindustrie, EDIFICE für die High Tech Industrie sowie ODETTE für die Automobilindustrie.
Ein Enterprise Service Bus stellt ein Konzept in einer verteilten Softwareinfrastruktur und in einer Service-orientierten Architektur (SOA) dar. Er wird dazu verwendet, heterogene Anwendungen voneinander zu entkoppeln und dennoch die Kommunikation untereinander zu ermöglichen. Dabei gibt es unterschiedlichste Architekturmodelle, wie ein ESB aufgebaut ist und diverse höherwertige Funktionalitäten, die damit umgesetzt werden können. In den nächsten zwei Abschnitten werden Architekturunterschiede und Funktionalitäten näher erläutert.
ESBs können grundsätzlich unterschiedlich aufgebaut sein. Es gibt verschiedene Möglich- keiten Systeme anzubinden und Nachrichten zwischen diesen weiterzuleiten. Auch die Art, wie ein ESB in die Softwareinfrastruktur eingebunden wird, differiert von ESB zu ESB. Grundsätzlich ist der Enterprise Service Bus aber die Schnittstelle aller Applikationen in der definierten Anwendungslandschaft und wird auch Middleware genannt (siehe Abbildung 2.7).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.7: Ein ESB als Architekturkonzept
Die angekoppelten Anwendungen sind entweder Nutzer von Services (Client) oder sie sind selbst Anbieter von Services (Server). Die Kombination von Nutzen und Anbieten zur selben Zeit ist auch möglich. Der ESB ist eine komplexe Schicht, die Entscheidungen treffen kann und somit Einfluss auf die Kommunikation nimmt. Verschiedene ESB-Architekturen unterscheiden sich dabei in den internen Verarbeitungsweisen. Dazu gehört unter Anderem die Punkt-zu-Punkt Verbindung von Client und Server, die der ESB herstellt, oder die Vermittlung des Clients an einen Server durch spezifische Merkmale in der Nachricht (vgl.[Jos08, S. 67 f.]).
Bei der ersten Möglichkeit, der Punkt-zu-Punkt Anbindung, weiß der Client schon vor Beginn des Aufrufs, welcher Server für den Serviceaufruf genutzt wird. Der Client wendet sich mit der Adresse des Servers an den ESB, der wiederum die Verbindung aufbaut. Bei diesem Ansatz entsteht eine engere Kopplung zwischen diesen Systemen. Bei Serviceausfällen muss der Client selbst reagieren und einen entsprechend anderen Server auswählen. Auch wenn sich zum Beispiel die Adresse des Servers ändert, müssen alle Clients die Änderung vornehmen.
Die zweite Möglichkeit der Vermittlung ist eine losere gekoppelte Lösung. Der Client teilt dem ESB in seiner Nachricht mit, welchen Service er aufrufen möchte. Dies kann zum Beispiel durch einen einfachen Identifier realisiert werden. Anhand dessen kann der ESB den entsprechenden Server auswählen und die Nachricht weiterleiten. Auf diese Weise können auch höherwertige Funktionalitäten hinzugefügt werden (siehe nächsten Abschnitt), wie zum Beispiel ein Lastausgleich.
Weiterhin können sich ESBs dahingehend unterscheiden, ob sie Protokoll - oder aber API -
getrieben sind (vgl. [Jos08, S. 71 ff.]). Beim Protokoll-getriebenen Ansatz, wie es bei
Webservices der Fall ist, wird der ESB über ein festgelegtes Protokoll angesprochen (bei Webservices zum Beispiel HTTP(S)). Dies hat den Vorteil, dass, egal welches Betriebssystem oder welche Programmiersprache genutzt wird, nur das Protokoll implementiert worden sein muss. Bei technischen Änderungen an den gekoppelten Systemen oder auch am ESB selbst müssen jeweils bei den anderen Systeme keine Änderungen vorgenommen werden. Problematisch wird es allerdings, wenn sich durch technischen Fortschritt das Protokoll ändert und man vom neuen Protokoll profitieren möchte. In diesem Fall müsste an allen Stellen Hand angelegt werden.
Die Alternative wäre ein API-getriebener ESB. Dabei werden plattformspezifische Ei- genschaften im ESB verwendet. Ein Client kann dann zum Beispiel einen Service direkt über die Programmiersprache Java ansprechen. Dabei ergibt sich ein großer Unterschied im Entwicklungsprozess. Bei einem Protokoll-getriebenen Ansatz können die einzelnen Systeme unabhängig voneinander realisiert werden. Welche Frameworks, welche Program- miersprachen oder welches System allgemein genutzt wird, spielt dabei keine Rolle. Beim API-getriebenen Ansatz müssen sich hingegen die Entwickler untereinander absprechen, falls zum Beispiel neue Versionen eines Moduls eingeführt werden sollen (vgl. [Jos08, S.72]).
Ein ESB kann für verschiedenste Aufgaben in einer Softwarearchitektur eingesetzt werden. Hauptverantwortlich ist er für das Bereitstellen von Services, damit sie durch einen Nutzer aufgerufen werden können. Die Services selbst werden dabei aber meist nicht von dem ESB selbst implementiert sondern von einer anderen Instanz. Demzufolge wird der ESB ein Routing einleiten, um den eingegangenen Serviceaufruf zu dem eigentlichen Serviceanbieter weiterzuleiten. Auch für die Rückantwort muss dieser Mechanismus angewandt werden. Dieser Aspekt wird auch als Mediation (auf Deutsch: „ Vermittlung “) bezeichnet (vgl. [Jos08, S. 63 ff.]).
Die einfache Weiterleitung von Nachrichten kann mit einem ESB zu einem komplexen
Business Prozess ausgebaut werden. Durch das Koordinieren von mehreren Services (Orche-
strierung) können so zustandsbehaftete Geschäftsabläufe realisiert werden. Dies ist durch
eine Prozess Engine möglich, die an den ESB gekoppelt wird (vgl. [Cha04, S. 140 ff.]).
In der heutigen heterogenen IT-Landschaft ist es meist aber nicht ausreichend, Nachrichten ohne weitere Verarbeitung weiterzuleiten. Verschiedene Systeme verwenden unterschiedliche Nachrichtenformate. Der ESB kann dazu genutzt werden, die Nachrichten zwischen diesen Systemen zu übersetzen. Durch die Tranformation ist es somit möglich, Anwendungen zu koppeln, die sich direkt gekoppelt nicht verstehen würden. Ferner noch bekommen die Systeme von der Transformation gar nichts mit. Die Implementierung und Wartung ist entsprechend an eine andere Instanz übertragen worden. Dadurch, dass die Services zentral in einem ESB verwaltet werden, besteht die Möglichkeit, Datenverkehr zu überwachen und zu protokollieren. Das Monitoring erlaubt es, Engstellen in der Softwarearchitektur oder gar Fehlerquellen aufzuspüren.
Dies führt uns zu dem Punkt der Zuverl ä ssigkeit. Mit einem ESB können nicht durchführbare Serviceaufrufe eingereiht und zu einem späteren Zeitpunkt erneut ausgeführt werden. Eine angekoppelte Message Queue behält die Nachrichten dabei solange vor, bis ein Nachrichtenaufruf erfolgreich war. Durch die Zwischenspeicherung der Daten gehen keine Daten verloren und dies trägt somit zur Zuverlässigkeit bei. Aber auch Lastspitzen eines Services können durch redundante Services durch ein Load Balancing vermieden werden.
Der Client bekommt davon nichts mit.
Auch mit dem Aspekt der Sicherheit kann ein ESB umgehen. So können Datenverbindungen
verschlüsselt und der Zugriff durch eine Authentifizierung abgesichert werden (vgl. [Jos08, S. 63 ff.]).
Kapitel 3
Logistics Mall - Cloud-Computing für die Logistik
Die Fraunhofer Institute für Software- und Systemtechnik (ISST) und für Materialfluss und Logistik (IML) forschen an einer Cloud-Computing Infrastruktur für logistische Dienste, die den Namen Logistics Mall trägt (vgl. [Fra12]). Ziel ist es, kleinen und mittleren Unternehmen (KMU) den Einkauf und die Pflege von komplexen Informationssystemen zu ersparen. Viel mehr soll es ihnen gestattet sein, für sie angepasste Logistikprozesse einzukaufen, ohne mit technischen Aspekten in Kontakt zu treten. Abgerechnet wird auf Basis der realen Nutzung.
Im folgenden Abschnitt wird die Logistics Mall näher erläutert, also welche Konzepte
dahinter stecken, wer daran beteiligt ist und wie ein Beispielprozess aussehen könnte.
Anschließend werden die Anforderungen an einen ESB für die Mall beschrieben, die sich daraus ergeben, dass die Mall bei einem externen Betreiber ausgeführt wird.
Es gibt fünf Akteure im Konzept der Mall. Als Hauptakteur ist der Logistik-Kunde anzuse- hen, der in aller Regel ein KMU ist, das nicht die Ressourcen hat, große Informationssysteme einzukaufen, zu installieren und allgemein zu betreiben. Viel mehr benötigt das Unterneh- men eine einfache logistische Abarbeitung von immer wiederkehrenden Aufträgen. Genau an diesem Punkt greift schließlich die Logistics Mall mit dem Cloud-Computing Ansatz, sodass es dem Logistik-Kunden möglich ist, ein genau für ihn angepasstes Logistik-Produkt oder gar einen ganzen Logistik-Prozess einzukaufen. Das können sowohl einzelne Systeme sein, als auch mehrere kombinierte Systeme für komplexe Abläufe.
Ein Logistik-Prozess ist eine Verkettung von Einzelprodukten, die nacheinander ausgeführt werden. Das könnte zum Beispiel eine Auftragserfassung, eine Kommissionierung oder aber auch der Transport von einer Ware sein. Diese Produkte beziehungsweise Dienste müssen von einem weiteren Akteur, hier der Logistik-Dienstleister, angeboten und der Logistics Mall bereitgestellt werden.
Damit diese von den Dienstleistern angebotenen Produkte der Mall im technischen Sinne zur Verfügung stehen, also der Kunde diese im Marketplace der Mall auswählen kann, gibt es den IT-Dienste-Entwickler. Durch bereitgestellte Werkzeuge kann dieser ohne große Umwege neue Prozesse einfügen. Die Verkettung von Diensten zu einem ausführbaren Gesamtprozess kann durch den vierten Akteur, dem Logistikprozess-Designer, durchgeführt werden. Auch ihm werden dazu spezielle Werkzeuge bereitgestellt.
Der sich im Hintergrund befindliche fünfte Akteur ist schließlich für den Betrieb der
Plattform zuständig. Er sorgt dafür, dass die Mall stets verfügbar ist und stellt somit die Hardware und Bandbreite zur Verfügung. Anhand des Gebrauchs der Anwendungen, Services und Prozessen stellt dieser auch den tatsächlichen Verbrauch den Kunden in Rechnung.
In Abbildung 3.1 ist dieses Gesamtkonzept veranschaulicht.
Abbildung in dieser Leseprobe nicht enthalten
Es wird ein Enterprise Service Bus gesucht, der für die Softwareinfrastruktur der Logistics Mall am geeignetsten ist. Dabei spielen nicht nur technische Aspekte eine Rolle, sondern vor allem auch Aspekte der Usability. Der Betrieb dieser Cloud-Computing Lösung wird von einem externen Betreiber geleistet. Aufgrund dieser Tatsache ergeben sich spezielle Anforderungen.
Die Mitarbeiter des Betreibers sind Administratoren von Computersystemen innerhalb eines Rechenzentrums. Es kann daher nicht davon ausgegangen werden, dass Kenntnisse in
Softwarearchitektur und -entwicklung vorhanden sind. Zu den Aufgaben dieser Mitarbeiter im Betrieb der Logistics Mall gehört unter anderem aber die Einbindung von neuen Anwendungen, sowie die Installation und Konfiguration von Routen zwischen den neuen und vorhandenen Anwendungen. Dementsprechend ist es wichtig, dass der ESB komfortabel
bedient werden kann. Eine übersichtlich und intuitiv gestaltete Oberfläche stellt somit eine wichtige Anforderung dar, die bei der Auswahl berücksichtigt werden muss.
Abbildung 3.1: Idee der Logistics Mall, Grafik: Fraunhofer ISST
Abbildung in dieser Leseprobe nicht enthalten
Es gibt aber auch weitere Anforderungen an den ESB, die unbedingt eingehalten werden müssen. Drei von diesen Anforderungen, die leicht ermittelt werden können, sind Grundlage für die erste Auswahl von Produkten aus dem Markt. Nur die ESBs, die diese Kriterien erfüllen, werden in dieser Arbeit näher untersucht.
1. Das erste Pflichtkriterium ist, dass das Produkt einer freien Lizenz unterliegen muss und somit kostenlos kommerziell eingesetzt werden kann. Dadurch sind die initialen Anschaffungskosten für das Projekt deutlich geringer. Weitere Vorteile sind die Einsichtnahme in den Source Code, um Probleme besser ermitteln zu können oder um Abläufe besser verstehen zu können. Je nach Lizenzmodell sind auch eigene Anpassungen möglich.
2. Das zweite Pflichtkriterium ist, dass der ESB mindestens mit der Programmiersprache Java arbeitet, das heißt, dass wenn eigene Erweiterungen oder Komponenten entwickelt werden, keine andere höhere Programmiersprache verwendet werden muss. Dies liegt darin begründet, dass die Logistics Mall auf Java-Technologie basiert.
3. Das dritte Pflichtkriterium an den ESB ist, dass die ausführbare Version auf einem Linux/Unix Betriebssystem lauffähig sein muss. So ist sichergestellt, dass auch bei hoch performanten Serversystemen des externen Betreibers der Bus eingesetzt werden kann.
Es gibt noch viele weitere Anforderungen und Kriterien an einem ESB. Diese müssen jedoch für jedes Produkt detaillierter betrachtet werden. Diese Arbeit ist in zwei Teile untergliedert, dem Vergleich anhand der Herstellerangaben (Recherche) und dem anschlie- ßenden praktischen Vergleich. In den jeweiligen Kapiteln werden weitere Anforderungen und Kriterien für beide Vergleiche erläutert und die ESBs danach untersucht. Es sei jedoch anzumerken, dass in dieser Arbeit nicht alle möglichen Kriterien untersucht werden können. Wichtige Eigenschaften wie zum Beispiel Performanz, Skalierbarkeit und Sicherheit spielen in dieser Untersuchung keine Rolle, da das Hauptaugenmerk aus Auf- wandsgründen auf die Usability der ESBs gelegt wird, sowie auf die Nutzbarkeit in Logistics Mall nahen Szenarien.
Kapitel 4
Marktübersicht
In diesem Kapitel werden die ESBs kurz vorgestellt, die in der Evaluation dieser Arbeit untersucht werden. Bei der initialen Auswahl dieser ESBs wurden Pflichtkriterien, die unbedingt zu erfüllen sind, berücksichtigt: ein Java Stack, eine Open Source Lizenz sowie die Verfügbarkeit des Servers für das Unix/Linux Betriebssystem.
In Tabelle 4.1 im Abschnitt 4.2 sind Kenndaten über die zu untersuchenden ESBs dar-
gestellt. Dazu gehören Produktname und Name des kommerziellen Produkts. So gibt es Unternehmen, die gänzlich Open Source getriebene Produkte, die durch die Community ent- wickelt werden, unter einem anderen Namen kommerziell unterstützen und entsprechende Service Modelle anbieten. In diesem Fall werden beide Produktnamen als Spaltenüberschrift angegeben.
Ein weitere Möglichkeit ist, dass ein Unternehmen das Produkt zum einen kostenlos und zum anderen kommerziell zur Verfügung stellt. In diesem Fall wird nur der Produktname des kostenlosen ESBs in die Spaltenüberschrift übernommen. Der kommerzielle Produktname wird dann explizit angegeben. Viele der ESBs basieren auf bekannte Frameworks. Es gibt auch ESBs, die sich andere ESBs zunutze machen und ausbauen. In der Tabelle werden unter Basisframeworks die jeweiligen Abhängigkeiten aufgelistet.
Des Weiteren ist die Version angegeben, die das Produkt zum Zeitpunkt dieser Untersuchung hat (Stand Juni 2012) sowie das jeweilige Lizenzmodell. Im Grundlagenkapitel 2.2 wird ein kurzer Überblick über die hier vorkommenden Lizenzen gegeben.
Im folgenden Abschnitt werden die einzelnen ESBs und deren Besonderheiten kurz be- schrieben.
[...]
