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

Inhaltsverzeichnis

Vorwort

Zusammenfassung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einführung in die Thematik
1.1 Ausgangssituation
1.2 Kurzvorstellung der Flughafen München GmbH
1.3 Problemstellung
1.4 Ziele und Aufbau der Arbeit

2 Anforderungsermittlung
2.1 Akteure
2.2 Szenarien
2.3 Anwendungsfälle
2.4 Funktionale Anforderungen
2.5 Nichtfunktionale Anforderungen

3 FMG Middlewareinfrastruktur
3.1 Anforderungen an die Verkehrssysteme der FMG
3.2 Historische Entwicklung der FMG Middlewareinfrastruktur
3.3 CORBA
3.4 CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur
3.5 Abgleich der SOA-Merkmale in der FMG-Middlewareinfrastruktur

4 Web Services Grundlagen
4.1 Definition
4.2 Anwendungsgebiete
4.2.1 Web Services als RPC
4.2.2 Web Services als Umsetzung einer SOA
4.3 Web Services Architektur
4.4 Basistechnologien und Spezifikationen
4.4.1 XML
4.4.2 SOAP
4.4.3 WSDL
4.4.4 UDDI
4.4.5 Geschäftsprozessmodellierung: WS-BPEL und WS-CDL
4.4.6 WS-*
4.4.7 REST
4.5 Sicherheitsaspekte von Web Services
4.5.1 Sicherheitsprobleme beim Einsatz von Web Services
4.5.2 WS-Security
4.5.3 Web Service Firewall
4.6 Leistungsaspekte von Web Services
4.6.1 Einflussfaktoren auf die Leistung von Web Services
4.6.2 Leistungsvergleich: SOAP Web Services vs. CORBA

5 Konzeption und Implementierung der FMG Web Service Schnittstelle
5.1 Ziele der FMG Web Service Schnittstelle
5.2 Software Product Line Engineering
5.2.1 Domain Engineering
5.2.2 Application Engineering
5.2.3 Software Product Lines bei der FMG Web Service Schnittstelle
5.3 Analyse
5.3.1 Objektmodell
5.3.2 Dynamisches Modell
5.4 Systementwurf
5.4.1 Integration in die FMG Softwarelandschaft
5.4.2 Kommunikationsmodelle
5.4.3 Entwurfsziele
5.4.4 Systemzerlegung
5.4.5 Realisierung der Entwurfsziele
5.4.6 Abbildung der Subsysteme auf Hardware und Software
5.4.7 Identifizierung und Speicherung von persistenten Daten
5.4.8 Einrichtung von Zugriffsrechten
5.4.9 Entwurf des globalen Kontrollflusses
5.4.10 Identifizierung von Randbedingungen
5.5 Objektentwurf
5.5.1 Objektmodell der Web Service Konfiguration
5.5.2 Objektmodell der Web Service Domain
5.6 Implementierung
5.7 Reales Beispiel: Skytanking Flugdatenschnittstelle
5.7.1 Beschreibung der Schnittstelle
5.7.2 Umsetzung
5.7.3 Leistungstest

6 Ergebnisse der Arbeit
6.1 Ergebnisse von allgemeinem Interesse
6.2 Ergebnisse von speziellem Interesse seitens der FMG

7 Abschließende Betrachtung und Ausblick

Literaturverzeichnis

Anhang
Anhang A Glossar
Anhang B XML und XML Schema Details
Anhang C UDDI Datenmodell und API
Anhang D WS-* Spezifikationen: WS-Addressing und WS-Notification
Anhang E XML-Signature, XML-Encryption, SAML, XACML

Abbildungsverzeichnis

Abbildung 1: Gartner IT Hype Cycle 2008

Abbildung 2: Flughafen München - Franz Joseph Strauß - Luftbild

Abbildung 3: Fluggastaufkommen im gewerblichen Luftverkehr 1999-2008

Abbildung 4: Flugbewegungen gesamt 1999-2008

Abbildung 5: FMG Web Service Schnittstelle – Anwendungsfalldiagramm

Abbildung 6: Informationsdrehscheibe Flughafen

Abbildung 7: Technische Grundidee von CORBA

Abbildung 8: CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur

Abbildung 9: MTM Produktübersicht: Audi A5 3,0 TDI 176 kW (240PS) Quattro

Abbildung 10: Sperrer Produktübersicht: Audi A5 3,0 TDI 176 kW (240PS) Quattro

Abbildung 11: Web Services Dreieck

Abbildung 12: Web Services Stack

Abbildung 13: SOAP Aufbau

Abbildung 14: Beispiel einer SOAP-Nachricht (Fluganfrage)

Abbildung 15: Beispiele einer SOAP Fehler Nachricht

Abbildung 16: Beispiel einer WSDL 2.0 -Beschreibung für einen Flugdatenservice

Abbildung 17: WSDL 1.1 vs. WSDL 2.0

Abbildung 18: Beispiel einer WS-ReliableMessaging Nachricht

Abbildung 19: Beispiel einer WS-ReliableMessaging Bestätigung

Abbildung 20: Beispielablauf einer WS-ReliableMessaging Kommunikation

Abbildung 21: Beispiel eines GET-Requests einer REST-Ressource

Abbildung 22: Beispiel einer Antwort auf den GET-Request einer REST-Ressource

Abbildung 23: Beispiel einer WADL

Abbildung 24: Web Services Sicherheitsstandards

Abbildung 25: Einfaches Szenario von WS-Federation

Abbildung 26: SOAP Leistungsmessung

Abbildung 27: Ping-Messungen

Abbildung 28: Software Product Lines bei der FMG Web Service Schnittstelle

Abbildung 29: Analyse-Objektmodell der Web Service Bibliothek

Abbildung 30: UML-Sequenzdiagramm des Anwendungsfalls CallWebService

Abbildung 31: Web Service Schnittstelle in die CORBA Middleware integriert

Abbildung 32: Web Service Schnittstelle ohne Integration in CORBA Middleware

Abbildung 33: SOA auf Basis von Web Services mit Anbindung zur CORBA Middleware

Abbildung 34: SOA Web Services Middleware ohne Anbindung zur CORBA Middleware

Abbildung 35: UML-Klassendiagramm: Subsystemzerlegung

Abbildung 36: Beispiel einer Antwort auf einen Web Service Aufruf

Abbildung 37: UML-Sequenzdiagramm: DataProviderSubsystem

Abbildung 38: UML-Sequenzdiagramm: NotificationSubsystem – Erstellen einer Subskription

Abbildung 39: FMG Notification Service – WSDL Beschreibung

Abbildung 40: UML-Sequenzdiagramm: NotificationSubsystem – Verarbeitung einer Benachrichtigung

Abbildung 41: TLS: Gegenseitige Authentifizierung von Client und Server

Abbildung 42: UML-Verteilungsdiagramm FMG Web Service Schnittstelle

Abbildung 43: VMware ESX Hardwareausfall

Abbildung 44: Veritas Cluster Server

Abbildung 45: Kontrollfluss beim Web Service Aufruf (Pull Modell)

Abbildung 46: Kontrollfluss bei einer Benachrichtigung (Push Modell)

Abbildung 47: UML-Klassendiagramm: Konfigurationsmodell der Web Service Domain

Abbildung 48: Beispiel einer XML-Konfigurationsdatei

Abbildung 49: UML-Klassendiagramm: WebServiceSubsystem

Abbildung 50: UML-Klassendiagramm: DataProviderSubsystem

Abbildung 51: UML-Klassendiagramm: NotificationSubsystem (1/2)

Abbildung 52: UML-Klassendiagramm: NotificationSubsystem (2/2)

Abbildung 53: UML-Klassendiagramm: SecuritySubsystem

Abbildung 54: UML-Klassendiagramm: TransformationSubsystem

Abbildung 55: UML-Klassendiagramm: MonitoringSubsystem (1/2)

Abbildung 56: UML-Klassendiagramm: MonitoringSubsystem (2/2)

Abbildung 57: Skytanking Web Service Schnittstelle register()

Abbildung 58: SQL-Abfrage Flugdatenbestand Skytanking Schnittstelle

Abbildung 59: Java Web Service Klasse der Skytanking Schnittstelle

Abbildung 60: Ergebnisse des Leistungstests der Skytanking Schnittstelle (Total time)

Abbildung 61: NetBeans GUI – Konfiguration von WS-ReliableMessaging

Abbildung 62: Beispiel eines XML-Dokuments mit einem Flugdatensatz

Abbildung 63: XML-Schema für einen Flugdatensatz

Abbildung 64: UDDI-Datenmodell in UML

Abbildung 65: WS-BrokeredNotification - UML Sequenzdiagramm

Abbildung 66: Erzeugung und Validierung von XML-Signaturen

Tabellenverzeichnis

Tabelle 1: Wichtige Kennzahlen der Flughafen München GmbH

Tabelle 2: Szenario AircraftCleaning

Tabelle 3: Szenario MobileFlightPlan

Tabelle 4: Anwendungsfall: CreateWebService

Tabelle 5: Anwendungsfall: ConfigWebService

Tabelle 6: Anwendungsfall: MonitorWebService

Tabelle 7: Anwendungsfall: CallWebService

Tabelle 8: Anwendungsfall: LoadConfig

Tabelle 9: Anwendungsfall: ConfigException

Tabelle 10: Anwendungsfall: UpdateMonitoring

Tabelle 11: Anwendungsfall: ManageSecurity

Tabelle 12: Anwendungsfall: SecurityException

Tabelle 13: Anwendungsfall: CallDataProvider

Tabelle 14: Anwendungsfall: ManageSubscriptions

Tabelle 15: Anwendungsfall: CreateSubscription

Tabelle 16: Anwendungsfall: StartSubscription

Tabelle 17: Anwendungsfall: StopSubscription

Tabelle 18: Anwendungsfall: NotifyPartner

Tabelle 19: Anwendungsfall: TransformResult

Tabelle 20: IT der FMG in Zahlen

Tabelle 21: Vergleich zwischen Transportsicherheit und Nachrichtensicherheit

Tabelle 22: Leistungsvergleich CORBA und SOAP Web Services mit und ohne Last

Tabelle 23: Anwendungsfall: GlassFishConfiguration

Tabelle 24: Anwendungsfall: DeployWebServiceInterface

Tabelle 25: Beispiel einer Gruppe von Flugdatensätzen

Tabelle 26: Skytanking Datenfelder

Tabelle 27: Leistungstest: Eigenschaften der verwendeten Systeme

