Anwendungsintegration durch Webservices
- 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
In den Warenkorb
48,00 €
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 |
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 [...]
In den Warenkorb
48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832458928
Arbeit zitieren:
Krischer, Benjamin Juni 2002: Anwendungsintegration durch Webservices, Hamburg: Diplomica Verlag
Schlagworte:
Middleware, EAI, IEI, Web Service, Integration



