Bachelor + Master Publishing
810 Bachelorarbeiten, 531 Masterarbeiten, 10.101 Diplomarbeiten

Anwendungsintegration durch Webservices

Anwendungsintegration durch Webservices
Über dieses Buch
  • Art: Diplomarbeit
  • Autor: Benjamin Krischer
  • Abgabedatum: Juni 2002
  • Umfang: 107 Seiten
  • Dateigröße: 1,6 MB
  • Note: 2,0
  • Institution / Hochschule: Philipps-Universität Marburg Deutschland
  • ISBN (eBook): 978-3-8324-5892-8
  • ISBN (Paperback) :
    978-3-8324-5892-8 P
  • ISBN (CD) :978-3-8324-5892-8 CD
  • Sprache: Deutsch
  • Prämierung:
  • Arbeit zitieren: Krischer, Benjamin Juni 2002: Anwendungsintegration durch Webservices, Hamburg: Diplomica Verlag
  • Schlagworte: Middleware, EAI, IEI, Web Service, Integration

Diplomarbeit von Benjamin Krischer

Einleitung:

Wenn sich IT-Systeme heutzutage nicht schnell genug an neue Unternehmensstrategien oder Rahmenbedingungen anpassen können lähmen sie den Betrieb. Eine schnelle Reaktionsfähigkeit ist demnach unabdingbar – permanent entstehen neue Märkte, die Nachfrage ändert sich, neue Services entstehen. Es gilt, den Spagat zwischen möglichst hoher Flexibilität und Unterstützung des laufenden Geschäftsbetriebs zu bewältigen.

Architekturen müssen dazu wandlungsfähig sein, heutige Systeme verfügen jedoch nur sehr begrenzt über die geforderte Beweglichkeit.

Die zunehmende Vernetzung von Unternehmen verlangt eine Kooperation von IT-Systemen in ständig wechselnden Kombinationen. Dabei richtet sich das Interesse zunehmend auf die Integration mit Geschäftspartnern, problematisch daran ist aber, dass bis zu 80% unternehmensinterner Systeme bisher noch nicht online fähig sind und ein stark wachsendes Bedürfnis besteht, diesen Zustand zu ändern. Insbesondere der E-Business Bereich begünstigt solche Anliegen und mit dessen Hilfe eröffnen sich weltweit neue Perspektiven für Unternehmen aller Branchen und Größen.

Leistungsfähigkeit und Geschwindigkeit der digitalen Datenübertragung machen es möglich, auf Anforderungen und Präferenzen der einzelnen Kunden und Partner schneller und wirksamer eingehen zu können als jemals zuvor, was von sinkenden Kosten für Hardware und Bandbreite unterstützt wird. Konsequenz ist, dass Geschäftsprozesse gegenwärtig nicht mehr an eigenen Unternehmensgrenzen enden,sondern darüber hinausgehen und eine Vielzahl an Geschäftspartnern miteinbinden.

Für die Realisierung dieses Vorhabens sind mächtige Integrationswerkzeuge erforderlich, damit auf die sich kontinuierlich ändernden Anforderungen flexibel reagiert werden kann. Deren Effizienz und Effektivität ist, besonders beim unternehmensübergreifendem Austausch von Geschäftsinformationen, vom Standardisierungsgrad der verwendeten Verfahren abhängig. Auch wenn zwischenbetrieblicher Informationsaustausch seit langem technisch realisierbar ist, basiert dieser zumeist auf proprietären Verfahren und ist mit hohem Aufwand verbunden.

So genannte Webservices (WS) die im Mittelpunkt der diesjährigen Cebit standen, könnten ein adäquates Werkzeug sein, um diese Trends einfacher als bisher unter Nutzung ubiquitärer Standards umzusetzen. Die WS-Technologie verspricht eine intelligentere Nutzung des Internets: Bislang sind dort vor allem Daten auf Webseiten verknüpft, WS sollen einen Schritt weitergehen und neben den Daten auch Programme vernetzen.

Einige Analysten vergleichen die Entwicklung von WS mit dem Übergang von maschinennaher Assembler Programmierung auf Programmiersprachen der 4. Generation oder mit dem Schritt von MS-DOS zu Windows. Weitere Argumente für den Einsatz von WS liefern die Auguren der Gartner Group: Sie gehen davon aus, dass WS im Jahr 2004 die dominante Softwarearchitektur verkörpern werden. Diese Aussagen verdeutlichen die großen Hoffnungen und Erwartungen in die neue Technologie.

