Anwenderunabhängige Flugdatenschnittstelle basierend auf Web Services am Beispiel der Flughafen München GmbH

MA-Thesis / Master von Andreas Waltl

Einleitung:

1, Einführung in die Thematik:

Der Hype um Service-orientierte Architekturen (SOA) und Web Services ist längst vorüber. Mittlerweile gibt es sogar IT-Experten und Analysten wie Anne Thomas Manes von der Burton Group, die in ihrem Blog-Eintrag SOA bereits für tot erklärt hat, weil viele SOA-Projekte in der Vergangenheit gescheitert oder zumindest nicht erfolgreich gewesen sind. Des Weiteren wird von Kritikern zu Recht angeführt, dass die an SOA gestellten Erwartungen, wie zum Beispiel die Senkung der IT-Kosten, die Wiederverwendbarkeit von Services oder die Agilität, oftmals nicht erfüllt werden. Dass SOA damit bereits am Ende sei, wird aber von mehreren IT-Verantwortlichen bezweifelt. Untermauert wird dies auch durch den SOA Check 2009 der Technischen Universität Darmstadt. 84% der befragten Unternehmen geben an, dass SOA in ihrem Unternehmen bereits eingesetzt wird (47%) oder aber der Einsatz geplant ist (37%).

(an dieser Stelle erscheint im Original eine Abbildung).

Auch im IT Hype Cycle, in dem das Forschungsinstitut Gartner jährlich die IT-Trends einordnet, wird deutlich, dass sowohl der Hype um SOA als auch das Tal der Ernüchterung vorüber ist. Im Hype Cycle 2008 und 2009 befindet sich SOA auf dem Weg der Erkenntnis. Nach etwa zwei bis fünf Jahren ist laut Gartner mit einer produktiven Nutzung zu rechnen.

Im SOA-Umfeld haben sich Web Services als häufigste Umsetzungstechnik einer SOA durchgesetzt (BSI 2009). Im IT Hype Cycle 2008 werden Web Services dem Plateau der Produktivität zugeordnet und werden sich in weniger als zwei Jahren in den Unternehmen etabliert haben. Die theoretischen Grundlagen und Basistechnologien für Web Services existieren schon seit geraumer Zeit auf dem Markt – beispielsweise wurde das SOAP Protokoll vom World Wide Web Consortium zum ersten Mal im Jahre 2000 spezifiziert (W3C 2004a). Nichtsdestotrotz war bzw. ist der produktive Einsatz von Web Services in Unternehmen teilweise noch bis heute umstritten. In erster Linie bemängeln Kritiker fehlende Sicherheitsfunktionen sowie mangelnde Leistung gegenüber vergleichbaren Techniken wie CORBA, DCOM oder Java RMI. In den letzten Jahren hat sich aber vor allem im Bereich Web Services Sicherheit einiges getan. Aus diesem Grund wird im theoretischen Teil dieser Arbeit den Themen Sicherheit und Leistung jeweils ein eigenes Kapitel gewidmet. Zu den großen Stärken von Web Services zählen die Plattformunabhängigkeit, die offenen Standards auf denen Web Services basieren sowie die relativ einfache Bereitstellung und Nutzung von Web Services.

Diese Master’s Thesis wird in Zusammenarbeit mit der Flughafen München GmbH (FMG) erstellt. Die FMG prüft derzeit, ob und wie Web Services in ihrer bestehenden IT-Landschaft am besten eingesetzt werden können, um damit im ersten Schritt externe Partner anzubinden. Dabei sind die Anforderungen in Bezug auf Sicherheit, Verfügbarkeit und Leistung überdurchschnittlich. Die IT-Architektur der FMG basiert auf einer CORBA Middlewareinfrastruktur, die in Kapitel 3 näher vorgestellt wird.

Im Rahmen dieser Arbeit soll eine Lösung konzeptioniert und implementiert werden, um externen Partnern der FMG (z.B. Abfertiger, Airlines, Medien) eine Web Service Schnittstelle zur Verfügung stellen zu können, auf deren Basis Flugdaten abgerufen werden können. Des Weiteren soll mithilfe der implementierten Lösung eine real existierende Schnittstelle auf Basis von Web Services umgesetzt werden, um die Praxistauglichkeit der Implementierung zu beweisen.

1.1, Ausgangssituation:

Fast alle großen Unternehmen hatten oder haben immer noch mit einer sehr heterogenen Softwarelandschaft zu kämpfen, die historisch gewachsen ist. Früher war es üblich für jeden Funktionsbereich (z.B. Einkauf, Verkauf, Produktion) speziell auf diese Bereiche zugeschnittene Applikationen zu entwickeln ohne dabei unbedingt auf Interoperabilität mit anderen Applikationen zu achten. Um den Datenaustausch zwischen diesen Applikationen dennoch zu ermöglichen, wurde häufig eine Unzahl von Schnittstellen zwischen diesen Applikationen manuell entwickelt (Point to Point Integration), die im Laufe der Zeit aufgrund der Anzahl und Spezifität nicht mehr beherrschbar waren.

Wenn man sich mit der Lösung dieses Problems auseinandersetzt, stößt man unweigerlich auf das Schlagwort Enterprise Application Integration (EAI). Es existieren zahlreiche, unterschiedliche Definitionen zu diesem Begriff – exemplarisch sei hier eine Definition aufgeführt:

‘Die Kernidee der Enterprise Application Integration (EAI) ist es, eine zentrale Plattform bereitzustellen, welche Applikationen über entsprechende, zum Teil vorgefertigte Adapter anbindet.’ Die Umsetzung einer EAI erfordert sowohl eine technische Integration als auch eine organisatorische/soziale Integration, wobei beides unternehmensintern oder unternehmensübergreifend betrachtet werden kann.

Für die technische Integration setzt man häufig eine Middleware (z.B. CORBA) ein, sodass jede Applikation nur noch eine Schnittstelle bzw. Adapter zur Middleware implementieren muss. Die Kommunikation zwischen Applikationen geschieht dann über die eingesetzte Middleware.

‘Middleware is connectivity software that is designed to help manage the complexity and heterogeneity inherent in distributed systems by building a bridge between different systems thereby enabling communication and transfer of data. Middleware could be defined as a layer of enabling software services that allow application elements to interoperate across network links, despite differences in underlying communications protocols, system architectures, operating systems, databases, and other application services.’ Da die übermittelten Daten häufig in Form von Nachrichten ausgetauscht werden, spricht man in diesem Zusammenhang von Message-oriented Middleware (MOM). Diejenige Komponente, die zwischen zwei Diensten einen virtuellen Kommunikationskanal (eventuell über Unternehmensgrenzen hinweg) aufbaut, bezeichnet man meist als Message Broker. Der Datenstrom wird in Unternehmen, wie dies auch bei der FMG der Fall ist, häufig von Ereignissen gesteuert, deshalb spricht man von Event-driven Enterprises.

Ein Enterprise-Service-Bus (ESB) bildet die zentrale Integrationseinheit der EAI und stellt die gleiche Funktionalität wie eine Message-oriented Middleware zur Verfügung. Sie bietet jedoch in aller Regel darüber hinaus noch einige Zusatzfunktionen wie Datentransformation (z.B. Datentypen unterschiedlicher Programmiersprachen), Protokollunabhängigkeit, Intelligentes Routing, Implementierung der SOA-Standards sowie im Gegensatz zu einigen Middleware Lösungen die Einfachheit der Anbindung und Benutzung an.

Eine Service-orientierte Architektur (SOA) ist eine (strenge) Form einer EAI:

‘Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene 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.’ Damit geht SOA noch weiter als EAI und fordert das Sevice-Paradigma. Das bedeutet, dass es in einer SOA streng genommen keine Applikationen als solche mehr gibt, da die IT Landschaft in Dienste und Prozesse, die die angebotenen Dienste nutzen, ‘zerfällt’.

Wie bereits erwähnt wurde, stellen Web Services eine Möglichkeit dar, eine SOA umzusetzen. Web Services werden ausführlich in Kapitel 4 dieser Arbeit behandelt.

Inhaltsverzeichnis:

	Vorwort	III
	Zusammenfassung	IV
	Abbildungsverzeichnis	VIII
	Tabellenverzeichnis	X
	Abkürzungsverzeichnis	XI