Tabelle 28: Ergebnisse des Leistungstests der Skytanking Schnittstelle

Tabelle 29: Glossar

Abkürzungsverzeichnis

[Abbildung in dieser Leseprobe nicht enthalten]

Vorwort

Die vorliegende Arbeit wurde in der Zeit von August 2009 bis Februar 2010 bei der Flughafen München GmbH in der Abteilung ITEC (Competence Center IT-Technology) erstellt. Sie bildete die Abschlussarbeit meines Masterstudiums Wirtschaftsinformatik an der Technischen Universität München.

Ich möchte mich bei Professor Bernd Brügge, Ph.D. (Lehrstuhl für Angewandte Softwaretechnik) bedanken, der den Kontakt zur FMG hergestellt und sich gleichzeitig bereit erklärt hat, diese Arbeit zu betreuen. Für die Betreuung seitens der FMG bedanke ich mich bei Herrn Harald Ranner sowie Herrn Bernhard Steckenbiller. Gleichzeitig möchte ich meinen Dank für die Diskussionen, Tipps und Anregungen Rolf Gall, Peter Fleischer, Achim Tuffentsammer, Jörg Brünnert, Michael Hüttenkofer, Dr. Andrea Sikeler, Michael Haas und Andreas Keil aussprechen.

Mein Dank gilt auch meiner Freundin Sabine sowie meine Eltern, die mich während meiner gesamten Studienzeit immer unterstützt haben.

Zusammenfassung

Lange Zeit wurden Web Services in Unternehmen vor allem aufgrund von Sicherheits- und Leistungsbedenken aber auch aus Gründen der Unreife nur zurückhaltend eingesetzt. Mittlerweile haben sich Web Services auch im Unternehmensumfeld etabliert, nicht zuletzt aufgrund der Tatsache, dass sich in der jüngeren Vergangenheit viel getan hat, um die kritischen Themen, allen voran die Sicherheit von Web Services, zu adressieren. Mit dem Einsatz von Web Services zur Kommunikation innerhalb und zwischen Unternehmen sind aber auch viele Vorteile verbunden. Exemplarisch seien hier die Standardisierung und die verfügbaren Werkzeuge genannt, die dazu geführt haben, dass Web Services auf fast allen Plattformen und Infrastrukturen relativ einfach angebunden und benutzt werden können.

Die vorliegende Arbeit wurde in Zusammenarbeit mit der Flughafen München GmbH (FMG) erstellt, die Web Services ebenfalls einsetzen will, um externe Partner damit (noch) einfacher anbinden zu können. Zu den Kernaufgaben dieser Master’s Thesis zählen deshalb die Konzeption und Implementierung einer universell einsetzbaren Web Service Schnittstelle unter Berücksichtigung der besonderen Anforderungen eines Flughafens hinsichtlich Sicherheit und Leistung sowie der ereignisgetriebenen Architektur. Anhand eines realen Beispiels soll die Einsatzbereitschaft der Schnittstelle demonstriert werden.

Stichworte: Web Services, Web Service Sicherheit, Web Service Performance, Datenaustausch, Push Notification, Web Service Messaging, Middleware, CORBA, SOA, XML, SOAP, WSDL, REST.

Abstract

For a long time there has been a lack of using Web Services in companies due to security and performance issues, but also because of their immaturity. In the meantime Web Services were established also in enterprise environments not to mention due to the fact that there has been taken a lot of effort to address the critical issues, such as the first one security. But there are also a lot of advantages when using Web Services for communication within or between company borders. For instance, the standardization and available tools have to be mentioned, which have lead to relatively easy linking and using of Web Services on almost all platforms and infrastructures.

The present paper was created in collaboration with the Flughafen München GmbH (FMG), which intends to use Web Services in order to (continue) facilitate linking of external partners. The main tasks of this Master’s Thesis are to work out and implement a concept for an all-purpose Web Service interface regarding the special requirements of an airport with respect to security and performance and also the event-driven architecture. The utilizability of the interface should be demonstrated on the basis of a real example.

Key words: Web Services, Web service security, Web service performance, Data interchange, Push Notification, Web Service Messaging, Middleware, CORBA, SOA, XML, SOAP, WSDL, REST.

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 (Manes 2009, 54 ff.). 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 (Herrmann 2008b). Dass SOA damit bereits am Ende sei, wird aber von mehreren IT-Verantwortlichen bezweifelt (Herrmann 2008a). Untermauert wird dies auch durch den SOA Check 2009 der Technischen Universität Darmstadt (Martin/Eckert 2009). 84% der befragten Unternehmen geben an, dass SOA in ihrem Unternehmen bereits eingesetzt wird (47%) oder aber der Einsatz geplant ist (37%).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Gartner IT Hype Cycle 2008

Quelle: (CIO.de 2008)

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 Middlewareinfra-struktur, 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 (Papazoglou 2008, 82).

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.“ (Aier/Schönherr 2004, 13)

Die Umsetzung einer EAI erfordert sowohl eine technische Integration als auch eine organisatorische/soziale Integration, wobei beides unternehmensintern oder unternehmensübergreifend betrachtet werden kann (Conrad et al. 2006, 5).

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.” (Papazoglou 2008, 55 f.)

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 (Melzer et al. 2008, 21 ff.).

Ein Enterprise-Service-Bus (ESB) bildet die zentrale Integrationseinheit der EAI (Computerwoche 2009) 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 (Melzer et al. 2008, 22f.).

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.“ (Melzer et al. 2008)

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“ (Strnadl 2006).

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.

1.2 Kurzvorstellung der Flughafen München GmbH

Wie der Titel dieser Master’s Thesis bereits aussagt, wird diese Arbeit in Zusammenarbeit mit der Flughafen München GmbH durchgeführt. Aus diesem Grund wird nachfolgend in aller Kürze die Flughafen München GmbH vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Flughafen München - Franz Joseph Strauß - Luftbild

Quelle: (Zaddach 2008, 4)

Geschichte und Meilensteine

Am 28. Oktober 1939 nahm der Flughafen München zum ersten Mal den Betrieb auf dem Flughafengelände München Riem auf. Da die Erweiterung bzw. der Umbau dieses Flughafengeländes aber aufgrund der Nähe zum Stadtkern erheblich eingeschränkt war, wurde bereits im März 1963 mit der Planung eines Großflughafens außerhalb von München begonnen (Wikipedia 2009a).

Die Standortentscheidung zugunsten des Erdinger Moos fiel endgültig im Juli 1969. Der neue Flughafen (Flughafen München Franz Josef Strauß) nahm seinen Betrieb schließlich am 17. Mai 1992 mit einem Terminal bestehend aus fünf Modulen (A-E) sowie zwei Start- und Landebahnen, die unabhängig voneinander betrieben werden können, auf. Um die Abfertigung der stetig steigenden Passagierzahlen gewährleisten zu können wurde im Jahre 1997 mit den Planungen für ein zweites Terminal begonnen. Das Terminal 2 wurde am 29. Juni 2003 eröffnet (Wikipedia 2009a).

Eigentümer

Die Flughafen München GmbH (FMG) hat drei staatliche Gesellschafter (FMG 2009a):

- Freistaat Bayern (51%)
- Bundesrepublik Deutschland (26%)
- Landeshauptstadt München (23%)

Konzerngesellschaften

Nachfolgend sind die Tochterunternehmen der FMG aufgelistet (FMG 2009b). In Klammern wird jeweils kurz der Geschäftszweck aufgelistet.

- aerogate (Check-In, Gepäck, Flugzeugabfertigung, Reisebuchung)
- AeroGround (Abfertigungsdienste am Boden)
- Allresto (Restaurants und sonstige gastronomische Einrichtungen)
- BayernFM (Facility Management)
- CAP (Bewachungs- und Sicherheitsdienste)
- Cargogate (Luftfrachtabfertigung)
- EFM (Rangieren und Enteisen von Flugzeugen)
- eurotrade (Betreiber von Läden im öffentlichen und nicht-öffentlichen Bereichen)
- FMV (Vermittlung und Verwaltung von Versicherungen)
- mucground (Bodenverkehrsdienste)
- Terminal 2 BG (Finanzierung, Bau und Betrieb des Terminals 2)
- MediCare (Medical Care)

Unternehmensstrategie

Die FMG hat folgende Konzernmission formuliert, auf die alle Aktivitäten der FMG seit 2005 ausgerichtet sind:

„2010 sind wir der attraktivste und effizienteste Hub-Flughafen in Europa. […] Der Flughafen München soll demnach als Infrastrukturstandort und Dienstleister bzw. Serviceanbieter der attraktivste unter den europäischen Hub-Flughäfen sein. Dazu gehören auch wettbewerbsfähige Preise sowie auf die Erfordernisse der Kunden ausgerichtete, effiziente Prozesse.“ (FMG 2008, 59).

Um diese Mission erfüllen zu können, wird besonderer Wert auf die Stärkung der Innovationskraft gelegt. Damit sollen neue, attraktive Produkte und Dienstleistungen für die Kunden der FMG entwickelt und effizient angeboten werden. Des Weiteren wird der Ausbau der Flughafeninfrastruktur vorangetrieben. Im Fokus steht dabei der Bau einer dritten Start- und Landebahn, um das Kapazitätsziel von mindestens 120 Starts und Landungen pro Stunde erreichen zu können (FMG 2008, 60 ff.).

Kennzahlen

[Abbildung in dieser Leseprobe nicht enthalten]^{[1] [2] [3]}

Tabelle 1: Wichtige Kennzahlen der Flughafen München GmbH

Quelle: Eigene Darstellung in Anlehnung an (FMG 2009d, 4)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Fluggastaufkommen im gewerblichen Luftverkehr 1999-2008

Quelle: (FMG 2009d, 5)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Flugbewegungen gesamt 1999-2008

Quelle: (FMG 2009d, 5)

Die beiden Abbildungen zeigen einen deutlichen Wachstumspfad der FMG auf. Im Zehn-Jahres-Vergleich (1999-2008) nahm das Fluggastaufkommen um 62% zu, während sich die Flugbewegungen um 45% erhöhten. Im internationalen Vergleich schnitt der Flughafen München beim Passagieraufkommen im Jahre 2008 auf Platz 27 (1999: Platz 40) ab, europaweit liegt der Münchner Flughafen auf Platz sieben (1999: Platz 9). Hinter dem Flughafen Frankfurt belegt der Flughafen München weiterhin den zweiten Platz (1999: Platz 2) im innerdeutschen Vergleich (FMG 2009c).

Servicebereich IT