Ziel dieser Arbeit ist es, Antworten auf die Fragen „Inwieweit kann die noch junge WS-Technologie schon heute bei der Realisierung von Aufgaben im Bereich der unternehmensinternen und -übergreifenden Anwendungsintegration zum Einsatz kommen?“ und „Welchen Mehrwert bietet ein derartiger Einsatz gegenüber anderen Technologien?“ zu finden. Dazu bedarf es neben einer Ausarbeitung der Unterschiede zwischen WS und anderen heutigen Architekturen einer Beurteilung der Eignung von WS für unternehmenskritische Anwendungen, sowie einer technischen und betriebswirtschaftlichen Bewertung der Technologie. Zudem wird aufgezeigt, wie die weitere Entwicklung von WS sich auf Anwendungsintegration (AI) auswirken könnte.

Gang der Untersuchung:

Im ersten Teil der Arbeit wird sowohl die Entstehung und heutige Bedeutung der AI systematisch erarbeitet, als auch ein Überblick über die derzeit bedeutendsten Standards gegeben. In den folgenden Kapiteln wird dem Leser die Welt der WS näher gebracht.

Hierzu dient der 3. Abschnitt als generelle Einführung in Funktionsweise und Anwendungsbereiche. Darauf aufbauend werden in Kapitel 4 die Grundlagen der Technologie erörtert. Ein Vergleich des WS-Frameworks mit der ebXML Initiative beendet das Kapitel. Im 5. Kapitel rundet eine vergleichende Betrachtung von Werkzeugen zur Erstellung von WS den technischen Teil der Arbeit ab. Der 6. Teil liefert eine detaillierte Analyse der Eignung von WS zur Integration unternehmensinterner und -externer Anwendungen. Das 7. und letzte Kapitel schließt die Arbeit mit einem kurzen Resümee ab.

Inhaltsverzeichnis:

Abkürzungsverzeichnis V
Abbildungsverzeichnis VIII
Tabellenverzeichnis IX
Listings IX
1. Webservices - Mehrwert für Anwendungsintegration? 1
2. Anwendungsintegration 3
2.1 Begriffliche Abgrenzung 3
2.2 Entstehung und heutige Bedeutung 5
2.2.1 Integrationsziele 5
2.2.2 Historische Entwicklung 7
2.2.3 Die Rolle von Electronic Data Interchange 9
2.2.4 Anwendungsintegration heute 11
2.3 Kommunikationsmodell: Synchron versus Asynchron 12
2.4 Integrationsansätze 13
2.4.1 Präsentationsintegration 13
2.4.2 Integration von Daten 14
2.4.3 Funktionsbasierte Integration 14
2.5 Integrationstopologien 16
2.5.1 Point-to-Point 16
2.5.2 Hub-and-Spoke 17
2.5.3 Bus/Pipeline 17
2.6 Ausgewählte Middleware als Beispiel für Integrationsplattformen 18
2.6.1 Grundlegende Differenzierungskriterien 19
2.6.2 CORBA - Die Common Object Request Broker Architecture 20
2.6.3 Enterprise Java Beans 22
2.6.4 Das (Distributed) Component Object Model 23
3. Webservices - Eine Einführung 25
3.1 Grundlegende Funktionsweise 26
3.2 Einsatzmöglichkeiten 27
4. Die Webservices-Technologie 28
4.1 XML - normierte Auszeichnungssprache als technologische Grundlage 29
4.2 Discovery - Das Auffinden von Webservices 31
4.2.1 UDDI - Grüne Seiten für Webservices 32
4.2.2 WSIL 32
4.3 Description - Selbstbeschreibende Dienste 33
4.3.1 WSDL 33
4.3.2 Ergänzende Beschreibungsansätze 34
4.3.2.1 User Interfaces 34
4.3.2.2 Weitere Beschreibungssprachen 35
4.4 Packaging - Die Übertragungsprotokolle 36
4.4.1 SOAP 36
4.4.2 Ergänzungen des SOAP Protokolls 37
4.5 Transport - Wege zur Verteilung 38
4.5.1 http 39
4.5.2 Alternative Transportwege 39
4.6 ebXML - Konkurrierendes Framework oder Ergänzung? 40
5. Werkzeuge zur Entwicklung von Webservices 42
5.1 Java 2 Enterprise Edition 42
5.1.1 Die J2EE Architektur 43
5.1.2 Die Entwicklung von Webservices mit J2EE 44
5.2 Microsoft .NET 45
5.2.1 Die Vision hinter .NET 45
5.2.2 .NET Framework und Services 45
5.2.3 .NET Server 46
5.3 Vergleichende Betrachtung: J2EE versus .NET 47
6. Der Einsatz von Webservices zur Integration heterogener Welten 50
6.1 Einordnung von Webservices in das Integrationsschema 50
6.2 Webservices - Ein Paradigmenwechsel? 51
6.3 Prämissen beim Einsatz von Webservices zur Anwendungsintegration 53
6.3.1 Standardisierung 53
6.3.2 Interoperabilität 55
6.3.3 Verbreitungsgrad 56
6.3.4 Sicherheit 58
6.3.5 Transaktionsunterstützung 59
6.3.6 Quality of Service 60
6.3.7 Weitere Faktoren 61
6.4 Weitere technische Gesichtspunkte 61
6.5 Webservices und heutige Middleware 62
6.6 Betriebswirtschaftliche Faktoren 65
6.7 Integration innerhalb von Unternehmensgrenzen 67
6.8 Organisationsübergreifende Integration 68
7. Webservices zwischen Vision und Wirklichkeit 70
Anhang A: Listings X
Anhang B: Ergänzende Abbildungen XIV
Literaturverzeichnis XVII
Eidesstattliche Erklärung XXXIV