1.	Einführung in die Thematik	1
1.1	Ausgangssituation	2
1.2	Kurzvorstellung der Flughafen München GmbH	4
1.3	Problemstellung	8
1.4	Ziele und Aufbau der Arbeit	9
2.	Anforderungsermittlung	11
2.1	Akteure	12
2.2	Szenarien	13
2.3	Anwendungsfälle	13
2.4	Funktionale Anforderungen	21
2.5	Nichtfunktionale Anforderungen	23
3.	FMG Middlewareinfrastruktur	25
3.1	Anforderungen an die Verkehrssysteme der FMG	25
3.2	Historische Entwicklung der FMG Middlewareinfrastruktur	26
3.3	CORBA	27
3.4	CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur	30
3.5	Abgleich der SOA-Merkmale in der FMG-Middlewareinfrastruktur	33
4.	Web Services Grundlagen	35
4.1	Definition	35
4.2	Anwendungsgebiete	36
4.2.1	Web Services als RPC	37
4.2.2	Web Services als Umsetzung einer SOA	40
4.3	Web Services Architektur	40
4.4	Basistechnologien und Spezifikationen	44
4.4.1	XML	44
4.4.2	SOAP	47
4.4.3	WSDL	51
4.4.4	UDDI	55
4.4.5	Geschäftsprozessmodellierung: WS-BPEL und WS-CDL	56
4.4.6	WS-*	58
4.4.7	REST	63
4.5	Sicherheitsaspekte von Web Services	67
4.5.1	Sicherheitsprobleme beim Einsatz von Web Services	69
4.5.2	WS-Security	71
4.5.3	Web Service Firewall	75
4.6	Leistungsaspekte von Web Services	77
4.6.1	Einflussfaktoren auf die Leistung von Web Services	77
4.6.2	Leistungsvergleich: SOAP Web Services vs. CORBA	78
5.	Konzeption und Implementierung der FMG Web Service Schnittstelle	83
5.1	Ziele der FMG Web Service Schnittstelle	83
5.2	Software Product Line Engineering	83
5.2.1	Domain Engineering	84
5.2.2	Application Engineering	85
5.2.3	Software Product Lines bei der FMG Web Service Schnittstelle	86
5.3	Analyse	88
5.3.1	Objektmodell	88
5.3.2	Dynamisches Modell	90
5.4	Systementwurf	92
5.4.1	Integration in die FMG Softwarelandschaft	92
5.4.2	Kommunikationsmodelle	96
5.4.3	Entwurfsziele	98
5.4.4	Systemzerlegung	99
5.4.5	Realisierung der Entwurfsziele	110
5.4.6	Abbildung der Subsysteme auf Hardware und Software	110
5.4.7	Identifizierung und Speicherung von persistenten Daten	113
5.4.8	Einrichtung von Zugriffsrechten	114
5.4.9	Entwurf des globalen Kontrollflusses	114
5.4.10	Identifizierung von Randbedingungen	116
5.5	Objektentwurf	118
5.5.1	Objektmodell der Web Service Konfiguration	118
5.5.2	Objektmodell der Web Service Domain	120
5.6	Implementierung	131
5.7	Reales Beispiel: Skytanking Flugdatenschnittstelle	132
5.7.1	Beschreibung der Schnittstelle	132
5.7.2	Umsetzung	135
5.7.3	Leistungstest	139
6.	Ergebnisse der Arbeit	143
6.1	Ergebnisse von allgemeinem Interesse	143
6.2	Ergebnisse von speziellem Interesse seitens der FMG	149
7.	Abschließende Betrachtung und Ausblick	153
	Literaturverzeichnis	155
	Anhang	165
Anhang A	Glossar	166
Anhang B	XML und XML Schema Details	167
Anhang C	UDDI Datenmodell und API	173
Anhang D	WS-* Spezifikationen: WS-Addressing und WS-Notification	177
Anhang E	XML-Signature, XML-Encryption, SAML, XACML	183

Textprobe:

Kapitel 4.4, Basistechnologien und Spezifikationen:

Die Anforderung /RQ18/ fordert den Einsatz von offenen und weit verbreiteten Standards. Aus diesem Grund werden in diesem Abschnitt die relevanten Basistechnologien und Spezifikationen, die in Zusammenhang mit Web Services stehen, näher erläutert.

4.4.1, XML:

Die eXtensible Markup Language (XML) ging aus SGML hervor und hat sich als Auszeichnungssprache für den elektronischen Datenaustausch über Netzwerke (v.a. das Internet) etabliert. Die erste Spezifikation mit Empfehlungsstatus dieser Sprache stammt aus dem Jahre 1998. Mittlerweile liegt XML in der fünften Ausgabe vom 26. November 2008 vor. Zu den wichtigsten Entwurfszielen von XML zählen:

XML soll unkompliziert im Internet verwendet werden können.

XML soll ein breites Spektrum von Anwendungen unterstützen.

XML soll zu SGML kompatibel sein.

Es soll einfach sein, Programme zu schreiben, die XML Dokumente verarbeiten.

XML-Dokumente sollen für Menschen lesbar und angemessen verständlich sein.