Im Servicebereich IT der FMG sind derzeit ca. 190 Mitarbeiter in den folgenden acht Servicefeldern beschäftigt (Ranner 2009, 5):

- ITE (Projekte und Entwicklung)
- ITO (Betrieb und Service)
- ITN (IT Engineering)
- ITF (Field Service)
- ITC (Consulting)
- ITI (Corporate Information Management)
- ITS (Interne Services)
- ITC (Controlling & Sales)

IT-Strategie

Die IT-Strategie der FMG ist aus der Konzernstrategie abgeleitet und soll die Mission der FMG unterstützen. Aus der strategischen Ausrichtung ergibt sich, dass der Servicebereich IT als Profit-Center geführt wird.

„Am Flughafen München sind wir der führende Anbieter für IT-Services und Systeme der Informations- und Kommunikationstechnik und wollen unsere Marktposition weiter ausbauen. Durch die Qualität, Innovationskraft und Wettbewerbsfähigkeit unserer Leistungen unterstreichen wir die Attraktivität des Flughafens München und sind für unsere Kunden der Anbieter der ersten Wahl. Für uns stehen die Bedürfnissen, Anforderungen und Zufriedenheit unserer Kunden und Nutzer im Mittelpunkt. […] Durch die Vermarktung unserer Leistung erbringen wir einen positiven Beitrag zum Unternehmensergebnis der FMG.“ (Ranner 2009, 1).

Servicefeld ITE (Projekte und Entwicklung)

Diese Arbeit ist bei der FMG im Servicefeld ITE (Projekte und Entwicklung) angesiedelt, das folgende Aufgabengebiete umfasst (Ranner 2009, 12 ff.):

- CC Application Development: Auswahl und Entwicklung von Anwendungssoftware
- CC IT-Technology: Bereitstellung von Basisdiensten in den Bereichen Datenbanken, Middleware, Redundanz und Software-Entwicklung
- Betreuung der SAP-Systeme
- Betreuung der Vertriebsanwendungssysteme
- Betreuung der Anwendungssysteme für verkehrsspezifische Prozesse (Aviation)
- Betreuung der Anwendungssysteme für Flugzeugabfertigungsprozesse am Boden (Groundhandling)

1.3 Problemstellung

Die FMG beobachtet schon seit längerem das Themengebiet der Web Services und will nun die damit verbundenen Potenziale nutzen. Besonders interessant ist dabei die Anbindung externer Partner mittels Web Services. Web Services stellen einen allgemein anerkannten und akzeptierten Standard zur Bewerkstelligung des Datenaustauschs zwischen Unternehmen dar. Zu den Vorteilen von Web Services zählen (Preissler 2004, 24):

- Programmiersprachen- und Plattformunabhängigkeit.
- Breite Unterstützung in der Industrie (z.B. Microsoft, IBM, Oracle, SAP).
- Verwendung offener Standards (keine Lizenzkosten).
- In der Regel geringe Anforderungen an Clients.
- Unabhängigkeit vom Transportprotokoll.
- Flexible Integration heterogener Systeme durch lose Kopplung und Verwendung verbreiteter Protokolle.
- Web Services basieren auf XML, was weit verbreitet ist und das Debugging erleichtert.
- Firewalldurchlässigkeit bei Verwendung von HTTP auf Port 80 (allerdings wird dies aus Sicherheitsgründen häufig auch kritisiert).
Mit dem Einsatz von Web Services sind aber auch einige Nachteile verbunden (Preissler 2004, 24f.):
- Mögliche Inkompatibilitäten aufgrund von Interpretationsspielräumen bei unterschiedlichen Implementierungen der Protokolle (z.B. SOAP). Für die Lösung dieses Problems wurde die Web Services Interoperability Organization (WS-I) gegründet.
- SOAP garantiert keinen Schutz der übertragenen Daten und garantiert auch nicht für die Übertragung. Diese Probleme wurden mit den Spezifikationen WS-Security und WS-ReliableMessaging adressiert.
- SOAP über HTTP bietet keine Callback-Funktionalität, sodass eine Interaktion nur vom Client ausgehen kann. Mit WS-Notification wird diesem Problem Rechnung getragen.
- Da Web Services auf XML basieren und HTTP häufig als Transportprotokoll eingesetzt wird, ergeben sich gegenüber vergleichbarer Techniken (z.B. CORBA) Leistungsnachteile (vgl. Elfwing/Paulsson 2002).

Die Aufgabe dieser Arbeit ist es, die theoretischen Grundlagen von Web Services darzustellen und dabei insbesondere auf Sicherheit und Leistung von Web Services einzugehen, die im FMG-Umfeld sehr wichtig sind. Darauf aufbauend soll eine universell einsetzbare Web Service Schnittstelle konzeptioniert und implementiert werden, die die Anbindung verschiedener externer Partner an die FMG für den lesenden Zugriff auf Flugdaten (je nach Partner in unterschiedlicher Granularität) basierend auf Web Services unterstützt. Zudem soll die Web Service Schnittstelle das FMG-Kommunikationsmodell unterstützen, dass bisher für die Anbindung externer Partner über CORBA-Schnittstellen verwendet wurde. Das FMG-Kommunikationsmodell funktioniert wie folgt:

1. Das Partnersystem registriert sich bei der für ihn von der FMG zur Verfügung gestellten Schnittstelle für den Erhalt eines aktuellen Flugdatenbestandes und Aktualisierungen auf diesem Bestand.
2. Das FMG-System schickt dem Partnersystem zunächst den aktuellen Flugdatenbestand an eine vom Partner zur Verfügung gestellte „Notification“ Schnittstelle.
3. Anschließend wird der Partner über jede Änderung eines Datensatzes im Bestand informiert, in dem jeder aktualisierte Datensatz ebenfalls an die „Notification“ Schnittstelle gesendet wird.
4. Um eine bestehende Verbindung zu simulieren, wird dem Partnersystem zusätzlich alle 30 Sekunden eine Ping Nachricht gesendet (Heartbeat Pattern).
5. Das Partnersystem kann die Kommunikation jederzeit durch einen entsprechenden Aufruf einer Methode bei der für ihn zur Verfügung gestellten Schnittstelle beenden.
6. Beim Auftreten eines Fehlers wird die Kommunikation automatisch eingestellt. In so einem Fall muss sich das Partnersystem neu registrieren.

Die Funktionsfähigkeit der Web Service Schnittstelle soll anhand eines realen Beispiels einer Schnittstelle demonstriert werden.

1.4 Ziele und Aufbau der Arbeit

Die Ziele der vorliegenden Arbeit sind:

(1) Theoretische Einführung in den Themenbereich Web Services unter Berücksichtigung der Basistechnologien sowie der Sicherheits- und Leistungsaspekte.
(2) Konzeption und Implementierung einer universellen Web Service Schnittstelle, die die Entwicklung einer speziellen Flugdatenschnittstelle für einen bestimmten Partner basierend auf Web Services optimal unterstützt.
(3) Umsetzung einer real existierenden Schnittstelle auf Basis von Web Services unter Verwendung der implementierten Web Service Schnittstelle.

Die Arbeit ist wie folgt gegliedert:

In Kapitel 2 werden die Anforderungen an die zu entwickelnde Web Service Schnittstelle der FMG ermittelt. Dies beinhaltet die Identifikation von Akteuren, Szenarien und relevanten Anwendungsfällen.

In Kapitel 3 wird die existierende Middlewareinfrastruktur der FMG vorgestellt, die auf CORBA basiert. Die zu entwickelnde Web Service Schnittstelle muss mit dieser Infrastruktur verbunden werden.

In Kapitel 4 wird das Themengebiet Web Services theoretisch behandelt. Neben mehreren Begriffsdefinitionen werden Anwendungsgebiete, Architektur sowie Basistechnologien und Spezifikationen beschrieben. Die für Unternehmen im Allgemeinen und für die FMG im Speziellen besonders wichtigen Aspekte Sicherheit und Leistung von Web Services werden jeweils gesondert in einem eigenen Abschnitt ausführlicher behandelt.

In Kapitel 5 wird die Konzeption und Implementierung der FMG Web Service Schnittstelle behandelt. Dabei werden die einzelnen Schritte der Konzeption, analog zur Vorgehensweise bei einem Softwareentwicklungsprojekt, erläutert. Zudem wird die Funktionsfähigkeit der Web Service Schnittstelle anhand einer real existierenden Schnittstelle gezeigt. Dabei wird auch ein Leistungstest der Web Service Schnittstelle durchgeführt.

In Kapitel 6 werden die wesentlichen Ergebnisse dieser Arbeit zusammengefasst. Dabei wird zunächst auf jene Ergebnisse eingegangen, die von allgemeinem Interesse sind. Anschließend werden die Ergebnisse, die speziell für die FMG wichtig sind, festgehalten.

Den Abschluss bilden eine kritische Betrachtung dieser Arbeit sowie ein Ausblick, der weiteren Forschungsbedarf aufzeigt.

2 Anforderungsermittlung

Im Rahmen der Anforderungsermittlung eines Softwaresystems unterscheidet man zwischen funktionalen und nichtfunktionalen Anforderungen.