Automatisiert erstellter Textauszug:

Der CORBA Standard ist das Ergebnis eines aus über 850 Firmen bestehenden Konsortiums namens Object Management Group (OMG).82 Schätzungsweise 60 unterschiedliche Implementierungen des CORBA Standards waren Ende 2001 am Markt und mindestens 1000 Großunternehmen nutzen CORBA zum heutigem Zeitpunkt.83 CORBA ist gegenwärtig der leistungsfähigste und komplexeste Middleware Ansatz am Markt und tritt mit dem Ziel an, Interfaces für interoperable, sprachunabhängige SW unter Nutzung der Objekttechnologie zur Verfügung zu stellen.84 Von Objekten bereitgestellte Schnittstellen werden in einer eigenen abstrakten, programm- und sprachunabhängigen Beschreibungssprache, der CORBA Interface Definition Language (IDL), beschrieben, CORBA ist also selbstbeschreibend. Das Herzstück von CORBA bildet der Object Request Broker (ORB). Durch ihn sind Funktionen eines Objekts dynamisch (Methoden sind beim Aufruf nicht bekannt und werden vom ORB gesucht) und statisch (bekannte Objekte) aufrufbar und CORBA Dienste zugänglich.85 Die Suche beim dynamischen Methodenaufruf erfolgt mittels eines Schnittstellenverzeichnisses, das Metadaten deklariert, die von den Clients benutzt werden können. Die in CORBA realisierte Trennung von Objekt und Implementierung ermöglicht einfachere SW Wiederverwendung, da Änderungen in einer Schnittstelle nicht zwangsläufig deren Gegenpart betreffen.86 Der ORB wird noch weiteren CORBA Diensten begleitet. Die komplette CORBA Architektur verdeutlicht die Abbildung auf der nächsten Seite. [...]