Der Entwurf von XML soll formal und präzise sein.

XML-Dokumente sollen einfach zu erstellen sein.

Die Knappheit von XML-Markup ist von minimaler Bedeutung.

Aus diesen Entwurfszielen ergibt sich, dass XML Dokumente von Mensch und Maschinen gleichermaßen gut lesbar bzw. verarbeitbar sein sollen. Demnach können XML Dokumente keine binären Daten enthalten, sondern bestehen aus reinem Text mit einer eindeutigen Kodierung. Ein Kritikpunkt, der bei XML immer wieder angeführt wird, ist die ‘Gesprächigkeit’ von XML, sodass die Größe von XML-Dokumenten recht groß gegenüber binären Dateien ist, die die gleiche Information transportieren. Der Grund für diese ‘Gesprächigkeit’ ist auch in den Entwurfszielen zu finden. Lesbarkeit und Verständlichkeit sind demnach wichtiger als die Knappheit. Durch Kompression gibt es aber dennoch Möglichkeiten ein XML-Dokument teilweise drastisch zu verkleinern, sodass die Netzwerklast mitunter deutlich schrumpft, da sich XML-Dokumente aufgrund vieler Wiederholungen im Text (z.B. bei Tags) in der Regel sehr gut komprimieren lassen.

Für den Erfolg von XML sind mehrere Eigenschaften der Sprache verantwortlich:

Einfachheit (im Gegensatz zur relativ komplexen SGML).

Erweiterbarkeit (Verwendung beliebiger Tags zur semantischen Auszeichnung).

Validierbarkeit (Überprüfung von XML-Dokumenten auf Einhaltung des Schemas).

Verschachtelung (Abbildung hoch komplexer Hierarchien jeder Art möglich).

Offener Standard (Freie Verwendbarkeit, Standardisierung durch W3C).

XML ist aber nicht nur eine reine Auszeichnungssprache für den Datenaustausch. XML fungiert darüber hinaus auch als Metasprache für eine ganze Reihe von Sprachen, deren Syntax auf XML basiert. Dazu wird der jeweilige Befehlssatz in Tags abgebildet. Bekannte Beispiele aus verschiedenen Themengebieten für XML-basierende Sprachen sind:

Semantic Web: RDF, OWL, Topic Maps.

Web Services: SOAP, WSDL, WS-BPEL.

Sonstige: XHTML, MathML, SVG, RSS.

Im Folgenden wird davon ausgegangen, dass XML-Tags, XML-Elemente und XML-Attribute sowie der grundsätzliche Aufbau eines XML-Dokuments bekannt sind. Eine Erklärung dieser Begriffe findet sich im Anhang unter B.1 und B.2.

XML-Fachbegriffe:

Nachfolgend werden die wichtigsten XML-Fachbegriffe erläutert.

Wohlgeformtheit:

Ein XML-Dokument heißt wohlgeformt (engl. well-formed), wenn es alle folgenden XML-Regeln erfüllt:

Vor der XML-Deklaration dürfen keine Leerzeichen verwendet werden.

Jedes XML-Dokument muss genau ein Wurzelelement enthalten, das alle anderen Elemente beinhaltet.

Jedes Element muss über einen Start-Tag und End-Tag verfügen.

Es dürfen sich keine Tags überlappen, wie das im folgenden Beispiel fehlerhaft dargestellt ist:

Es wird zwischen Groß- und Kleinschreibung unterschieden. Dies bedeutet, dass Start- und End-Tag exakt gleich geschrieben werden müssen.

Die Namensgebung von Elementen und Attributen muss den entsprechenden Regeln folgen.

Attribute dürfen nur in einem Start-Tag vorkommen und müssen eindeutig sein.

Gültigkeit:

Wenn ein XML-Dokument wohlgeformt ist, heißt das noch lange nicht, dass es auch gültig (engl. valid) ist. Während Wohlgeformtheit nur ausdrückt, dass ein XML-Dokument äußerlich syntaktisch korrekt ist, können bei der Prüfung auf Gültigkeit eines XML-Dokuments wesentlich strengere Regeln validiert werden. Ein XML-Dokument heißt gültig, wenn es ein vorgegebenes Schema (z.B. DTD oder XML-Schema) erfüllt. Bevor ein XML-Dokument auf Gültigkeit überprüft wird, muss es die Prüfung der Wohlgeformtheit bestanden haben.

Mithilfe einer Schemadefinition kann beispielsweise beschrieben werden, welche Elemente ein XML-Dokument enthalten muss bzw. kann, wie die Verschachtelung dieser Elemente auszusehen hat und welche Attribute in bestimmten Elementen verwendet werden dürfen.