- „ Funktionale Anforderungen beschreiben die Interaktion des Systems mit seiner Umgebung unabhängig von seiner Implementierung. Die Umgebung beinhaltet den Anwender und alle anderen externen Systeme, die auf das System einwirken.“ (Brügge/Dutoit 2004, 149). Funktionale Anforderungen definieren also die Funktionen, die ein Softwaresystem bereitstellen soll.
- „ Nichtfunktionale Anforderungen beschreiben Aspekte des Systems, die nicht unmittelbar in Bezug zu seiner Funktionalität stehen. Nichtfunktionale Anforderungen betreffen verschiedenste Aspekte des Systems, die von der Bedienbarkeit bis hin zur Leistungsfähigkeit reichen.“ (Brügge/Dutoit 2004, 150). Die nichtfunktionalen Anforderungen können nach dem FURPS-Modell (F unctionality, U sability, R eliability, P erformance und S upportability) in folgende Anforderungskategorien eingeteilt werden:
- „ Bedienbarkeit gibt an, wie leicht ein System für den Anwender zu erlernen ist, wie einfach die Eingabe ist und wie leicht die Ergebnisse eines Systems oder einer Komponente interpretierbar sind.“ (Brügge/Dutoit 2004, 150).
- „ Zuverlässigkeit ist die Fähigkeit eines Systems oder einer Komponente, die erforderlichen Funktionen unter vorgegebenen Bedingungen während eines vorgegebenen Zeitrahmens zu erfüllen.“ (Brügge/Dutoit 2004, 151). Darunter fallen zusätzlich noch die Robustheit eines Systems, dass die „Fähigkeit eines Systems, auch bei falschen Eingaben korrekt arbeiten zu können.“ (Brügge/Dutoit 2004, 151) angibt, sowie deren Sicherheit, dass „ein Maß für das Ausbleiben katastrophaler Folgen für die Umgebung“ (Brügge/Dutoit 2004, 151) ist.
- „ Leistungsanforderungen befassen sich mit quantifizierbaren Attributen des Systems wie beispielsweise Antwortzeit (wie schnell das System auf eine Benutzereingabe reagiert), Durchsatz (wie viel Arbeit das System innerhalb einer bestimmten Zeit bewältigen kann) und Verfügbarkeit (der Grad, bis zu dem ein System oder eine Komponente funktions- und einsatzfähig ist, wenn es bzw. sie gebraucht wird).“ (Brügge/Dutoit 2004, 151).
- „ Unterstützbarkeit bezieht sich auf die Leichtigkeit, mit der Änderungen im System durchgeführt werden können, beispielsweise Anpassungsfähigkeit (die Fähigkeit, das System ändern zu können, um es an neue Konzepte im Anwendungsbereich anzupassen), Wartungsfreundlichkeit (die Fähigkeit, ein System zu verändern, um neue Techniken zu integrieren oder Fehler zu beheben) und Internationalisierung (die Fähigkeit, das System zu verändern, um zusätzliche internationale Konventionen wie Sprache, Währungseinheiten und Zahlenformaten handhaben zu können).“ (Brügge/Dutoit 2004, 151).

Des Weiteren sollte die Anforderungsspezifikation folgende Eigenschaften erfüllen (Brügge/Dutoit 2004, 152f.):

- Vollständigkeit ist dann gegeben, „wenn alle möglichen Szenarien innerhalb des Systems beschrieben wurden[.]“ (Brügge/Dutoit 2004, 153).
- Konsistenz einer Anforderungsspezifikation ist erreicht, wenn keine Widersprüche entstehen.
- Klarheit bedeutet die Eindeutigkeit der Anforderungsspezifikation hinsichtlich der Beschreibung des Systems. Klarheit ist dann erreicht, wenn die Spezifikation genau ein System beschreibt und es nicht möglich ist, diese Spezifikation unterschiedlich zu deuten.
- Korrektheit einer Anforderungsspezifikation ist gegeben, „wenn sie das vom Kunden benötigte und vom Entwickler zu erstellende System genau darstellt (d.h. alle Elemente in der Anforderungsspezifikation stellen die unterschiedlichen Aspekte des Systems zur Zufriedenheit sowohl des Kunden als auch der Entwickler dar).“ (Brügge/Dutoit 2004, 153).
- Realitätsnähe ist dann erreicht, „wenn das System unter den vorgegebenen Einschränkungen implementiert werden kann.“ (Brügge/Dutoit 2004, 153). Die Anforderungsspezifikation ist dann realistisch.
- Nachprüfbarkeit einer Anforderungsspezifikation ist dann erfüllt, „wenn man nach Fertigstellen des Systems mit wiederholbaren Tests zeigen kann, dass die Anforderungen erfüllt werden.“ (Brügge/Dutoit 2004, 153).
- Rückverfolgbarkeit ist gegeben, „wenn jede Anforderung durch die gesamte Softwareentwicklung bis zur Implementierung verfolgt werden kann und wenn jede Systemfähigkeit auf einen entsprechenden Satz von Anforderungen zurückverfolgt werden kann.“ (Brügge/Dutoit 2004, 153).

2.1 Akteure

„ Akteure repräsentieren externe Entitäten, die mit dem zu entwickelnden System interagieren. Bei einem Akteur kann es sich sowohl um einen Menschen handeln als auch um ein anderes System.“ (Brügge/Dutoit 2004, 155). Für die Web Service Schnittstellen der FMG wurden folgende Akteure identifiziert:

- FMG-ITE

Das Servicefeld ITE der FMG administriert die Web Service Schnittstellen und übernimmt insbesondere die Konfiguration der Web Services für die einzelnen Partner.

- Interne oder externe Partner

Bei Partnern kann es sich einerseits um Organisationseinheiten wie interne Abteilungen oder externe Unternehmen handeln, andererseits aber auch um interne oder externe Systeme. Interne Partner agieren innerhalb der FMG Systemgrenze, externe Partner dagegen außerhalb (Tuffentsammer 2009).

Nachfolgend werden einige Beispiele für interne und externe Partner genannt:

- ITEA, ITEG (interne Abteilungen)
- Abfertiger, Airlines, DFS, Medien (externe Unternehmen)
- Andocksystem, Systeme des Dolly 3 Projekts (interne Systeme)
- Dispositionssystem eines Reinigungsunternehmens (externes System)

2.2 Szenarien

Nachfolgend werden zwei Szenarien angeführt, die mit einer Web Service Schnittstelle realisiert werden können:

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 2: Szenario AircraftCleaning

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 3: Szenario MobileFlightPlan

Quelle: Eigene Darstellung

2.3 Anwendungsfälle

Das nachfolgende Anwendungsfalldiagramm zeigt die wesentlichen Anwendungsfälle der FMG Web Service Schnittstelle (im Folgenden als „System“ bezeichnet), ihr Zusammenwirken untereinander, sowie deren Initiierung durch die jeweiligen Akteure. Im Anschluss werden die einzelnen Anwendungsfälle genauer erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: FMG Web Service Schnittstelle – Anwendungsfalldiagramm

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 4: Anwendungsfall: CreateWebService

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 5: Anwendungsfall: ConfigWebService

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 6: Anwendungsfall: MonitorWebService

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 7: Anwendungsfall: CallWebService

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 8: Anwendungsfall: LoadConfig

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 9: Anwendungsfall: ConfigException

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 10: Anwendungsfall: UpdateMonitoring

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 11: Anwendungsfall: ManageSecurity

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 12: Anwendungsfall: SecurityException

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 13: Anwendungsfall: CallDataProvider

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 14: Anwendungsfall: ManageSubscriptions

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 15: Anwendungsfall: CreateSubscription

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 16: Anwendungsfall: StartSubscription

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 17: Anwendungsfall: StopSubscription

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 18: Anwendungsfall: NotifyPartner

Quelle: Eigene Darstellung

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 19: Anwendungsfall: TransformResult

Quelle: Eigene Darstellung

2.4 Funktionale Anforderungen

In diesem Abschnitt werden nun die funktionalen Anforderungen der FMG Web Service Schnittstelle aufgelistet und beschrieben (Tuffentsammer 2009).

[Abbildung in dieser Leseprobe nicht enthalten]

2.5 Nichtfunktionale Anforderungen

Neben den funktionalen Anforderungen existieren auch einige nichtfunktionale Anforderungen für die FMG Web Service Schnittstelle (Tuffentsammer 2009).

[Abbildung in dieser Leseprobe nicht enthalten]

3 FMG Middlewareinfrastruktur

Im Folgenden wird die IT-Softwarelandschaft der FMG vorgestellt, die entscheidend für die Bewerkstelligung der vier Kernprozesse der FMG (Flugzeugabfertigung, Passagierabfertigung, Gepäckssortierung/Transport und Frachthandling) ist. Zunächst werden die Anforderungen an die Verkehrssysteme der FMG erläutert. Im Anschluss wird die historische Entwicklung der FMG Softwarelandschaft hin zu einer CORBA-Middlewareinfrastruktur dargelegt. Danach werden CORBA an sich und die CORBA-Softwarekomponenten im Speziellen bei der FMG genauer erläutert. Abschließend wird die Frage beantwortet, ob die aktuelle FMG Middlewareinfrastruktur die Merkmale einer SOA erfüllt.

3.1 Anforderungen an die Verkehrssysteme der FMG

- „Hohe Verfügbarkeit der Systeme
- Ausfall einzelner Systeme soll nicht das Gesamt-System „lahm“ legen
- Betrieb „rund-um-die-Uhr“ (Nachts ruhiger)
- Starke Integration der Systeme
- Schnelle Kommunikation zwischen den Systemen
- Kostengünstige Systeme“ (Zaddach 2008, 35)

IT in Zahlen

Zur Erfüllung der Hochverfügbarkeitsforderung werden zwei redundante Rechenzentren betrieben. Die Zahlen in der nachfolgenden Tabelle vermitteln einen Eindruck über Größe, Komplexität und Leistungsbedarf der IT.

[Abbildung in dieser Leseprobe nicht enthalten]

Tabelle 20: IT der FMG in Zahlen

Quelle: (Zaddach 2008, 13, 46)

3.2 Historische Entwicklung der FMG Middlewareinfrastruktur

Das Grundkonzept des ereignisgesteuerten Datenstroms (Event-driven Enterprise) stammt aus den Jahren 1988 bis 1992 und wurde im Zuge der Inbetriebnahme des neuen Franz Josef Strauß Flughafens implementiert. Dabei beziehen die Anwendungen die notwendigen Daten von zentraler Stelle und werden über für sie relevante Datenmanipulationen informiert. Die Datenhaltung selbst erfolgte schon damals in einer relationalen Datenbank. Die dazu notwendigen Softwarekomponenten wurden von der Firma Softlab entwickelt. Die Kommunikation wurde über die proprietäre und komplexe FMG-Netzwerk-Software unter Verwendung des FMG-Protokolls Generation 1 oder auch über proprietäre Protokolle von externen Partnern abgewickelt. Zu den zentralen Softwarediensten zählten (Steckenbiller 2001, 1ff.):

- Verteildienst (nimmt Änderungen von FMG-internen Systemen an Datenbanktabellen entgegen und verteilt diese an angemeldete interne und externe Systeme)
- Bestandsdienst (liefert auf Anfrage Bestände aus der Datenbank)
- Sammeldienst (nimmt Daten von externen Systemen entgegen, manipuliert ggf. die Daten in der Datenbank und leitet die Änderungen zum Verteilen an den Verteildienst weiter)

Aus Gründen der Standardisierung der Kommunikationsinfrastruktur sowie der Integration heterogener Softwarekomponenten wurde im Jahre 2001 damit begonnen, die Socket-basierte Kommunikation durch eine CORBA-Middlewarekommunikation zu ersetzen, die bis heute aktuell ist (Frank 2005, 7).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Informationsdrehscheibe Flughafen

Quelle: (Zaddach 2008, 34)