Obwohl nachrichtenbasierte Kommunikation (Messaging) die älteste Middleware Idee darstellt, gibt es noch keinen Standard für dieses Konzept.74 Prozesse kommunizieren hierbei über den Austausch von Nachrichten. Daher reichen für die einfachste Art der Verständigung zwei Befehle aus: Send und Receive.75 Messaging kann synchron oder asynchron mit Hilfe von Message Queues erfolgen. Letztere ergänzen das Konzept des Messaging durch Queue Manager, die Speicherung und Weiterleitung von Messages übernehmen.76 Remote Procedure Calls (RPC) wurden Mitte der 80er Jahre entwickelt und sind Mechanismen die, wenn sie aufgerufen werden, eine Funktion auf einem entfernten System ausführen und das Resultat an den aufrufenden Rechner zurückgeben.77 Der RPC, der stets synchron abläuft, ist Grundlage vieler anderer Technologien, unter anderem dem Distributed Component Object Model (DCOM) und der Common Object Request Broker Architecture (CORBA). Grundlegende Idee solcher Middleware ist, bei der Kommunikation von verteilten Prozessen dieselben Techniken wie bei lokalen zu verwenden.78 Problematisch bei RPCs ist die Ausführungsgeschwindigkeit: Ein einzelner Call benötigt zur Ausführung 10.000 - 15.000 Instruktionen. Diesem Aufwand stehen positiv die Einfachheit des Mechanismus und die anspruchslose Programmierung der Aufrufe gegenüber.79 Database Access Middleware bietet Mechanismen zum Zugriff auf Datenbanken. Weiterhin werden Funktionalitäten wie Data Sharing, Data Synchronization und Data Warehousing unterstützt. Beispielhaft sei für diesen Typ ODBC oder JDBC (Open bzw. Java Database Connectivity), als Middleware zum Datenzugriff erwähnt. Transaction Processing Monitors sind ein Middleware Typus, der die Integrität von komplexen Transaktionen sichert und die dazu nötigen Features wie Rollback, Fehlerbehandlung, Replikation und vieles mehr zur Verfügung stellt.80 Als letztes ist die Distributed Object Technology zu nennen. Hierbei unterliegen „Schnittstellen und Implementierungen einem objektorientierten Modell, das zur [...]

Die Integration von Applikationen unter derselben Systemsoftware stellt hohe Erwartungen an die Entwickler. Sobald zusätzlich heterogene Betriebssysteme ins Spiel kommen, nimmt die Komplexität nochmals zu. Als Hilfsmittel zur Verringerung der Komplexität kommt Middleware ins Spiel, die als ‚Enabler der Integration’ bezeichnet werden kann.69 Middleware ist anwendungsunabhängige SW, deren primäres Ziel der Abbau von technischen und konzeptuellen Inkompatibilitäten ist.70 Der Begriff kann weiterhin definiert werden als „Softwareschicht, die Dienstleistungen für die Integration in einer heterogenen Umgebung erbringt“.71 Middleware stellt Mechanismen zur Kommunikation von Prozessen über Netzwerke und zur Überwindung von Barrieren zwischen Systemen als auch zur Behandlung von Fehlern und Ausfällen dieser Systeme bereit. Eine entscheidende Aufgabe von Middleware ist die Gewährleistung von Transparenz, d. h. die Komplexität des verteilten Systems wird gegenüber Entwicklern und Anwendern verborgen. Zusätzlich stellt Middleware betriebssystemnahe [...]

Arbeit zitieren:
Krischer, Benjamin Juni 2002: Anwendungsintegration durch Webservices, Hamburg: Diplomica Verlag

Schlagworte:
Middleware, EAI, IEI, Web Service, Integration

Entdecken Sie mehr zum Thema

diplom.de
Bachelor + Master Publishing

Hermannstal 119 k
22119 Hamburg

Fon: +49 (0) 40 655992-0
Fax: +49 (0) 40 655992-22

Service-Telefon

Rufen Sie uns an:
+49 (0) 40 655992-0

Mo-Fr
09.00-16.00 Uhr

diplom.de in den Medien

Folgen Sie uns bei Twitter & werden Sie diplom.de-Fan bei Facebook!
Schreibtipps unserer Lektoren, Neuigkeiten aus dem Verlagsalltag und das Expertenwissen unserer Autoren als Tweet & Post!
Wir freuen uns auf Sie!

diplom.de BACHELOR + MASTER PUBLISHING

Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Magisterarbeiten, Dissertationen und andere Abschlussarbeiten aus allen Fachbereichen und Hochschulen können Sie bei uns als eBook sofort per Download beziehen oder sich auf CD oder als Buch zusenden lassen. Seit mehr als 15 Jahren ist diplom.de der seriöse, professionelle und erfolgreiche Partner für die Veröffentlichung wissenschaftlicher Abschlussarbeiten.

© Diplomica Verlag GmbH 1996-2011, AG Hamburg HRB 80293 - GF Björn Bedey, USt-IdNr.: DE214910002 - Verkehrsnummer: 12285 - Impressum
Index der Arbeiten - Index der Autoren