Auch wenn ein XML-Dokument wohlgeformt und gültig ist, muss es noch nicht richtig sein. Wenn ein Schema beispielsweise vorgibt, dass eine Adresse mit Straße, PLZ und Ort eingegeben werden muss, dann prüft die Gültigkeitsprüfung zwar ob diese Elemente existieren und ob der jeweilige Datentyp korrekt ist, jedoch kann dennoch eine falsche Adresse eingegeben werden, die dem Schema zwar entspricht, aber in der Realität nicht existiert.

XML-Prozessor:

Ein XML-Prozessor (oft auch XML-Parser genannt) ist eine Software, die XML-Dokumente lesen und verarbeiten kann. Insbesondere wird der Zugriff auf Inhalt und Struktur unterstützt. Ein XML-Prozessor arbeitet in der Regel innerhalb einer Anwendung, die XML-Dokumente verarbeiten muss (z.B. Webbrowser). Man unterscheidet zwischen validierenden und nicht-validierenden Parsern. Validierende Parser können ein XML-Dokument auf die Einhaltung der Regeln einer DTD oder eines XML-Schemas prüfen. Des Weiteren unterscheidet man zusätzlich zwischen SAX- und DOM-Parsern. SAX-Parser durchlaufen das XML-Dokument einmal und erzeugen dabei Ereignisse, für die Callback-Funktionen registriert werden können und die dann entsprechend aufgerufen werden (Push Modell). Dagegen bildet ein DOM-Parser das XML-Dokument als Baumstruktur im Speicher ab und bietet entsprechende Methoden an, um auf Elemente und/oder Attribute des Baums zugreifen oder sie manipulieren zu können. Während beim SAX-Parser nach einem Durchlauf das XML-Dokument nicht mehr zur Verfügung steht, bleibt das Dokument beim DOM-Parser im Speicher erhalten. Dadurch kann der Baum auch nachträglich noch beliebig ausgelesen bzw. manipuliert werden. Dies führt jedoch zu erhöhtem Speicherbedarf (v.a. bei großen XML-Dokumenten) im Vergleich zu SAX-Parsern. Zudem sind SAX-Parser in aller Regel schneller als DOM-Parser. Mit StAX existiert darüber hinaus noch eine API, die einen Mittelweg zwischen SAX und DOM beschreitet. Wie bei SAX wird ein XML-Dokument durchlaufen, allerdings hat im Gegensatz zu SAX nicht der Parser sondern die Anwendung die Kontrolle. Sie fordert weitere Daten über einen Iterator aktiv an (Pull Modell).

XML-Schema:

Für die Beschreibung von Strukturen und Regeln eines XML-Dokuments (ähnlich einer Grammatik, in der Regeln definiert sind, mit denen zwischen gültigen und ungültigen Sätzen unterschieden werden kann) werden Schemasprachen eingesetzt. Wird einem XML-Dokument ein Schema hinzugefügt, dem es folgen soll, so kann die Gültigkeit dieses XML-Dokuments mit validierenden XML-Prozessoren überprüft werden. Zur Beschreibung eines Schemas haben sich in den Anfangsjahren von XML die Dokument-Typdefinitionen (DTDs) durchgesetzt, die noch bis heute in vielen Fällen eingesetzt werden. Allerdings ist die Mächtigkeit von DTDs zur Beschreibung eines Schemas begrenzt (z.B. unzureichende Unterstützung von Datentypen oder Wertebereichen). Des Weiteren folgen DTDs nicht der XML-Syntax, sodass beispielsweise ein Zugriff über DOM nicht möglich ist. Da sich XML für den Datenaustausch im B2B-Bereich etabliert hat, musste für diese Probleme eine Lösung gefunden werden, die allerdings über drei Jahre nach der ersten Spezifikation von XML mit Empfehlungsstatus auf sich warten ließ. Am 2. Mai 2001 veröffentlichte das W3C schließlich die erste Spezifikation von XML-Schema mit Empfehlungsstatus, welche die Defizite von DTDs adressierte.

XML-Schema ist aber nicht nur für die Schemadefinition beim Datenaustausch nützlich - praktisch alle XML-basierten Sprachen stellen für den erlaubten Sprachumfang ein passendes XML-Schema zur Verfügung, so auch die für Web Services wichtigen Technologien SOAP, WSDL und BPEL. Details zu XML Schema können im Anhang B.3 nachgelesen werden.