Das Herzstück dieser Infrastruktur bildet der Information Broker mit einer zentralen Datenbank, der die zahlreichen Flughafenanwendungen (weiße Kreise) wie zum Beispiel Flugplanverwaltung, Busdispositionssystem, etc. mit den relevanten Informationen in Form von Nachrichten versorgt. Der Informationsfluss wird durch Ereignisse gesteuert (Event-Driven-Architecture), die durch die verschiedenen Anwendungen erzeugt werden. Der äußere blaue Bereich zeigt externe Partner (grüne Kreise), die über Adapter angebunden werden. Beispielsweise werden SITA-Meldungen empfangen, die Informationen über ankommende Flüge enthalten.

3.3 CORBA

In diesem Abschnitt wird CORBA und dessen Funktionsweise überblicksartig vorgestellt. Die Object Management Group (OMG)^[4] beschreibt CORBA wie folgt:

„ CORBA is the acronym for C ommon O bject R equest B roker A rchitecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.” (OMG 2009a)

CORBA ist eine von der Object Management Group (OMG) standardisierte Spezifikation, die die Interoperabilität von Anwendungen unter Nutzung objektorientierter Technologien in verteilten Umgebungen zum Ziel hat. Dabei werden die Unterschiede der heterogenen Umgebungen vor den Anwendungen verborgen. CORBA ist also eine Middleware, die zwischen Applikationen, dem Netzwerk und dem/den Betriebssystem(en) sitzt. Für CORBA existieren sowohl zahlreiche kommerzielle als auch Open-Source Implementierungen (Linnhoff-Popien 1998, 21), (Pope 1998, 61).

Die folgende Abbildung veranschaulicht die Funktionsweise von CORBA:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Technische Grundidee von CORBA

Quelle: (Zaddach 2008, 37)

Die blauen Kästchen stellen Anwendungen in den unterschiedlichsten Programmiersprachen dar. Die Kommunikation zwischen diesen (verteilten) Anwendungen übernimmt der Object Request Broker (ORB) über das Internet Inter-ORB Protocol (IIOP). Damit die Kommunikation von Applikationen, die in unterschiedlichen Programmiersprachen implementiert sind, überhaupt funktionieren kann, muss von der konkreten Programmiersprache abstrahiert werden. Dies wird durch die Interface Definition Language (IDL) erreicht, mit der eine Schnittstelle in einer abstrakten, programmiersprachenunabhängigen Sprache beschrieben werden kann. Aus den IDLs kann auf der Seite des Aufrufers (Client) ein Stub erzeugt werden. Für den Aufrufer wird damit ein lokaler Funktionsaufruf simuliert. In Wirklichkeit ist es aber ein entfernter Aufruf, der durch den ORB realisiert wird. Auf der Seite des Anbieters (Server) kann aus der IDL ein Skeleton generiert werden, in der der Anbieter die Implementierung vornimmt. CORBA fungiert also als Nachrichtenvermittler, der zwischen Client und Server brüggt.

Mowbray und Malveau geben drei zentrale Gründe für die Relevanz von CORBA als Zukunftstechnologie an (Mowbray/Malveau 1997, 13):

- CORBA IDL: Universelle Notation für Softwareschnittstellen.
- CORBA Infrastruktur: Der ORB vereinfacht verteiltes Rechnen.
- Standardisierte CORBA-basierte Spezifikationen: Beschleunigen die Entwicklung durch Design-Wiederverwendung, kommerziell verfügbare Softwaredienste, Interoperabilität und Wiederverwendung von Code.

Die Interface Definition Language (IDL)

IDL ist eine weit verbreitete standardisierte und stabile Notation für die Definition von Softwareschnittstellen, die auch unabhängig von CORBA verwendet werden kann. Sie ist eine abstrakte und programmierspracheunabhängige Beschreibungssprache für Schnittstellen, die die sichtbare Funktionalität von Objekten beschreibt aber Implementierungsdetails verbirgt (Trennung von Schnittstelle und Implementierung). Mit der IDL können Attribute, Operationen und deren Parameter sowie Ausnahmen (engl. Exceptions) angegeben werden. Interessant und wichtig ist vor allem die Tatsache, dass aus IDL-Schnittstellen mithilfe von IDL Compilern für spezielle Sprachen Stubs und Skeletons für viele Programmiersprachen erstellt werden können, d.h. die IDL kann in eine konkrete Programmiersprache übersetzt werden (Mowbray/Malveau 1997, 13), (Linnhoff-Popien 1998, 35).

Der Object Request Broker (ORB)

Der ORB ist das Herzstück des CORBA-Standards. Er ermöglicht die Kommunikation zwischen Objekten, die in unterschiedlichen Programmiersprachen implementiert sein können und auf verteilten, heterogenen Rechnern mit unterschiedlichen Betriebssystemen laufen können. Der ORB nimmt Aufträge eines Clients zur Ausführung einer Operation entgegen, leitet sie zur Objektimplementierung an den Server weiter und veranlasst dort deren Ausführung. Das Ergebnis dieser Operation wird anschließend an den Client zurückgesendet. Sollte es während der Ausführung zu Fehlern gekommen sein, werden diese an den Client durchgereicht. Exceptions können sowohl von Serverobjekten als auch vom ORB selbst geworfen werden.

Für den Client ist dies alles transparent, d.h. das Auffinden des Servers sowie die gesamte Kommunikation und Umwandlung der Daten für Client und Server sowie die Umwandlung in ein für die Übertragung geeignetes Format (CDR^[5] ), übernimmt der ORB. Um die Interoperabilität herstellen zu können, muss sowohl auf Client-Seite als auch auf Server-Seite ein ORB als Kommunikationsschnittstelle eingesetzt werden (Linnhoff-Popien 1998, 21), (Mowbray/Malveau 1997, 13 f.).

Das Internet Inter-ORB Protocol (IIOP)

Um die Interoperabilität zwischen verschiedenen ORB Implementierungen gewährleisten zu können, wurde mit dem General Inter-ORB Protocol (GIOP) ein einheitliches Protokoll für die Kommunikation entwickelt. Das Internet Inter-ORB Protocol (IIOP) ist eine Spezialisierung des GIOP und beschreibt wie die Agenten TCP/IP Verbindungen öffnen, um diese für den Transfer von GIOP Nachrichten zu nutzen. GIOP spezifiziert sieben verschiedene Nachrichtentypen: Request, Reply, Cancel Request, Locate Request, Locate Reply, Close Connection, Message Error (Linnhoff-Popien 1998, 38 ff.), (Pope 1998, 164 f.).

3.4 CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur

Zu Beginn der CORBA-Umstellung wurde eine kommerzielle Implementierung von IONA (Orbix 2000) eingesetzt. Aus Kostengründen erfolgte aber schon bald die Umstellung auf die Open Source ORBs JacOrb (Java) und TAO (C++).

In der folgenden Abbildung sind die CORBA-Softwarekomponenten sowie ihre Beziehungen untereinander innerhalb der FMG Middlewareinfrastruktur abgebildet. Die einzelnen Komponenten werden im Anschluss genauer erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur

Quelle: Eigene Darstellung in Anlehnung an (Gall 2008, 7)

CORBA-Namensdienst

Der CORBA-Namensdienst fungiert als Verzeichnisdienst. Er wird von externen Partnern verwendet, um eine Referenz auf den gewünschten Dienst zu erlangen. Innerhalb der FMG wird der Namensdienst nur benutzt, um eine gültige Referenz auf die Dienstfabrik zu erhalten (Gall 2008, 7).

Dienstfabrik (DF)

Die Dienstfabrik ist eine Eigenentwicklung der FMG und funktioniert ähnlich dem CORBA-Namensdienst. Sie wurde entwickelt, um den Redundanzanforderungen der FMG gerecht zu werden. Die verfügbaren Dienste registrieren sich in der Dienstfabrik unter einem eindeutigen Namen^[6]. In der Dienstfabrik werden dann unter diesem Namen immer zwei Instanzen desselben Dienstes registriert, die in unterschiedlichen Rechenzentren laufen. Eine Instanz ist im Normalbetrieb immer aktiv, die andere passiv. Die Dienstfabrik implementiert das Heartbeat-Entwurfsmuster. Alle 30 Sekunden wird mittels eines Pings festgestellt, ob die beiden Instanzen des Dienstens noch „am Leben“ sind. Wenn nun eine Anwendung einen Dienst benötigt, dann wendet sie sich an die Dienstfabrik und erhält die zu diesem Zeitpunkt gültige Objektreferenz auf den aktiven und funktionsfähigen Dienst. Mögliche Dienste sind alle Softwarekomponenten, die Schnittstellen implementieren und das Framework nutzen, also insbesondere der Information Broker sowie alle Objekt- und Anwendungsmanager und Adapter. Die Dienstfabrik selbst ist natürlich auch redundant ausgelegt (Gall 2008, 8).

Information Broker (IB)

Auch der Information Broker ist eine Eigenentwicklung, der für die asynchrone Nachrichtenübermittlung zuständig ist. Er empfängt Nachrichten und leitet diese an diejenigen Konsumenten weiter, die sich für diese Nachricht interessieren. Eine Nachricht besteht aus einer Liste von Name/Wert Paaren, wobei die Werte verschiedene Datentypen annehmen können. Zusätzlich ist jeder Nachricht auch ein bestimmter Typ zugewiesen, sodass sich Konsumenten für Nachrichten eines bestimmten Typs registrieren können, wobei in der Typangabe auch Wildcards enthalten sein dürfen. Mithilfe der Angabe eines Nachrichtentyps kann also eine gewisse inhaltliche Selektion vorgenommen werden. Darüber hinaus kann das Zeitintervall, in der die Konsumenten Nachrichten erhalten möchten, eingeschränkt werden. Weitergehende Filterungen oder Transformationen müssen durch die Konsumenten selbst vorgenommen werden. Der Information Broker speichert alle Nachrichten für vier Stunden, sodass auch verpasste Nachrichten in dieser Zeit nachgeliefert werden können (Gall 2008, 8).

Objektmanager

