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

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

4.11 - 1251 ratings - Source



Inhaltsangabe:Einleitung: 1, EinfA¼hrung in die Thematik: Der Hype um Service-orientierte Architekturen (SOA) und Web Services ist lAcngst vorA¼ber. Mittlerweile gibt es sogar IT-Experten und Analysten wie Anne Thomas Manes von der Burton Group, die in ihrem Blog-Eintrag SOA bereits fA¼r tot erklAcrt hat, weil viele SOA-Projekte in der Vergangenheit gescheitert oder zumindest nicht erfolgreich gewesen sind. Des Weiteren wird von Kritikern zu Recht angefA¼hrt, dass die an SOA gestellten Erwartungen, wie zum Beispiel die Senkung der IT-Kosten, die Wiederverwendbarkeit von Services oder die AgilitAct, oftmals nicht erfA¼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 UniversitAct 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 jAchrlich die IT-Trends einordnet, wird deutlich, dass sowohl der Hype um SOA als auch das Tal der ErnA¼chterung vorA¼ber ist. Im Hype Cycle 2008 und 2009 befindet sich SOA auf dem Weg der Erkenntnis. Nach etwa zwei bis fA¼nf Jahren ist laut Gartner mit einer produktiven Nutzung zu rechnen. Im SOA-Umfeld haben sich Web Services als hAcufigste Umsetzungstechnik einer SOA durchgesetzt (BSI 2009). Im IT Hype Cycle 2008 werden Web Services dem Plateau der ProduktivitAct zugeordnet und werden sich in weniger als zwei Jahren in den Unternehmen etabliert haben. Die theoretischen Grundlagen und Basistechnologien fA¼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 bemAcngeln Kritiker fehlende Sicherheitsfunktionen sowie mangelnde Leistung gegenA¼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 groAŸen StAcrken von Web Services zAchlen die PlattformunabhAcngigkeit, 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 MA¼nchen GmbH (FMG) erstellt. Die FMG prA¼ft derzeit, ob und wie Web Services in ihrer bestehenden IT-Landschaft am besten eingesetzt werden kApnnen, um damit im ersten Schritt externe Partner anzubinden. Dabei sind die Anforderungen in Bezug auf Sicherheit, VerfA¼gbarkeit und Leistung A¼berdurchschnittlich. Die IT-Architektur der FMG basiert auf einer CORBA Middlewareinfrastruktur, die in Kapitel 3 nAcher vorgestellt wird. Im Rahmen dieser Arbeit soll eine LApsung konzeptioniert und implementiert werden, um externen Partnern der FMG (z.B. Abfertiger, Airlines, Medien) eine Web Service Schnittstelle zur VerfA¼gung stellen zu kApnnen, auf deren Basis Flugdaten abgerufen werden kApnnen. Des Weiteren soll mithilfe der implementierten LApsung eine real existierende Schnittstelle auf Basis von Web Services umgesetzt werden, um die Praxistauglichkeit der Implementierung zu beweisen. 1.1, Ausgangssituation: Fast alle groAŸen Unternehmen hatten oder haben immer noch mit einer sehr heterogenen Softwarelandschaft zu kAcmpfen, die historisch gewachsen ist. FrA¼her war es A¼blich fA¼r jeden Funktionsbereich (z.B. Einkauf, Verkauf, Produktion) speziell auf diese Bereiche zugeschnittene Applikationen zu entwickeln ohne dabei unbedingt auf InteroperabilitAct mit anderen Applikationen zu achten. Um den Datenaustausch zwischen diesen Applikationen dennoch zu ermApglichen, wurde hAcufig eine Unzahl von Schnittstellen zwischen diesen Applikationen manuell entwickelt (Point to Point Integration), die im Laufe der Zeit aufgrund der Anzahl und SpezifitAct nicht mehr beherrschbar waren. Wenn man sich mit der LApsung dieses Problems auseinandersetzt, stApAŸt man unweigerlich auf das Schlagwort Enterprise Application Integration (EAI). Es existieren zahlreiche, unterschiedliche Definitionen zu diesem Begriff exemplarisch sei hier eine Definition aufgefA¼hrt: Die Kernidee der Enterprise Application Integration (EAI) ist es, eine zentrale Plattform bereitzustellen, welche Applikationen A¼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 unternehmensA¼bergreifend betrachtet werden kann. FA¼r die technische Integration setzt man hAcufig 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 A¼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 A¼bermittelten Daten hAcufig 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 A¼ber Unternehmensgrenzen hinweg) aufbaut, bezeichnet man meist als Message Broker. Der Datenstrom wird in Unternehmen, wie dies auch bei der FMG der Fall ist, hAcufig 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 FunktionalitAct wie eine Message-oriented Middleware zur VerfA¼gung. Sie bietet jedoch in aller Regel darA¼ber hinaus noch einige Zusatzfunktionen wie Datentransformation (z.B. Datentypen unterschiedlicher Programmiersprachen), ProtokollunabhAcngigkeit, Intelligentes Routing, Implementierung der SOA-Standards sowie im Gegensatz zu einigen Middleware LApsungen 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 vielfAcltige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste reprAcsentiert und dadurch eine plattform- und sprachenunabhAcngige Nutzung und Wiederverwendung ermApglicht. 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, zerfAcllt . Wie bereits erwAchnt wurde, stellen Web Services eine MApglichkeit dar, eine SOA umzusetzen. Web Services werden ausfA¼hrlich in Kapitel 4 dieser Arbeit behandelt. Inhaltsverzeichnis:Inhaltsverzeichnis: VorwortIII ZusammenfassungIV AbbildungsverzeichnisVIII TabellenverzeichnisX AbkA¼rzungsverzeichnisXI 1.EinfA¼hrung in die Thematik1 1.1Ausgangssituation2 1.2Kurzvorstellung der Flughafen MA¼nchen GmbH4 1.3Problemstellung8 1.4Ziele und Aufbau der Arbeit9 2.Anforderungsermittlung11 2.1Akteure12 2.2Szenarien13 2.3AnwendungsfAclle13 2.4Funktionale Anforderungen21 2.5Nichtfunktionale Anforderungen23 3.FMG Middlewareinfrastruktur25 3.1Anforderungen an die Verkehrssysteme der FMG25 3.2Historische Entwicklung der FMG Middlewareinfrastruktur26 3.3CORBA27 3.4CORBA-Softwarekomponenten in der FMG Middlewareinfrastruktur30 3.5Abgleich der SOA-Merkmale in der FMG-Middlewareinfrastruktur33 4.Web Services Grundlagen35 4.1Definition35 4.2Anwendungsgebiete36 4.2.1Web Services als RPC37 4.2.2Web Services als Umsetzung einer SOA40 4.3Web Services Architektur40 4.4Basistechnologien und Spezifikationen44 4.4.1XML44 4.4.2SOAP47 4.4.3WSDL51 4.4.4UDDI55 4.4.5GeschAcftsprozessmodellierung: WS-BPEL und WS-CDL56 4.4.6WS-*58 4.4.7REST63 4.5Sicherheitsaspekte von Web Services67 4.5.1Sicherheitsprobleme beim Einsatz von Web Services69 4.5.2WS-Security71 4.5.3Web Service Firewall75 4.6Leistungsaspekte von Web Services77 4.6.1Einflussfaktoren auf die Leistung von Web Services77 4.6.2Leistungsvergleich: SOAP Web Services vs. CORBA78 5.Konzeption und Implementierung der FMG Web Service Schnittstelle83 5.1Ziele der FMG Web Service Schnittstelle83 5.2Software Product Line Engineering83 5.2.1Domain Engineering84 5.2.2Application Engineering85 5.2.3Software Product Lines bei der FMG Web Service Schnittstelle86 5.3Analyse88 5.3.1Objektmodell88 5.3.2Dynamisches Modell90 5.4Systementwurf92 5.4.1Integration in die FMG Softwarelandschaft92 5.4.2Kommunikationsmodelle96 5.4.3Entwurfsziele98 5.4.4Systemzerlegung99 5.4.5Realisierung der Entwurfsziele110 5.4.6Abbildung der Subsysteme auf Hardware und Software110 5.4.7Identifizierung und Speicherung von persistenten Daten113 5.4.8Einrichtung von Zugriffsrechten114 5.4.9Entwurf des globalen Kontrollflusses114 5.4.10Identifizierung von Randbedingungen116 5.5Objektentwurf118 5.5.1Objektmodell der Web Service Konfiguration118 5.5.2Objektmodell der Web Service Domain120 5.6Implementierung131 5.7Reales Beispiel: Skytanking Flugdatenschnittstelle132 5.7.1Beschreibung der Schnittstelle132 5.7.2Umsetzung135 5.7.3Leistungstest139 6.Ergebnisse der Arbeit143 6.1Ergebnisse von allgemeinem Interesse143 6.2Ergebnisse von speziellem Interesse seitens der FMG149 7.AbschlieAŸende Betrachtung und Ausblick153 Literaturverzeichnis155 Anhang165 Anhang AGlossar166 Anhang BXML und XML Schema Details167 Anhang CUDDI Datenmodell und API173 Anhang DWS-* Spezifikationen: WS-Addressing und WS-Notification177 Anhang EXML-Signature, XML-Encryption, SAML, XACML183 Textprobe: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, nAcher erlAcutert. 4.4.1, XML: Die eXtensible Markup Language (XML) ging aus SGML hervor und hat sich als Auszeichnungssprache fA¼r den elektronischen Datenaustausch A¼ber Netzwerke (v.a. das Internet) etabliert. Die erste Spezifikation mit Empfehlungsstatus dieser Sprache stammt aus dem Jahre 1998. Mittlerweile liegt XML in der fA¼nften Ausgabe vom 26. November 2008 vor. Zu den wichtigsten Entwurfszielen von XML zAchlen: XML soll unkompliziert im Internet verwendet werden kApnnen. XML soll ein breites Spektrum von Anwendungen unterstA¼tzen. XML soll zu SGML kompatibel sein. Es soll einfach sein, Programme zu schreiben, die XML Dokumente verarbeiten. XML-Dokumente sollen fA¼r Menschen lesbar und angemessen verstAcndlich sein. Der Entwurf von XML soll formal und prAczise 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 gleichermaAŸen gut lesbar bzw. verarbeitbar sein sollen. Demnach kApnnen XML Dokumente keine binAcren Daten enthalten, sondern bestehen aus reinem Text mit einer eindeutigen Kodierung. Ein Kritikpunkt, der bei XML immer wieder angefA¼hrt wird, ist die GesprAcchigkeit von XML, sodass die GrApAŸe von XML-Dokumenten recht groAŸ gegenA¼ber binAcren Dateien ist, die die gleiche Information transportieren. Der Grund fA¼r diese GesprAcchigkeit ist auch in den Entwurfszielen zu finden. Lesbarkeit und VerstAcndlichkeit sind demnach wichtiger als die Knappheit. Durch Kompression gibt es aber dennoch MApglichkeiten 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. FA¼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 (AœberprA¼fung von XML-Dokumenten auf Einhaltung des Schemas). Verschachtelung (Abbildung hoch komplexer Hierarchien jeder Art mApglich). Offener Standard (Freie Verwendbarkeit, Standardisierung durch W3C). XML ist aber nicht nur eine reine Auszeichnungssprache fA¼r den Datenaustausch. XML fungiert darA¼ber hinaus auch als Metasprache fA¼r eine ganze Reihe von Sprachen, deren Syntax auf XML basiert. Dazu wird der jeweilige Befehlssatz in Tags abgebildet. Bekannte Beispiele aus verschiedenen Themengebieten fA¼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 grundsActzliche Aufbau eines XML-Dokuments bekannt sind. Eine ErklAcrung dieser Begriffe findet sich im Anhang unter B.1 und B.2. XML-Fachbegriffe: Nachfolgend werden die wichtigsten XML-Fachbegriffe erlAcutert. Wohlgeformtheit: Ein XML-Dokument heiAŸt wohlgeformt (engl. well-formed), wenn es alle folgenden XML-Regeln erfA¼llt: Vor der XML-Deklaration dA¼rfen keine Leerzeichen verwendet werden. Jedes XML-Dokument muss genau ein Wurzelelement enthalten, das alle anderen Elemente beinhaltet. Jedes Element muss A¼ber einen Start-Tag und End-Tag verfA¼gen. Es dA¼rfen sich keine Tags A¼berlappen, wie das im folgenden Beispiel fehlerhaft dargestellt ist: Es wird zwischen GroAŸ- und Kleinschreibung unterschieden. Dies bedeutet, dass Start- und End-Tag exakt gleich geschrieben werden mA¼ssen. Die Namensgebung von Elementen und Attributen muss den entsprechenden Regeln folgen. Attribute dA¼rfen nur in einem Start-Tag vorkommen und mA¼ssen eindeutig sein. GA¼ltigkeit: Wenn ein XML-Dokument wohlgeformt ist, heiAŸt das noch lange nicht, dass es auch gA¼ltig (engl. valid) ist. WAchrend Wohlgeformtheit nur ausdrA¼ckt, dass ein XML-Dokument AcuAŸerlich syntaktisch korrekt ist, kApnnen bei der PrA¼fung auf GA¼ltigkeit eines XML-Dokuments wesentlich strengere Regeln validiert werden. Ein XML-Dokument heiAŸt gA¼ltig, wenn es ein vorgegebenes Schema (z.B. DTD oder XML-Schema) erfA¼llt. Bevor ein XML-Dokument auf GA¼ltigkeit A¼berprA¼ft wird, muss es die PrA¼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 dA¼rfen. Auch wenn ein XML-Dokument wohlgeformt und gA¼ltig ist, muss es noch nicht richtig sein. Wenn ein Schema beispielsweise vorgibt, dass eine Adresse mit StraAŸe, PLZ und Ort eingegeben werden muss, dann prA¼ft die GA¼ltigkeitsprA¼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 RealitAct 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 unterstA¼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 kApnnen ein XML-Dokument auf die Einhaltung der Regeln einer DTD oder eines XML-Schemas prA¼fen. Des Weiteren unterscheidet man zusActzlich zwischen SAX- und DOM-Parsern. SAX-Parser durchlaufen das XML-Dokument einmal und erzeugen dabei Ereignisse, fA¼r die Callback-Funktionen registriert werden kApnnen 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 kApnnen. WAchrend beim SAX-Parser nach einem Durchlauf das XML-Dokument nicht mehr zur VerfA¼gung steht, bleibt das Dokument beim DOM-Parser im Speicher erhalten. Dadurch kann der Baum auch nachtrAcglich noch beliebig ausgelesen bzw. manipuliert werden. Dies fA¼hrt jedoch zu erhAphtem Speicherbedarf (v.a. bei groAŸen XML-Dokumenten) im Vergleich zu SAX-Parsern. Zudem sind SAX-Parser in aller Regel schneller als DOM-Parser. Mit StAX existiert darA¼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 A¼ber einen Iterator aktiv an (Pull Modell). XML-Schema: FA¼r die Beschreibung von Strukturen und Regeln eines XML-Dokuments (Achnlich einer Grammatik, in der Regeln definiert sind, mit denen zwischen gA¼ltigen und ungA¼ltigen SActzen unterschieden werden kann) werden Schemasprachen eingesetzt. Wird einem XML-Dokument ein Schema hinzugefA¼gt, dem es folgen soll, so kann die GA¼ltigkeit dieses XML-Dokuments mit validierenden XML-Prozessoren A¼berprA¼ft werden. Zur Beschreibung eines Schemas haben sich in den Anfangsjahren von XML die Dokument-Typdefinitionen (DTDs) durchgesetzt, die noch bis heute in vielen FAcllen eingesetzt werden. Allerdings ist die MAcchtigkeit von DTDs zur Beschreibung eines Schemas begrenzt (z.B. unzureichende UnterstA¼tzung von Datentypen oder Wertebereichen). Des Weiteren folgen DTDs nicht der XML-Syntax, sodass beispielsweise ein Zugriff A¼ber DOM nicht mApglich ist. Da sich XML fA¼r den Datenaustausch im B2B-Bereich etabliert hat, musste fA¼r diese Probleme eine LApsung gefunden werden, die allerdings A¼ber drei Jahre nach der ersten Spezifikation von XML mit Empfehlungsstatus auf sich warten lieAŸ. Am 2. Mai 2001 verApffentlichte das W3C schlieAŸlich die erste Spezifikation von XML-Schema mit Empfehlungsstatus, welche die Defizite von DTDs adressierte. XML-Schema ist aber nicht nur fA¼r die Schemadefinition beim Datenaustausch nA¼tzlich - praktisch alle XML-basierten Sprachen stellen fA¼r den erlaubten Sprachumfang ein passendes XML-Schema zur VerfA¼gung, so auch die fA¼r Web Services wichtigen Technologien SOAP, WSDL und BPEL. Details zu XML Schema kApnnen im Anhang B.3 nachgelesen werden.SAcmtliche Web Service Schnittstellen sowie die Web Service Bibliothek werden in der Programmiersprache Java ... Metro 1.1.5 besteht im Wesentlichen aus den folgenden drei Teilen (Heuser/Holubek 2010, 34): JAX-WS RI 2.1.3 JAX-WSanbsp;...


Title:Anwenderunabhängige Flugdatenschnittstelle basierend auf Web Services am Beispiel der Flughafen München GmbH
Author: Andreas Waltl
Publisher:Diplomarbeiten Agentur - 2010-09-05
ISBN-13:

You must register with us as either a Registered User before you can Download this Book. You'll be greeted by a simple sign-up page.

Once you have finished the sign-up process, you will be redirected to your download Book page.

How it works:
  • 1. Register a free 1 month Trial Account.
  • 2. Download as many books as you like (Personal use)
  • 3. Cancel the membership at any time if not satisfied.


Click button below to register and download Ebook
Privacy Policy | Contact | DMCA