Die Objektmanager verwalten Datenbanktabellen und stellen eine Service-Schicht zur Verfügung, mit der ihre Schnittstelle komfortabel genutzt werden kann. Zu den Aufgaben der Objektmanager zählen die konsistente Datenhaltung sowie die Kapselung technischer Details. Außer den zentralen Diensten wie Dienstfabrik und Information Broker werden keine anderen Dienste von Objektmanagern genutzt. Daten dürfen nur über die entsprechenden Objektmanager in den Datenbanktabellen verändert werden. Bei jeder Änderung eines Datensatzes, werden diese Änderungen über den Information Broker in Form einer Nachricht verteilt. Objektmanager werden typischerweise von den Anwendungsmanagern und Adaptern benutzt. Aus Leistungsgründen dürfen lesende Abfragen auf die Datenbank in Ausnahmefällen auch von Anwendungsmanagern oder Adaptern direkt durchgeführt werden – typischerweise sind dies Join-Abfragen (Gall 2008, 8 f.).

Beispiel: Der „FlugManager“ ist der Objektmanager für die Datenart FD (Flugdaten). Er bietet Abfrage- und Aktualisierungsmethoden für die Flugdaten an. In der Service-Schicht wird ein Info-, Update- und Benachrichtigungsservice angeboten (Gall 2008, 9).

Anwendungsmanager

Die Anwendungsmanager sind Bestandteil jeder FMG Anwendung und kapseln Anwendungslogik. Sie benutzen Objektmanager für Datenabfragen und –manipulationen, dürfen aber auch eigene Datenbank-Tabellen verwalten, die nur für die jeweilige Anwendung relevant sind. Ein Anwendungsmanager verteilt im Gegensatz zu den Objektmanagern keine Änderungen über den Information Broker (Gall 2008, 9).

Beispiel: Der „STAR-Manager“ ist der Anwendungsmanager für die FMG Anwendung Vorfeldkontrolle. Er nutzt die Objektmanager „FlugManager“ und „RollsegmentManager“. Über eine Client-Server-Schicht werden alle STAR-GUIs, die relevante Updates in aufbereiteter Form erhalten, verwaltet. Zudem verwendet der „STAR-Manager“ für interne Daten eigene Datenbank-Tabellen (Gall 2008, 9).

Adapter

Externe Systeme oder Altsysteme, die nicht über CORBA kommunizieren können, werden über Adapter an die FMG Middlewareinfrastruktur mittels einer einfachen und stabilen Schnittstelle (Entwurfsmuster Fassade) angebunden. Adapter nutzen oftmals mehrere Anwendungs- und/oder Objektmanager und nehmen auch Protokollumwandlungen vor, falls der Partner CORBA nicht nutzen kann. Aus Sicherheitsgründen erfolgt die Kommunikation zu externen Partnern über den DBC-CORBA-Proxy. Damit sich externe CORBA-Anwendungen die Referenz eines Adapters über den CORBA-Namensdienst (Standardverzeichnisdienst) holen können, müssen sich alle Adapter beim CORBA-Namensdienst registrieren (Gall 2008, 9).

Beispiel:

Der „ADS-Adapter“ bindet die Andocksysteme an die FMG Middlewareinfrastruktur an. Die Andocksysteme erhalten aktuelle Fluginformationen über fachliche IDL-Methoden, die vom „ADS-Adapter“ bereitgestellt werden. Umgekehrt rufen die Andocksysteme aber auch entsprechende Methoden beim Adapter auf, wenn ein Flugzeug beispielsweise den Status „onblock“ hat. Der Adapter leitet die Statusänderung dann an den FlugManager weiter. Die Kommunikation zwischen „ADS-Adapter“ und den Andocksystemen wird über den DBC-CORBA-Proxy abgewickelt (Gall 2008, 9 f.).

GUI

Die Aufgabe der Graphical User Interfaces (GUIs) oder grafischen Benutzeroberflächen (deutsch) ist es, den Anwendern eine grafische, benutzerfreundliche Schnittstelle zur Verfügung zu stellen, mit denen Daten angezeigt und verändert werden können. Die Daten werden über einen Anwendungsmanager abgerufen und verändert. Darüber hinaus haben GUIs keine weiteren Beziehungen, insbesondere dürfen sie nicht mit dem Information Broker oder Objektmanagern kommunizieren. GUIs müssen gemäß FMG Richtlinien in Java geschrieben werden (Gall 2008, 10).

Beispiel:

Die „STAR-GUIs“ (grafische Benutzeroberflächen der Vorfeldkontrolle) kommunizieren mit dem Anwendungsmanager „STAR-Manager“ (Gall 2008, 10).

Domain Boundary Controller (DBC)

Zur Sicherung der CORBA-Kommunikation mit externen Systemen wird eine Firewall, der sogenannte DBC-CORBA-Proxy eingesetzt. Er unterstützt Authentifizierung, Autorisierung sowie die sichere, verschlüsselte Übertragung über SSL (Gall 2008, 10).

3.5 Abgleich der SOA-Merkmale in der FMG-Middlewareinfrastruktur

Eine Frage, die sich im Rahmen dieser Arbeit aufdrängt, ist die Frage, ob es sich bei der aktuellen FMG-Middlewareinfrastruktur um eine Service-orientierte Architektur (SOA) handelt. Dazu werden nachfolgend die Merkmale einer SOA nach (Melzer et al. 2008, 11f.) aufgelistet und geprüft, ob diese in der FMG-Middlewareinfrastruktur erfüllt werden.

Lose Kopplung

„Unter loser Kopplung verstehen wir einen Architekturansatz, bei dem die Abhängigkeiten zwischen Dienstanbietern und Dienstnutzern auf ein Minimum reduziert werden.“ (Tilkov/Tilly/Wilms 2005). Dabei müssen mehrere Dimensionen der Kopplung (z.B. zeitlich, örtlich, Technologien, Syntax, Semantik etc.) beachtet werden. Des Weiteren sind die Grenzen zwischen loser und enger Kopplung fließend. Tilkov, Tilly und Wilms führen aus, dass schon kleinste Änderungen (z.B. das Hinzufügen eines weiteren optionalen Arguments) in einem RPC-Modell häufig zu Problemen führen (Tilkov/Tilly/Wilms 2005). CORBA verstärkt diese Gefahr noch, da die Definition von IDLs zu strenger Typisierung tendiert, was einer losen Kopplung widerspricht. Bei der FMG wird dieses Problem adressiert, indem flexible Schnittstellen durch die Verwendung von Name/Wert-Paarlisten anstelle von festen Parameterlisten designed werden sollen (Gall 2008, 27f.).

Ein Grundgedanke von SOA ist die Auffindung, Einbindung und Nutzung von Diensten zur Laufzeit, um die Kopplung auf ein Minimum zu reduzieren und damit flexibel zu bleiben, sodass auch Dienste zur Laufzeit ausgetauscht werden können. In den FMG-Anwendungen sind die abhängigen Anwendungsmanager, die benötigte Dienste zur Verfügung stellen, fest hinterlegt, wodurch eine enge Kopplung entsteht. Ein Beispiel soll dies verdeutlichen: Der bestehende Anwendungsmanager „FlugManager“ wird von zahlreichen Anwendungen genutzt und ist in diesen Anwendungen fest hinterlegt. Wenn nun ein neuer Anwendungsmanager ebenfalls die Funktionalität des „FlugManagers“ implementiert und man nur einen Teil der bisherigen Anwendungen auf den neuen „FlugManager“ umstellen will (andernfalls würde der Austausch des bisherigen Anwendungsmanagers mit dem neuen „FlugManager“ genügen), müsste man alle Anwendungen, die den neuen „FlugManager“ nutzen sollen, um-schreiben und neu kompilieren.

Dynamisches Binden

Die Dienstfabrik unterstützt die dynamische Bindung der aktiven Instanz einer FMG-Softwarekomponente (z.B. Anwendungsmanager, Adapter) zur Laufzeit.

Verzeichnisdienst

Bei der FMG wird der CORBA-Namensdienst für externe Partner eingesetzt. Interne Systeme wenden sich an die Dienstfabrik, die jedoch nur die Instanz vorhandenen Softwarekomponenten zurückliefert, jedoch nicht die Suche nach Softwarekomponenten unterstützt, wie dies Verzeichnisdienste üblicherweise tun.

Verwendung von Standards

Die FMG verwendet als Middleware CORBA, das bei der OMG standardisiert ist.

Einfachheit

Es ist sehr schwierig eine allgemein gültige Aussage über die Einfachheit einer Technik treffen zu können – dennoch gilt in der Praxis CORBA häufig als relativ komplex.

Das Ergebnis dieses Abgleichs ergibt, dass die FMG Middlewareinfrastruktur viele Kriterien einer SOA erfüllt, aber zumindest im strengen Sinn (nach der Definition) doch keine ist, da ein wesentliches Merkmal einer SOA, neben der durchgängigen Verwendung eines Verzeichnisdienstes, nämlich die lose Kopplung, fehlt. Zwar werden die Anwendungsmanager, die die Dienste zur Verfügung stellen, aus Redundanzgründen dynamisch an die Anwendung gebunden, allerdings sind die Anwendungen, wie oben ausgeführt wurde, eng an die Anwendungsmanager gekoppelt, womit die FMG Middlewareinfrastruktur die Kriterien einer SOA nicht erfüllt.

Allerdings soll an dieser Stelle nicht der Eindruck erweckt werden, dass die FMG Softwarelandschaft die Kriterien einer SOA erfüllen soll oder gar muss. Vielmehr müsste im Rahmen einer weiteren Forschungsarbeit geklärt werden, ob und wie die FMG von der Umsetzung einer SOA konkret profitieren könnte und welche Umsetzungstechnik ggf. verwendet werden soll. Weitere Gedanken hierzu finden sich im Ausblick dieser Arbeit (Kapitel 7).

4 Web Services Grundlagen

Dieses Kapitel bildet den theoretischen Teil dieser Arbeit. Nachdem der Web Services Begriff definiert wurde, werden Anwendungsgebiete, die Web Services Architektur sowie die Basistechnologien erläutert. Auf die Themen Sicherheit und Leistungsaspekte von Web Services wird jeweils gesondert in einem eigenen Abschnitt eingegangen.

4.1 Definition

Wie dies häufig bei neuen Begrifflichkeiten in der IT ist, existiert bis dato für den Web Services Begriff keine einheitliche, verbindliche Definition – vielmehr existieren zahlreiche Definitionsansätze, die sich im Abstraktionsgrad und der Betonung unterschiedlicher Aspekte des Begriffs unterscheiden. Nachfolgend werden exemplarisch vier Definitionen des Web Services Begriffs zitiert und anschließend analysiert:

„Web services are software components that interact with one another dynamically via standard Internet technologies, making it possible to build bridges between IT systems that otherwise would require extensive development efforts. One of the tenets of Web services is that systems can advertise the presence of business processes, information or tasks that can be consumed by other systems.“ (Gartner Group, Plummer/Andrews/Lombardo 2001)

„A Web service is a self-describing, self-contained software module available via a network, such as the Internet, which completes tasks, solves problems, or conducts transactions on behalf of a user or application. Web services constitute a distributed computer infrastructure made up of many different interacting application modules trying to communicate over private or public networks (including the Internet and Web) to virtually form a single logical system.“ (Papazoglou 2008, 5).

„A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” (W3C 2009).

„Web Services are modular, self-describing applications that can be published, located, and invoked from just about anywhere on the Web or a local network. The provider and the consumer of the XML Web service do not have to worry about the operating system, language environment, or component model used to create or access the XML Web service, as they are based on ubiquitous and open Internet standards, such as XML, HTTP, and SMTP.” (Cauldwell et al. 2001, 19).

Während die ersten beiden Definitionen (Gartner Group und Papazoglou) relativ abstrakt gehalten sind, nennen die letzteren beiden (W3C und Cauldwell et al.) konkrete Basistechniken wie XML, WDSL und SOAP. Bemerkenswert ist dabei, dass das W3C das SOAP-Protokoll direkt mit Web-Services verknüpft, wobei mittlerweile auch alternative Möglichkeiten (z.B. RESTful Web Services) existieren, mit denen Web Services umgesetzt werden können, wenngleich SOAP Web Services nach wie vor weiter verbreitet sind.

Des Weiteren kategorisieren alle vier Definitionen Web Services zwar als Software jedoch im Detail unterschiedlich („software component“, „software module“, „software system“, „applications“). Von einer Anwendung kann bei Web Services aus meiner Sicht keine Rede sein, da Web Services per se erst einmal nur Dienste zur Verfügung stellen. Ein Anwendungsfall ergibt sich daher erst nach Nutzung bzw. Kombination (Orchestrierung) der zur Verfügung stehenden Dienste (evtl. durch Nutzung unterschiedlicher Web Services). Da Web Services somit in aller Regel einen Teil eines Software Systems oder einer Anwendung darstellen, erscheint auch der Begriff Software System als zu allgemein und zu groß gewählt. Software Komponenten und Software Module werden als Teile einer Software verstanden, die eine Schnittstelle nach außen zur Verfügung stellen und passen demnach besser. Die Grenzen zwischen diesen beiden Begriffen sind unscharf und werden in der Praxis häufig auch vermischt, daher kann man auch Web Services nur schwer einer dieser Kategorien mit letzter Sicherheit zuordnen, wie auch die vier vorgestellten Definitionen eindrucksvoll beweisen.

Die vier Definitionen weisen aber auch interessante Gemeinsamkeiten auf, die je nach Definition unterschiedlich konkret ausgedrückt werden. Jede Definition beinhaltet den Aspekt der Interoperabilität, also die Nutzung von Web Services basierend auf allgemein anerkannten, offenen Standards, die unabhängig vor der verwendeten Infrastruktur, des Betriebssystems oder der Programmiersprache sind.

Zudem wird in allen Definitionen mehr oder weniger konkret die Maschine-zu-Maschine Interaktion über ein Netzwerk (meistens das Internet) erwähnt. Der Mensch kann dabei zwar auch Initiator eines Web Service Aufrufs sein, allerdings nutzt er Web Services nur mittelbar, da die eigentliche Interaktion immer zwischen zwei Maschinen stattfindet (Melzer et al. 2008, 55).

Da die Kommunikation bei Web Services über ein Netzwerk aber nicht notwendigerweise über das Internet stattfindet, wäre der Begriff Net Services eigentlich treffender gewesen, allerdings soll sich Bill Gates in einer Telefonkonferenz aus marketingtechnischen Gründen für den Begriff Web Services eingesetzt haben (Melzer et al. 2008, 71).

Wesentlich sind meiner Meinung nach die nachfolgenden drei Kriterien, die Web Services charakterisieren. Diese zeigen auch das Verständnis des Web Service Begriffs in dieser Arbeit:

- Interoperable Kommunikation zwischen meist verteilten, heterogenen IT-Systemen.
- Maschine-zu-Maschine Kommunikation – die Daten, die übertragen werden, sind zur Verarbeitung (auch semantisch) durch Maschinen bestimmt.
- Basieren auf Internet-Technologien (meist HTTP und XML).

4.2 Anwendungsgebiete

Im Allgemeinen können Web Services überall dort ihre Stärke ausspielen, wo heterogene Software-Systeme, die häufig noch verteilt sind, miteinander kommunizieren und interagieren müssen, um Transaktionen durchzuführen oder Daten auszutauschen. Heterogene Software-systeme trifft man häufig innerhalb großer Unternehmen an, die eine Vielzahl von Anwendungen nutzen und/oder deren Softwarelandschaft historisch gewachsen ist. Bei der Kommunikation von Softwaresystemen zwischen Unternehmen hat man es dagegen mit fast an Sicherheit grenzender Wahrscheinlichkeit mit heterogenen Softwarelandschaften zu tun, sobald mehr als zwei, drei Unternehmen im Spiel sind.

Während man heterogene Systeme innerhalb eines Unternehmens noch mit einer (evtl. proprietären) Middleware verzahnen kann, bleibt zwischen Unternehmen häufig nur noch die Nutzung offener Standards als einzige Lösungsmöglichkeit, um die Komplexität und den Aufwand in akzeptablen Grenzen zu halten. Genau hier kommen nun Web Services ins Spiel, die die Kommunikation über Unternehmensgrenzen hinweg unterstützen und auf offenen Standards basieren.

4.2.1 Web Services als RPC

Nachfolgend werden einige konkrete Beispiele für Web Services angeführt, die dem klassischen Remote Procedure Call (RPC) entsprechen:

- Innerhalb eines Unternehmens
- Verzahnung des Online Shops eines Unternehmens mit dem SAP-System, um Kundendaten und Bestellungen über den Online Shop automatisch ins SAP-System zu übertragen.
- Neue GUI-Anwendung, die bei einer Interaktion des Benutzers eine Transaktion in einem Alt-System anstößt.
- Zwischen Unternehmen entlang der Supply-Chain (B2B)
- Berechnung der Versandkosten eines bestimmten Paketdienstes (z.B. UPS) anhand eines bestimmten Warenkorbs in einem Online Shop für eine bestimmte Versandadresse.
- Datenaustausch zwischen Unternehmen am Beispiel von MTM

MTM ist ein Unternehmen, das sich auf das Tuning und die Veredelung von Serienfahrzeugen der Volkswagengruppe spezialisiert hat. Die MTM-Produkte für jedes Fahrzeug sind auf der Unternehmenswebsite (http://www.mtm-online.de) abrufbar. Zusätzlich hat MTM noch ein weltweites Importeurs- und Händlernetzwerk aufgebaut, die auf die Produktdaten ebenfalls per Web Services direkt zugreifen können. Damit ist es u.a. möglich, dass die Importeure die MTM-Produkte direkt auf ihrer Website anzeigen können. Da nur reine Daten über die Web Services übertragen werden, kann das Look & Feel frei gestaltet und damit die jeweilige Corporate Identitiy berücksichtigt werden (Trennung von Inhalt und Präsentation). Aufgrund der direkten Anbindung an den MTM Server, entfallen aufwendige Datenbankspiegelungen wodurch Dateninkonsistenzen vermieden werden können.

Nachfolgend finden sich zwei Abbildungen in Form von Screenshots, die einen Ausschnitt aus der MTM-Produktübersicht für den Audi A5 (Basismotorisierung: 3,0 TDI 176 kW Quattro) zeigen. Der erste Screenshot zeigt die Produktübersicht auf der offiziellen Website (http://www.mtm-online.de), der zweite Screenshot zeigt die gleiche Produktübersicht auf der Website des österreichischen Importeurs Sperrer Motorsports (http://www.sperrer.at), die mittels Web Services geholt und angezeigt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: MTM Produktübersicht: Audi A5 3,0 TDI 176 kW (240PS) Quattro

Quelle: (MTM 2009)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Sperrer Produktübersicht: Audi A5 3,0 TDI 176 kW (240PS) Quattro

Quelle: (Sperrer 2009)

- Anbindung allgemein zugänglicher Informationsquellen

- Wetterdaten^[7]
- Währungsumrechnungskurse^[8]
- Viele weitere Web Services (siehe http://www.webservicelist.com)

Das bislang beschriebene Szenario beschreibt aber nur einen Teil der Anwendungsgebiete von Web Services, nämlich denjenigen, der im Wesentlichen dem klassischen Remote Procedure Call (RPC) entspricht.

4.2.2 Web Services als Umsetzung einer SOA

Web Services wurden aber auch als Implementierungsmöglichkeit einer SOA entworfen, die u.a. das Auffinden, die dynamische Bindung und die Nutzung von Services jeweils zur Laufzeit fordert. Um diese Forderung umsetzen zu können, ist ein Verzeichnisdienst notwendig, der die verfügbaren Services registriert und damit überhaupt erst auffindbar macht (Melzer et al. 2008, 11). Mittels einer Beschreibungssprache (z.B. WS-BPEL) können sogar ganze Geschäftsprozesse modelliert und abgearbeitet werden, indem einzelne, verfügbare Services in der gewünschten Ausführungsreihenfolge orchestriert werden.

Nachfolgend sind wiederum Beispiele für dieses Szenario aufgeführt:

- Innerhalb eines Unternehmens

Die Deutsche Bank hat den Neukundenprozess, der zu den Kernprozessen im Privatkundengeschäft zählt, in einem zweijährigen Projekt (2006 bis 2008) namens „Orinoco“ SOA konform gestaltet. Ziel war es, die Anlage eines Neukunden zu standardisieren, um eine automatische Abarbeitung mittels eines Workflows, der wiederverwendbare Services nutzt, zu erreichen. Christian Schmidt, Leiter der Abteilung Cross Business Services: „Mit Orinoco wollten wir zeigen, dass die IT in der Lage ist, die immer volatileren Business-Anforderungen optimal zu erfüllen.“ (Herrmann 2009).

- Zwischen Unternehmen entlang der Supply-Chain (B2B)

Unternehmen, die bei Planung oder Durchführung ihrer Geschäftsprozesse auf die Dienste von Partnerunternehmen angewiesen sind, können ihre Geschäftsprozesse durch die Nutzung der von den Partnerunternehmen im Rahmen eines Verzeichnis-dienstes zur Verfügung gestellten Services automatisieren. Beispielsweise wäre bei Airlines die Flugplanung ein solcher Prozess, der auf mehrere Partner angewiesen ist. Unter anderem müssen beim Abflug- und Zielflughafen entsprechende Slots und Stellplätze gebucht werden. Weiterhin muss u.a. ein Abfertiger und evtl. ein Cateringunternehmen ausgewählt und gebucht werden. Um all diese Aufgaben automatisieren zu können, ist man auf Services der Partner angewiesen. Zugegebenermaßen erscheint die Realisierung eines solchen vollautomatisierten Prozesses mit mehreren Partnern derzeit noch zu komplex, da dafür alle Partner eine Service-orientierte Architektur zur Verfügung stellen müssten, die noch dazu von außen genutzt werden kann. Allerdings kann auch festgehalten werden, dass es mithilfe von Web Services grundsätzlich denkbar wäre, einen solchen Prozess vollautomatisiert umzusetzen.

4.3 Web Services Architektur

Für die Implementierung einer SOA, die auf Web Services basiert, ist man auf einige Basistechnologien angewiesen. Beispielsweise ist ein Kommunikationsprotokoll (z.B. SOAP) notwendig, um zwischen zwei Endpunkten Nachrichten austauschen zu können. Des Weiteren muss ein Web Service beschrieben werden können (WSDL), damit potenzielle Nutzer in der Lage sind, herausfinden zu können, wie sie den Web Service aufrufen können und welche Operationen bzw. Datentypen er zur Verfügung stellt. Um überhaupt die gewünschten Web Services auffinden zu können, ist zudem ein Verzeichnisdienst (UDDI) notwendig, der das Veröffentlichen und die Suche nach Web Services ermöglicht. Die folgende Abbildung zeigt das Web Services Dreieck, das die Rollen und die Interaktionsreihenfolge beim Veröffentlichen, Suchen und Nutzen eines Web Services anschaulich darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Web Services Dreieck

Quelle: (Melzer et al. 2008, 56)

In dieser Abbildung sind drei verschiedene Rollen dargestellt:

- Dienstanbieter (bietet einen Dienst an und agiert als Server/Provider)
- Dienstnutzer (will einen Dienst nutzen und agiert als Client/Consumer)
- Dienstverzeichnis (verwaltet Dienstbeschreibungen und -verweise und stellt eine Suchfunktion bereit – kann mit den gelben Seiten verglichen werden)

Die Interaktionsreihenfolge gestaltet sich wie folgt:

1. Der Dienstanbieter registriert einen Dienst im Dienstverzeichnis (UDDI), indem er die Dienstbeschreibung als WSDL an das Dienstverzeichnis schickt – zuvor muss der Dienst natürlich verfügbar gemacht worden sein (engl. deployed).
2. Der Dienstnutzer sucht nun nach dem gewünschten Dienst im Dienstverzeichnis, indem er an das Dienstverzeichnis eine entsprechende SOAP-Nachricht schickt. Die Suche basiert dabei meist auf Taxonomien oder Ontologien.
3. Bei erfolgreicher Suche bekommt der Dienstnutzer die Dienstbeschreibung zurück, die einen Verweis auf den gefundenen Dienst enthält.
4. Der Dienstnutzer versucht den Dienst jetzt beim Dienstanbieter direkt aufzurufen. Meistens werden vor der eigentlichen Nutzung des Dienstes noch die Bedingungen der Nutzung ausgehandelt (z.B. Authentifizierung, QoS-Vereinbarungen, etc.).
5. Nach erfolgreicher Verhandlung konsumiert der Dienstnutzer den vom Dienstanbieter zur Verfügung gestellten Dienst.

Wenn der Dienstnutzer den Dienstanbieter kennt, kann die Suche über das Dienstverzeichnis ausbleiben. Allerdings geht dadurch auch die lose Kopplung verloren, die von einer SOA verlangt wird. (Melzer et al. 2008, 14 ff.)

In der folgenden Abbildung sind die von Web Services benötigten Technologien und Spezifikationen im sogenannten Web Services Stack dargestellt. (Papazoglou 2008, 33 ff.).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Web Services Stack

Quelle: (Papazoglou 2008, 33)

Auf der untersten Ebene des Web Services Stacks befindet sich die Transportschicht (befindet sich oberhalb des TCP/IP Stacks) mit Transportprotokollen wie HTTP, JMS, SMTP oder auch FTP und IIOP die hier nicht abgebildet sind, welche allesamt auf das Transportprotokoll TCP sowie das Netzwerkprotokoll IP aufbauen. Obwohl Web Services nicht an ein spezielles Transportprotokoll gebunden sind, hat sich HTTP, das auch im World Wide Web benutzt wird, als Protokoll etabliert, nicht zuletzt aufgrund der Eigenschaft, dass der Standardport dieses Protokolls Port 80 ist und damit Durchlässigkeitsprobleme an der Firewall von vornherein vermieden werden, da Port 80 in der Standardkonfiguration der meisten Firewalls durchlässig ist.

Sowohl die Nutzdaten einer Nachricht selbst, als auch praktisch alle Web Service Technologien (SOAP, WSDL, UDDI, WS-BPEL, WS-CDL) basieren auf XML, das ein allgemein akzeptiertes Format für die Datenübertragung darstellt. In Abschnitt 4.4.1 wird detailliert auf XML eingegangen.

Die darüber liegenden drei Ebenen SOAP, WSDL und UDDI bilden den Kern der Web Service Technologien. SOAP ist ein XML-basiertes Nachrichtenprotokoll, auf das Web Services angewiesen sind, um Nachrichten austauschen zu können. Es ist unabhängig vom verwendeten Transportprotokoll. Für die Beschreibung von Web Services wird die Web Service Description Language (WSDL) eingesetzt, die als Schnittstellenbeschreibungssprache fungiert. In einer WSDL-Beschreibung werden beispielsweise verfügbare Operationen und Datentypen sowie das verwendete Transportprotokoll und der Endpunkt, an dem der Web Service aufgerufen werden kann, spezifiziert. Um eine lose Kopplung realisieren zu können, müssen Web Services (genauer die Web Service Beschreibung – also WSDL) in einem öffentlichen Verzeichnis registriert und aufgefunden werden können. Um genau diesen Aspekt kümmert sich die Universal Description, Discovery and Integration (UDDI). Im Detail werden diese drei Basistechnologien in den Abschnitten 4.4.2 bis 4.4.4 erläutert.

Damit Web Services verlässlich genutzt werden können, müssen diese eine Reihe von Quality of Service (QoS) Anforderungen erfüllen. Diese werden in Service-Level-Agreements (SLAs) festgeschrieben, die auch heutzutage noch in den wenigsten Fällen automatisiert ausgehandelt werden (Melzer et al. 2008, 158), obwohl es dafür bereits Lösungsansätze gibt (vgl. Waltl/Hyldetoft 2008). Zu den wichtigsten QoS-Anforderungen in Bezug auf Web Services zählen nach (Mani/Nagarajan 2002):

- Verfügbarkeit (Grad für die Bereitschaft eines Web Service zur sofortigen Nutzung)
- Erreichbarkeit (Grad für die Instaziierbarkeit eines Web Service – ein Web Service kann zwar verfügbar aber nicht erreichbar sein, wenn beispielsweise zu viele Clients gleichzeitig zugreifen)
- Integrität (Grad, in dem ein Web Service eine Interaktion korrekt gemäß WSDL/SLAs abwickelt)
- Leistung (Durchsatz und Latenz eines Web Service)
- Verlässlichkeit (Grad zu dem ein Web Service die geforderte Dienstqualität erfüllen kann – wird in Transaktionsfehlern pro Monat oder Jahr gemessen)
- Regeleinhaltung (Einhaltung von Regeln, Gesetzen und Standards)
- Sicherheit (Vertraulichkeit, Authentifizierung, verschlüsselte Übertragung)

Um die verschiedenen QoS-Anforderungen zu adressieren, wurden zahlreiche WS-* Spezifikationen entworfen, auf die in Abschnitt 4.4.6 näher eingegangen wird.

Auf den obersten beiden Ebenen befinden sich zwei Spezifikationen, mit denen ganze Geschäftsprozesse auf Basis von Web Services (evtl. über Unternehmensgrenzen hinweg) abgebildet werden können. Dazu können mehrere Web Services orchestriert (WS-BPEL) und koordiniert (WS-CDL) werden. Ein Geschäftsprozess basierend auf Web Services gleicht dann einem Ablaufplan (engl. Workflow) von Methodenaufrufen, der u.a. auch Verzweigungen, Schleifen, Parallelität und die Behandlung von Ausnahmen unterstützt, damit auch die Geschäftslogik in einem Geschäftsprozess abgebildet werden kann. In Abschnitt 4.4.5 wird auf die ebenfalls XML-basierte Orchestrierungssprache WS-BPEL noch näher eingegangen. Auf eine detaillierte Erläuterung von WS-CDL wird aus Gründen des Umfangs sowie der untergeordneten Relevanz für die Erfüllung der Ziele dieser Arbeit verzichtet.

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 (W3C 1998). Mittlerweile liegt XML in der fünften Ausgabe vom 26. November 2008 vor. Zu den wichtigsten Entwurfszielen von XML zählen (W3C 2008a):

- 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 (Vonhoegen 2007, 30 f.), (Wittenbrink et al. 2003, 43 ff.):

- 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)

[...]

^[1] EBITDA exkl. Leasingaufwand Gebäude 44 Mio. € 2008 (2007: 50 Mio. €), EBIT exkl. Zinsanteil Leasing

^[2] Ergebnisse exkl. Rückstellungen für Ground Handling 31,3 Mio. € 2008 (2007: 20,0 Mio. €)

^[3] Konzern-Jahresüberschuss exkl. Zinsen für Gesellschafterdarlehen 43,5 Mio. € 2008 (2007: 0,- €) ohne Berücksichtigung von Steuereffekten

^[4] 1989 gegründetes Konsortium der Computerindustrie mit mehreren hundert Mitgliedern. Zu den veröffentlichten Standards gehören u.a. CORBA, MDA und UML (OMG 2009b).

^[5] Common Data Representation: Für die Datenübertragung optimiertes binäres Format.

^[6] Namen müssen folgender Konvention entsprechen: <Mandant>.<Arbeitsgebiet>.<Annwendungsname><Manager|Adapter> Beispiele: fmg.lk04.GepaeckManager, fmg.lf15.SitaAdapter

^[7] http://www.webservicex.net/WeatherForecast.asmx?wsdl

^[8] http://www.webservicex.net/CurrencyConvertor.asmx?wsdl