Aktuelle Ansätze für Web Service basierte Integrationslösungen. Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke

Transkript

1 Aktuelle Ansätze für Web Service basierte Integrationslösungen Arbeitsgruppe Softwaretechnik Software Measurement Laboratory SMLab Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke Otto-von-Guericke-Universität Magdeburg Fakultät Informatik - Institut für verteilter Systeme Postfach 4120, D Magdeburg Abstrakt Der vorliegende Preprint gibt einen Überblick zu den Möglichkeiten der Web- Service Technologie im Rahmen so genannter Enterprise Application Integration Lösungen (kurz EAI-Lösungen). Nach der Einführung und Motivation wird auf die technologischen Grundlagen von EAI-Lösungen und Web Services eingegangen. In einem weiteren Abschnitt werden mögliche Vorgehensweisen und Architekturansätze zur Implementierung Web Service basierter EAI- Lösungen aufgezeigt. Darüber hinaus werden potentielle Lücken im derzeitigen Konzept der Web Services beschrieben, die zum Teil den Gegenstand aktueller Standardisierungsbemühungen bilden. Um hier einen entsprechenden Einblick zu erhalten werden ausgewählte Standardisierungsansätze im weiteren Verlauf des Kapitels detailliert vorgestellt. Insbesondere wird hier auf einen herstellerübergreifenden Ansatz eingegangen, der die Möglichkeit einer Geschäftsprozesssteuerung auf der Grundlage integrierter Web Services bietet. In diesem Zusammenhang wird ein entsprechendes Beispiel vorgestellt und schrittweise erläutert. Abschließend wird auf weiterführende Ansätze bzw. derzeit noch nicht abgedeckte Themenstellungen eingegangen.

2 Dank Für die technische Aufbereitung des verwendeten BPEL-Beispiels möchten wir uns insbesondere bei Herrn Friedhelm Röhl bedanken. Auch Herrn Lars Gentsch gebührt unser Dank für die Ausarbeitung der theoretischen Grundlagen zu Web Service Technologie. Ebenso geht ein Dank an Herrn Thomas Schlosser und Frau Petra Schmietendorf für die technische Unterstützung bei der Fertigstellung des vorliegenden Preprints.

3 Inhaltsverzeichnis 1 EINFÜHRUNG UND MOTIVATION 7 2 TECHNOLOGISCHE GRUNDLAGEN Grundlagen von EAI-Lösungen Schichtenmodell der Applikationsintegration Integrationslevel Datenaustausch mit XML Dienste von EAI-Lösungen EAI-Produkte Web Service Grundlagen XML - Extensible Markup Language SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration Rollen im Web Service Konzept Entwicklung, Wiederverwendung und Ausführung 19 3 EAI-LÖSUNGEN AUF DER BASIS VON WEB-SERVICES Ausgangssituation Web Services und EAI: Heutige Situation und Trends Unterschiede zwischen traditionellen EAI-Lösungen und Web Services Vorgehensweise zur Implementierung von EAI-Lösungen Überblick zum Vorgehen Phasen eines Integrationsprojektes Architektur einer Web Service basierten EAI-Lösung Service- basierte Architekturen für eine Enterprise Business Integration Web Service Architekturmodelle für Enterprise Integration Beispiel: Web Services für EAI Bedeutung der Web Services für ein Unternehmen Vorteile der Nutzung von Web Services als Integrationsplattform Fachkomponenten im Rahmen von EAI-Lösungen 31 4 EAI-KONFORME STANDARDISIERUNGSANSÄTZE Überblick und aktuelle Situation WS Coordination Integration verschiedener Transaktionsprotokolle WS Transaction Transaktionsmodelle Koordinationsprotokolle für Atomic Transaction (AT) Koordinationsprotokolle für Business Activity (BA) BPEL Business Process Excecution Language for Web Services Aktivitätsdefinition in BPEL Interaktionen mit anderen Partnern Fehlerbehandlung Lifecycle von Services Beziehung zwischen WS-Transaktion und BPEL Vorteile 44

4 4.5 Beispiel einer EAI-Lösung auf Basis BPEL -Spezifikation Entwicklungs- und Laufzeitumgebung Beschreibung des Beispielprozesses Detailbeschreibung der WSDL- und BPEL-Dateien 49 5 AUSBLICK UND ENTWICKLUNGSTENDENZEN Weiterentwicklungen Communities zum Themengebiet 55 6 QUELLENVERZEICHNIS 56

5 Abbildungsverzeichnis Abbildung 1 EAI-Schichtenmodell 9 Abbildung 2: Web Service Architektur (in Anlehnung an IBM und Microsoft) 15 Abbildung 3: Beispiel einer einfachen XML-Dateil 16 Abbildung 4: Zusammenwirken der Komponenten 18 Abbildung 5: Vorgehensweise zur Implementierung einer EAI-Lösung 23 Abbildung 6: Referenzmodell einer Servicebasierten Integrationsarchitektur 26 Abbildung 7: Web Service Architekturmodell für Enterprise Integration 27 Abbildung 8: Beispiel einer Integration auf Grundlage von Web Services 29 Abbildung 9: Ablauf der Registrierung 38 Abbildung 10: Transaktionsverlauf 38 Abbildung 11: WSDL-Beschreibung der verwendeten Services 46 Abbildung 12: Bearbeitung von Prozeßbeschreibungen unter Eclipse 46 Abbildung 13: Laufzeitumgebung für BPEL 47 Abbildung 14: Auflistung der installierten Geschäftsprozesse 48 Abbildung 15: Sequenzdiagramm des Beispielprozesses 49

6 Tabellenverzeichnis Tabelle 1: Primitive BPEL-Aktivitäten 42 Tabelle 2: Strukturierte BPEL-Aktivitäten 42 Listingverzeichnis Listing 1: Definitionen und Namensbereiche 49 Listing 2: Message Definitionen 50 Listing 3: Definitionen der Porttypen 50 Listing 4: Properties und Aliasing 51 Listing 5: Servicelinktype Definitionen 51 Listing 6: Bekanntmachung des Dienstes 51 Listing 7: Definitionen und Namensbereiche 51 Listing 8: Partner-Definitionen 52 Listing 9: Container-Definitionen 52 Listing 10: Definition des Correlation Set 52 Listing 11: einfache und strukturierte Aktivitäten 53 Listing 12: Verzweigungen 53 Listing 13: Versenden des Ergebnisses 53

7 1 Einführung und Motivation Die Geschwindigkeit mit der Leistungen an heutigen Märkten plaziert werden können wird zunehmend zu einem entscheidenden Wettbewerbsfaktor. Die Grundlage dafür sind zum einem effizient gestaltete Geschäftsprozesse die möglichst einen durchgängigen Ablauf notwendiger Aktivitäten gewährleisten und zum anderen darunter liegende Softwaresysteme welche die fachlich begründeten Funktionen dieser Aktivitäten im Rahmen von Softwareanwendungen realisieren. Im Rahmen sowohl strategischer als auch zeitweiser Partnerschaften (dies impliziert auch eine Zusammenarbeit auf Anforderung) erfolgt eine gemeinsame Vermarktung von Produkten, die Integration von Produktions- und Lieferantenbeziehungen, der gemeinsame Zugriff auf Informationen und Services beteiligter Unternehmen sowie der Zugriff auf technische als auch menschliche Ressourcen. Die kommenden Jahre werden dementsprechend durch einen ständigen Wandel von Geschäftsprozessen geprägt sein, welche durch Informationssysteme effizient zu unterstützen sind. Integrationslösungen, welche sowohl unternehmensinterne als auch unternehmensexterne IT-Systeme geschäftsprozeßgetrieben integrieren, spielen in diesem Kontext eine zunehmend wichtigere Rolle. Konnten noch vor einigen Jahren Investitionen durch den bloßen Hinweis auf immer neue Technologien bzw. entsprechende Hypes begründet werden, steht nun das Wirtschaftlichkeitsdenken im Vordergrund. Es gilt Wettbewerbsvorteile durch die Optimierung der vorhandenen IT-Infrastruktur zu erreichen. Dem entsprechend sind erfolgreich eingesetzte Lösungen im Sinne des Investitionsschutzes an neue Bedürfnisse anzupassen, Einsparungspotentiale aufzudecken und vor allem eine geschäftsprozessorientierte Ausrichtung der verwendeten IT-Systeme zu gewährleisten. In diesem Kontext gewinnen Integrationslösungen zunehmend an Bedeutung. Bisher haben sich für deren Realisierung dedizierte Integrationsframeworks, die von Firmen wie z.b. IBM, TIBCO oder auch Vitria bereitgestellt werden, etabliert. Wenngleich diese Systeme einen hohen Reifegrad besitzen und insbesondere in großen Unternehmen seit einigen Jahren erfolgreich eingesetzt werden, implizieren sie auch gravierende Nachteile. Insbesondere dann, wenn mittelständische und kleine Unternehmen Integrationslösungen anstreben, erweisen sich die kommerziellen Integrationsframeworks als kostenintensiv und unflexibel. Darüber hinaus können auf diesen Frameworks aufsetzende Lösungen dem globalen Zusammenwirken von Unternehmen nur schwer folgen, da deren Standardisierung relativ gering ist. Genau an dieser Stelle setzen Web Services an. Ziel ist es, eine einfachere & kostengünstigere Vorgehensweise zur Integration von IT-Systemen anzubieten, als dieses durch dedizierte EAI- Lösungen möglich ist. Noch existiert keine einheitliche Auffassung, was genau unter einem Web Service zu verstehen ist. Sehr allgemein kann von einem softwarebasierten Service gesprochen werden, der über das weltweit verfügbare Internet angeboten wird. Web Services kombinieren dabei die Vorteile der komponentenbasierten Entwicklung, der Internet-Technologie und im zunehmenden Maße auch der Agententechnologie. Im Zusammenhang mit der Verwendung von Web Services werden die folgenden Vorteile erwartet: - Einfacher und kostengünstiger als dedizierte EAI-Frameworks - Breite Akzeptanz innerhalb der Industrie durch hohen Grad an Standardisierung - Synchrones und asynchrones Kommunikationsmodell - Unterstützung des Komponentenparadigma

8 - Einfache Vorgehensweise zur Kommunikation durch Firewalls hindurch - Brücke zwischen heterogenen Technologieansätzen 2 Technologische Grundlagen Im Rahmen dieses Abschnitts wollen wir auf die technologischen Grundlagen von EAI- Lösungen und Web Services basierten Lösungsansätzen näher eingehen. Dazu gehört im Kontext der EAI-Lösungen ein kurzer historischer Abriss über deren Entwicklung, die Vorstellung von involvierten Technologien, Integrationsstrategien und auf dem Markt angebotene Produkte für EAI-Lösungen. Für weiter führende Informationen sei auf den ebenfalls in diesem Jahr erschienen Preprint Nr. 5 verwiesen, der sich ausschließlich mit Bewertungsaspekten im Umfeld von EAI-Lösungen beschäftigt. Im Kontext der Web Services wird geklärt was unter einem Web Services zu verstehen ist und welche grundlegenden Technologien derzeit zum Einsatz kommen. [Reitz 2003] 2.1 Grundlagen von EAI 1 -Lösungen In den fünfziger und sechziger Jahre waren Anwendungen in Unternehmen noch sehr einfach gestrickt, was Funktionalität und Umfang betraf. Eine Zusammenarbeit zwischen den Applikationen war damals nicht notwendig bzw. sinnvoll. Durch Einführung von Festplattenspeichern und Datenbanktechnologien Ende der Sechziger, Anfang der Siebziger, konnten Programmierer direkt auf Informationen zugreifen, ohne den Umweg über sequentielle Datei gehen zu müssen. In dieser Zeit wurde damit begonnen, über die Integration von Unternehmensdaten nachzudenken. In den Achtzigern begann man immer mehr den Wert und die Notwendigkeit von Applikationsintegration zu verstehen. In dieser Zeit entstanden einige der Middlewaretechnologien, die teilweise auch heute noch genutzt werden (DCE-RPC 1982, CORBA 1989). Viele der Anwendungen aus den siebziger Jahren mussten an die neuen Herausforderungen an die IT-Abteilungen der Untenehmen angepasst werden. Durch die Versuche bestehende ältere Systeme zu integrieren, kam allerdings die Neuentwicklung zu kurz. Ein Grossteil der bestehenden Energien wurde darauf ausgerichtet, existierende Applikationen mit immer neuen, benötigten Features auszustatten. Zwei neue Technologien sollten Anfang der neunziger Jahre antreten, um die Probleme der Applikationsintegration zu lösen: Enterprise Ressource Planning (ERP) und Data Warehousing. Beide haben verschiedene Ausrichtungen. ERP integriert die operationalen Aspekte eines Unternehmens und Data Warehousing die anfallenden Daten. Die Weiterentwicklung dieser Technologien und die Entstehung von neuen (z.b. Messageorientierte Middleware Mitte der Neunziger) resultieren in der EAI, wie wir sie heute vorfinden. Dazu gehören beispielsweise Strategien wie das Supply Chain Management (SCM), die Business-to-Business Integration (B2B) sowie die Business Prozess Integration (BPI) Schichtenmodell der Applikationsintegration Eine automatisierte Abbildung der Geschäftsprozesse auf die IV-Struktur eines Unternehmens ist, wie schon festgestellt wurde, nur über die Integration der beteiligten Applikationen 1 Quelle: William Inmon, "A Brief History of Integration." (

9 möglich. Wie man sich sicher vorstellen kann ist dies, abhängig von der Größe des Unternehmens, ein relativ aufwändiger und kostenintensiver Prozess, da eine große Anzahl von unternehmensspezifischen Einflussfaktoren berücksichtigt werden müssen. Eine einfache Install and Run - Lösung ist somit kaum realisierbar. Um den Umfang und die Komplexität der Aufgaben, die bei EAI-Projekten anfallen, besser verstehen zu können, soll hier ein Schichtenmodell vorgestellt werden, das die Aspekte der Unternehmensintegration aufeinander aufbauenden Teilgebieten zuordnet und notwendige Tätigkeiten entsprechend zuteilt. Abbildung 1 EAI-Schichtenmodell Abbildung 1 zeigt eine Möglichkeit für ein solches EAI-Schichtenmodell. Auf die einzelnen Ebenen soll im Folgenden etwas detaillierter eingegangen werden: Plattform-Integration: Die Plattform-Integration bildet die unterste Ebene des EAI- Schichtenmodells. Auf dieser Stufe ist es notwendig, die zugrunde liegenden Hardund Softwarearchitekturen im heterogenen Unternehmensnetzwerk miteinander zu verbinden. Integration bedeutet hier, die Kommunikation zwischen den Unternehmensapplikationen möglichst effizient und sicher zu ermöglichen. Dazu muss u.a. zwischen verschiedenen Netzwerktypen, Hardwareplattformen und Betriebsystemen, mit eigenen Technologien und Strategien zum Informationsaustausch, vermittelt werden. Ein Beispiel ist hier die Umstellung eines heterogenen Firmennetzwerkes auf des einheitliche und von fast allen Systemen unterstützte TCP/IP-Protokoll. Middleware-Integration: Bei heutigen Unternehmen kann davon ausgegangen werden, dass ein Grossteil der existierenden Applikationen über die schon oben erwähnten Peer-to-Peer Verbindungen direkt miteinander kommunizieren. In diesen

10 Fällen kommt eine so genannte Middleware-Software zum Einsatz, die den Nachrichtenaustausch ermöglicht. Bei der Integration der beteiligten Applikationen und der damit verbundenen Ersetzung der direkten Verbindungen durch Schnittstellen zur EAI-Plattform, müssen diese Middleware-Technologien durch die EAI- Middleware ausgetauscht und die Systeme daran angepasst werden. Ist dies nicht möglich, wird es notwendig, spezielle Adapter, die die Kommunikation ermöglichen, einzusetzen. Typische Middleware-Ansätze sind beispielsweise DCE RCP, COM+/DCOM, CORBA und EJB. Daten-Integration: Eine der Schlüsselaufgaben in EAI-Projekten ist sicherlich die Integration der verschieden applikationsspezifischen Datenbanken zu einer unternehmensweiten Datenbasis, mit zentralisiertem Zugriff über die EAI-Plattform. Dazu ist es notwendig das Unternehmensdaten, inklusive dem jeweiligen Speicherort und dem Datenbankschema, für jede Applikation identifiziert und katalogisiert werden und ein unternehmensweites Metadatenmodell erstellt wird, um gezielt auf die Informationen zugreifen zu können. Soweit möglich, sollten Datenbanken zusammengefasst werden um Redundanzen zu vermeiden und Inkonsistenzen ausschließen zu können. Eine weitere Aufgabe dieser Ebene ist die Einführung eines einheitlichen Datenaustauschformates, für das sich beispielsweise XML (siehe auch Abschnitt 2.1.3) anbieten würde. Applikations-Integration: Auf der Höhe dieser Integrationsebene besteht nur noch eine eher abstrakte Sicht auf die zugrunde liegende IV-Struktur des Unternehmens. Hier besteht die Aufgabe darin, die Daten und Funktionalitäten der Applikationen dem Gesamtsystem zur Verfügung zu stellen. Erleichtert oder erst ermöglicht werden dadurch beispielsweise automatisierte Verbindungen zwischen dem Back-Office und dem Front-Office, B2B Lösungen, ein gemeinsames Nutzer-Interface für alle Applikationen und ein integrierter Web-Auftritt. Die Integration der Applikationen auf dieser Stufe ist die Vorraussetzung für ein integriertes Unternehmen auf Geschäftsprozessebene. Geschäftsprozess-Integration: Hierbei handelt es sich um die höchste Stufe der EAI. Um Geschäftsprozesse integrieren zu können, ist es notwendig, das existierende Geschäftsprozesse identifiziert, kombiniert und automatisiert werden. Dazu gehört die Verknüpfung von Aufgaben, Prozeduren, Organisationen, Informationsströmen und Anwendungen, die an den verschiedenen Geschäftsprozessen beteiligt sind Integrationslevel Anders als die Integrationsschichten, bei denen die Darstellung der Komplexität der Applikationsintegration und die Verteilung der Tätigkeiten im Vordergrund stehen, dienen die EAI-Level zur Festlegung des Umfanges der Integration aus Sicht des Unternehmens. In der Literatur 2 findet man die folgenden drei EAI-Level vor: Data-Level EAI Data-Level EAI ist aufgrund der geringen Kosten und des damit verbundenen geringen Risikos, für viele Firmen der Einstiegspunkt in die Enterprise Application Integration. Integriert wird bei diesem Level auf der Ebene der Datenhaltung (siehe Abschnitt 2.1.1, 2 B. Lublinsky - Achieving the Ultimate EAI Implementation,

11 Daten-Integration) und umgeht damit die Stufe der Applikations-Integration. Eine Anpassung der Zielanwendungen ist in den meisten Fällen nicht notwendig. Für die Data-Level EAI existieren zwei Ansätze. Beim ersten Ansatz werden Daten zwischen Datenbanken, durch die periodische oder ereignisgesteuerte Synchronisierung von Datenbankinhalten, ausgetauscht. Diese Lösung entspricht virtuell der Punkt-zu-Punkt Kommunikation und kann somit in fast allen Fällen eingesetzt werden. Sollen Daten zwischen Datenbanken mit verschiedenen Datenbankmodellen (z.b. relational und objekt-orientiert) ausgetauscht werden, muss man diese transformieren. Der zweite Ansatz geht von einer Föderation der Datenbanken aus. Dabei wird anhand einer Middleware eine Schnittstelle auf ein unternehmensweites, virtuelles Datenmodell geschaffen, unter dem alle Datenbanksysteme, unabhängig vom Hersteller, vom Modell und vom Schema, zusammengefasst werden. Alle Applikationen haben somit einen zentralisierten Zugriff auf alle Unternehmensdaten. Message-Level EAI Auf diesem Level erfolgt der Informationsaustausch zwischen den Applikationen auf der Basis von Nachrichten. Das heißt, dass die Applikationen direkt miteinander kommunizieren können, ohne den Umweg über die Datenbanken nehmen zu müssen, wobei allerdings voraussetzt wird, dass diese Art der Kommunikation von den zu integrierenden Systemen direkt unterstützt werden muss. Der Vorteil liegt hierbei in dem besser zu kontrollierenden Informationsaustausch. Message-Level EAI ist aufwendiger als die Data-Level EAI da die Applikationen mit Mechanismen und Schnittstellen zum Austausch von Nachrichten erweitert werden müssen. Im Gegensatz zu den Punkt-zu-Punkt Verbindungen wird hier der Publish-Subscribe Ansatz verfolgt. Bei einem Business-Event veröffentlicht die auslösende Applikation eine entsprechende Nachricht im Netzwerk. Eine andere Applikation, der Abonnement, holt sich aufgrund einer speziellen Kennzeichnung die Nachricht ab und kann dann damit weiterarbeiten. Der Nachteil bei diesem EAI-Level liegt im höheren Aufwand gegenüber der Data-Level EAI und in der hohen Kopplung der einzelnen Systeme untereinander. Process-Level EAI Bei der Prozess-Level EAI handelt es sich um die Form der Applikations-Integration, wie sie mit diesem Artikel eigentlich dargelegt werden soll. Die Integration erfolgt hier auf Basis von Geschäftsprozessen, wobei die EAI-Middleware als Workflow-Engine fungiert und damit so zu sagen den Mittelpunkt der IV-Struktur des Unternehmens bildet. Alle Unternehmens- Applikationen sind entweder direkt oder über zwischengeschaltete Adapter mit ihr verbunden. Sie hat die Aufgabe Schnittstellen für die existierenden Anwendungen bereitzustellen, den nachrichtenbasierten Informationsaustausch anhand definierter Geschäftsprozesse im System zu routen und die ausgetauschten Daten zwischen applikationsspezifischen Formaten zu transformieren. Es existieren zwei Ansätze für die Implementation der Process-Level EAI: Message Broker und Application Server. Während sich Message Broker rein auf das Routen der Nachrichten beschränken und damit die Geschäftsprozess-Logik in den Anwendungen belassen, verlagern

12 Application Server diese in die EAI-Plattform. Dadurch erhöhen sich noch einmal die Flexibilität, die Erweiterbarkeit und die Skalierbarkeit des Systems, allerdings auch gleichzeitig der Aufwand bei der Umsetzung. Die Geschäftsprozess-Integration ist die am weitesten fortgeschrittene Form der EAI. Sie erlaubt es einem Unternehmen, die Effizienz von Prozessen zu steigern, Kosten zu sparen und auf Kundenbedürfnisse besser zu reagieren. Welches Level aber letztendlich eingesetzt wird, ist von den Bedürfnissen des Unternehmens und den aufzubringenden Kosten abhängig. Gerade bei kleineren Firmen mit einer überschaubaren IV-Struktur und relativ kleinem Budget kann die Integration auf Daten- oder Nachrichtenebene durchaus genügen Datenaustausch mit XML Mit dem Start eines EAI-Projektes in einem Unternehmen muss man sich über ein einheitliches Datenformat Gedanken machen, da ansonsten die ständigen Transformationen zwischen den proprietären Formaten den Aufwand der Entwicklung erhöhen aber auch die Fehleranfälligkeit und die Laufzeit von Transaktionen innerhalb eines EAI-Systems negativ beeinflussen. Als ein de facto Standard für Datenbeschreibungssprachen im EAI-Umfeld hat sich XML (extensible Markup Language) durchgesetzt. Sie ist plattformunabhängig, menschenlesbar und wird von einer großen Anzahl an EAI bezogenen Produkten und Unternehmensapplikationen, mit Import- und Export-Funktionen unterstützt. XML ist an sich, auch wenn es der Name anders impliziert, keine Markup 3 -Language, sondern vielmehr eine Menge von Regeln, um neue Markup-Languages zu erzeugen. Entstanden ist XML als eine vereinfachte Teilmenge der Standard Generalized Markup Language (SGML), welche 1987 von Dr. Charles Goldfarb, Ed Mosher und Ray Lorie aus der GML in einen Industrie-Standard (ISO 8879) überführt wurde. Von ihr stammt beispielsweise auch HTML ab. GML (Generalized Markup Language) wurde ursprünglich entwickelt, um Kennzeichen, beispielsweise für das Layout oder den Font, in Texten für das Verlagswesen zu formalisieren. Heute dienen Markups allgemein dazu, die logische Struktur eines Dokumentes vom Inhalt zu trennen. Diese Struktur wird dazu genutzt, den Zweck der enthaltenen Daten zu beschreiben. Man spricht in diesem Fall auch von Meta-Daten. Eine mit XML definierte Markup-Language besteht aus einer Anzahl von Markup Tags (Kombination aus Wörtern und Sonderzeichen zur Beschreibung des Zwecks der Daten) und einer für die Dokumente spezifischen Baumstruktur. Die Tags und die Baumstruktur (oder Content Model) werden in der DTD- Datei (DTD Document Type Definition) niedergeschrieben. Mehr zum Thema XML findet sich u.a. in [Daconta 2000] Dienste von EAI-Lösungen An eine moderne EAI-Plattform werden eine Menge Anforderungen gestellt. Sie sollte möglichst performant, skalierbar, offen und sicher sein. Sie sollte die Geschäftsprozessintegration genauso unterstützten wie die Business-to-Business Integration und die Integration aller Nutzeroberflächen der beteiligten Applikationen. Des weiteren sollten sie über entsprechende Tools leicht zu administrieren sein, möglichst viele Standard- Applikationen und Hard- und Softwarearchitekturen unterstützen und sie sollte eine spezielle 3 Extensible Markup Language Erweiterbare Textauszeichnungs/Textkennzeichnungs-Sprache

13 Entwicklungsumgebung mitbringen, um eine Anpassungen der IV-Struktur des Unternehmens zu ermöglichen. Welche Dienste muss eine solche EAI-Lösung also anbieten, um die an sie gerichteten Bedürfnisse befriedigen zu können und das unabhängig davon, ob es sich um eine Komplettlösung von einem Anbieter oder um eine Kooperation von mehreren Produkten handelt? Die folgende Liste stellt eine Übersicht über die wichtigsten EAI-Services dar: Plattform- und Protokollmanagement: Dazu gehört die Unterstützung einer Vielzahl von Hard- und Softwareplattformen, Middlewaretechnologien im heterogenen Unternehmensnetzwerk und verschiedener Kommunikationsprotokolle. Synchronous, Asynchronous Support: Je nach Aufgabenstellung kann die Nutzung eines synchronen oder eines asynchronen Datenaustausches sinnvoller sein. Des Weiteren ist es möglich, dass verschiedene Middleware-Lösungen im Unternehmen im Einsatz sind, die nur eine der beiden Strategien unterstützen. Daher sollte eine EAI-Lösung Dienste zur Nutzung des synchronen oder asynchronen Datenaustausches und zur Vermittlung zwischen den beiden Technologien (Bridging) anbieten. Security Management: Eine sehr wesentliche aber auch sehr komplexe und verantwortungsvolle Aufgabe ist das Security Management. Unternehmensdaten sind oftmals sehr sensibel und dürfen daher auf keinen Fall in die falschen Hände geraten. Eine EAI-Lösung hat daher die Aufgabe wirkungsvolle Mechanismen für die Verschlüsselung von Kommunikation und Daten und zur Authentifizierung von Nutzern und Nutzergruppen anzubieten, um spezielle Bereiche und Informationen nur ausgewählten Personen zur Verfügung zu stellen. Daten Transformation und Mapping: Dazu gehören Dienste zur weiter oben schon erwähnten Umwandlung von proprietären Datenformaten in das einheitliche XML-Format, sowie Mechanismen zum Parsen von XML-Dateien und Nachrichten. Ebenso besteht der Bedarf an Mechanismen zur semantischen Anpassung von XML-Dateien. Daten- und Nachrichten-Persistens: Die persistente Speicherung von Daten und Nachrichten in Knotenpunkten von Übertragungseinrichtungen und Servern dient zur Sicherung der Zuverlässigkeit von Kommunikationswegen und zur Wahrung der Konsistenz des Gesamtsystems, beim Ausfall von einzelnen Systemen die an der Übermittlung und Verarbeitung der Daten und Nachrichten beteiligt sind. Sollte es zu einem Ausfall kommen, kann zur Wiederherstellung der Konsistenz, mit Hilfe der gespeicherten Informationen, ein Rollback durchgeführt werden. Transaktionsverwaltung: Operationen auf Datenbankinhalte bestehen grundsätzlich aus einer Anzahl von schreibenden und/oder lesenden Zugriffen. Transaktionen sind Datenbankoperationen, die die ACID Eigenschaften besitzen. ACID steht für: Atomicity (Eine Operation wird entweder vollständig oder gar nicht ausgeführt. Falls eine Operation nicht vollständig ausgeführt wird, müssen alle vorgenommenen Änderungen rückgängig gemacht werden, um die Konsistenz zu wahren.), Consistency (Durch eine Transaktion darf die Konsistenz der Datenbank nicht gefährdet werden, daher müssen nach der entsprechenden Operation Überprüfungen der Integritätsbedingungen vorgenommen werden.),

14 Isolation (Eine Person darf nur auf Daten zugreifen, die von keiner anderen Person bearbeitet werden. Er hat damit einen exklusiven Zugriff.) und Durability (Nach einer erfolgreichen Transaktion müssen die Ergebnisse der Operation persistent in der Datenbank vorliegen. Alle nachfolgenden Operationen beziehen sich damit auf den aktualisierten, konsistenten Inhalt der Datenbasis). Die Transaktionsverwaltung hat die Aufgaben die ACID-Eigenschaften für Transaktionen zu garantieren und eine Abarbeitungsfolge (Scheduling) für Operationen von verschiedenen Nutzern festzulegen. Routing Services: Da in einem integrierten Unternehmen die Applikationen im Idealfall nicht mehr direkt miteinander kommunizieren, hat die EAI-Plattform die Aufgabe die Nachrichten und Informationen, anhand von definierten Geschäftsprozessen, weiterzuleiten. Des Weiteren sollte sie den Anwender bei der Eingabe und Definition dieser Geschäftsprozesse, möglicherweise mit einem grafischen Editor, unterstützen. Load-Balancing: Load-Balancing bedeutet die Aufteilung von Anfragen an gleichwertig Server, um eine möglichst gleichmäßig Lastverteilung und damit minimale Antwortzeiten zu erreichen. Error- und Exception-Handling: Sollte eins der Systeme oder eine Übertragungseinrichtung ausfallen, hat die EAI-Plattform die Aufgabe, betroffene Systeme und Personen (z.b.: den Administrator) zu informieren und wenn möglich, geeignete Gegenmaßnahmen zu ergreifen. Um solche Ausfälle selbständig erkennen zu können, müssen der Zustand und die Konsistenz des Gesamtsystems ständig überwacht werden EAI-Produkte Bei EAI-Plattformen arbeiten oft verschiedene Einzellösungen Hand in Hand. Eine mit der Integration beauftragte IV-Abteilung oder Firma hat hier entweder die Möglichkeit eine am Markt befindliche Komplettlösung von einem Hersteller einzusetzen und die existierende IV- Infrastruktur darauf anzupassen, oder sie verfolgt den so genannten best of breed Ansatz, bei dem mehrere Teillösungen, von verschiedenen Herstellern, die auf das Unternehmen und auf die bestehende Situation am besten zugeschnittenen sind, ausgewählt und kombiniert werden. Der erste Ansatz hat den Vorteil, dass alle Komponenten aus einer Hand kommen und die Zusammenarbeit somit gewährleistet ist. Die Kosten für das Training der Mitarbeiter und für die Integration der Applikationen sind im Gegensatz zum zweiten Ansatz verhältnismäßig gering. Nachteilig dabei ist aber, dass Teilkomponenten, die spezielle Bedürfnisse eines Unternehmens nur eingeschränkt oder gar nicht befriedigen, in den wenigsten Fällen ausgetauscht werden können. Wurde erst einmal eine Plattform ausgewählt, ist man von ihr und den angeboten Leistungen und verwendeten Technologien abhängig. Ein späterer Wechsel auf eine andere Plattform ist mit einem unverhältnismäßig großen Aufwand verbunden. Hinzu kommt noch, dass aufgrund ihrer hohen Spezialisierung, eine Einzellösung eine Aufgabe oft besser erfüllen kann als die Teillösungen einer EAI-Plattform, welche möglichst viele Bereiche abdecken will. Produkte für das EAI-Umfeld kommen typischer Weise aus den folgenden Bereichen: Messageorienteirte Middleware TP Monitore

15 Message Broker Application Server Web-Portal-Software Process- bzw. Workflow-Engine zur Automatisierung der Geschäftsprozesse 2.2 Web Service Grundlagen In Anlehnung an [Heafel 2002] handelt es sich bei Web Services um netzwerkbasierte Applikationen, die ihre im Internet angebotenen Funktionen mittels des WSDL-Protokolls (Web-Service Description Language) beschreiben, für den Informationsaustausch XML- Dokumente (extensible Markup Language) verwenden und für den Aufruf entfernter Methoden bzw. die Datenübertragung das SOAP-Protokoll (Simple Object Access Protocol) nutzen. Typischerweise erfolgt die Übertragung der in XML-Dokumente verpackten Daten und Funktionsaufrufe auf der Basis des http-protokolls, so dass auch durch Firewalls hindurch kommuniziert werden kann. Diese Eigenschaft bietet die Möglichkeit echte B2B 4 - Anwendungen zu entwickeln. Zur Lokalisierung im Internet verfügbarer Web Services werden UDDI-Verzeichnisdienste (Universal Description, Discovery and Integration) verwendet. Zentrale UDDI Verzeichnisse werden z.b. von IBM und Micrsosoft betrieben. Waren klassische EAI-Lösungen an eine primäre Integrationsplattform gebunden, so wird durch die Verwendung der Web Service Basistechnologien eine vollständige technologische Entkopplung der kommunizierenden Systeme erreicht. Einzige Voraussetzung für die technologische Kopplung ist das Vorhandensein einer Internet/Intranet Infrastruktur. Derzeit im Internet angebotene Web Services variieren von einfachen Funktionen, wie z.b. Wetteroder Authentifizierungs-Services, bis hin zu kompletten Geschäftstransaktionen, wie z.b. die Buchung aller benötigten Leistungen im Rahmen eines Reiseportals. BPEL4WS (Business Process Automation) Messaging WS- Security WS- SLA WS-Transaction geplante WS-Standards WS-Coordination WSDL, UDDI, WS-Introspection SOAP (WS Routing, WS Attachment, DIME) verfügbare WS-Standards XML, XML Schema, Encoding Transports Basis- Techniken Abbildung 2: Web Service Architektur (in Anlehnung an IBM und Microsoft) 4 B2B Business to Business

16 In Abbildung 1 kann die durch IBM und Microsoft derzeit propagierte Web Service Architektur nachvollzogen werden. Aus dieser Übersicht wird auch ersichtlich, dass Themenstellungen wie das Messaging, sicherheitsrelevante Aspekte, die Verwendung von Service-Level- Vereinbarungen inklusive der Verrechnung oder auch die Transaktionssicherung noch keinem weltweit anerkannten Standard unterliegen XML - Extensible Markup Language XML ist ähnlich wie HTML eine Datenbeschreibungs- und Strukturierungssprache. XML bietet sehr flexible Möglichkeiten im Kontext der Informationsübertragung, weshalb es eine der wesentlichen Grundlagen zur unternehmensweiten Integration von Anwendungssystemen darstellt. Mit Hilfe von XML strukturierte Funktionen und Daten können über Protokolle, wie z.b. HTTP ausgetauscht werden. Innerhalb der Industrie arbeiten immer mehr Unternehmen mit dieser Sprache um standardisierte Datenformate für den unternehmensinternen, aber auch unternehmensübergreifenden Dokumentenaustausch festzulegen. Im folgenden ein einfaches Beispiel einer XML-Datei. <?xml version="1.0"?> <brief> <adresse typ = an > <name>harry Mustermann</name> <strasse>musterstrasse</strasse> <nummer>1b</nummer> <postleitzahl>12345</postleitzahl> <ort>musterhausen</ort> </adresse> <adresse typ = von > <name>klaus Gustav</name> <strasse>dorfstrasse</strasse> <nummer>33</nummer> <postleitzahl>54321</postleitzahl> <ort>michelbinge</ort> </adresse> <brieftext> Lieber Harry, wie geht es dir... etc. </brieftext> </brief> Abbildung 3: Beispiel einer einfachen XML-Dateil Diese kleine XML-Datei spiegelt den Aufbau eines einfachen Briefes wieder. In der ersten Zeile steht welcher XML-Version diese Datei genügt. Alle Informationen in dieser Datei werden durch so genannte Tags (englisch ausgesprochen) eingeschlossen. Der Tag <brief> zusammen mit dem schließenden Tag </brief> enthält alle Informationen eines Briefes. Es können auch mehrere Briefe in einer Datei zusammengefasst werden. Es wird von wohlgeformt oder Wohlgeformtheit bei XML gesprochen, wenn es zu jedem öffnenden Tag auch einen schließenden Tag gibt. In XML besteht die Möglichkeit in einem Tag ein oder mehrere Attribute zu definieren. Im Tag <adresse> wurde ein Attribut typ definiert welches angibt ob es sich bei der Adresse um die Empfänger- (typ = an ) oder die Absenderadresse (typ = von ) handelt. Der Tag <brieftext> umschließt den eigentlichen Inhalt des Briefes.

17 Bei den Web-Services wird XML für die SOAP-Nachrichten und für die WSDL- Beschreibung verwendet. Allerdings sind hier die Tags und ihre etwaigen Attribute fest vordefiniert. In den entsprechenden Standards des W3C sind diese genau aufgelistet und beschrieben SOAP Simple Object Access Protocol Mittels SOAP erfolgt die Kommunikation (z.b. Methodenaufrufe, Parameter und Ergebnisse) zwischen Web Services. [Knuth 2002] bringt die Bedeutung von SOAP auf eine ganz einfache Formel: SOAP = XML over HTTP. SOAP ermöglicht dabei eine RPC- (Remote Procedure Calls) und eine DOC-orientierte Arbeitsweise. Neben SOAP gab und gibt es noch andere Ansätze z.b. XML-RPC, allerdings scheint sich SOAP jetzt weitestgehend durchgesetzt zu haben nicht zu letzt auch weil Microsoft SOAP-Unterstützung in das.net- Framework integriert hat. Entsprechend [Short 2002] bieten sich die folgenden Vorteile bei der Nutzung des Protokolls: - Programmiersprachenunabhängigkeit, da SOAP keine Programmiersprache oder spezielle API (Application Programmers Interface) vorschreibt. - Transportprotokollunabhängigkeit, zwar beschreibt die SOAP-Spezifikation wie SOAP Nachrichten an HTTP gebunden werden, jedoch handelt es sich bei einer SOAP-Nachricht lediglich um ein XML-Dokument und dieses könnte auch über andere Protokolle übertragen werden (z.b.: SMTP Simple Mail Tranfer Protocol). - SOAP bietet Unabhängigkeit von einer speziellen Objektinfrastruktur, d.h. Middelware- Systeme wie COM+ oder J2EE (Enterprise Java Beans) können so modifiziert werden, dass sie SOAP unterstützen. SOAP ermöglicht eine Interoperabilität zwischen unterschiedlichen Middleware-Ansätzes, weshalb es auch als Bridge zwischen verschiedenen Technologien verwendet werden kann. - Verwendung von bestehenden Industriestandards, d.h. das SOAP auf bestehende Standards wie XML zurückgreift um z.b. Nachrichten zu kodieren. Statt einem eigenen Typensystem verwendet SOAP die in der XML-Schemaspezifikation definierten Typen. Wie schon erwähnt ist SOAP an kein spezielles Transportprotokoll gebunden. - SOAP ermöglicht Plattformunabhängigkeit, d.h. jede Plattform die XML und HTTP verwenden kann, kann auch mit anderen, diese Technologien verwendenden Plattformen, kommunizieren. So kann eine PC-Anwendung mit einer Back-End-Anwendung kommunizieren welche beispielsweise auf einem Großrechner läuft UDDI Universal Description, Discovery and Integration Um im Internet angebotene Web-Services ausfindig machen bedarf es entsprechender Verzeichnisse im Sinne eines Telefonbuches. Bei UDDI handelt es sich um einen zentralen Verzeichnisdienst der für die Veröffentlichung technischer Informationen über Webdienste verwendet wird. UDDI wurde in Kooperation mehrerer großer Unternehmen 5 wie z.b. IBM, Sun, SAP und Microsoft entwickelt. UDDI besteht aus einer Gruppe von Registrierungen und Registratoren. Jede Registrierung enthält eine vollständige Kopie des gesamten UDDI-Verzeichnisses. Das System basiert auf einem Replikationsmodell mit einem einzigen Master. Damit ist jeder registrierte Web- 5 eine vollständige Liste aller an der Entwicklung beteiligter Unternehmen findet sich unter

18 Service von jeder Registrierung aus auffindbar. Ein Registrator 6 bietet Registrierungsdienste für einen Kunden. Innerhalb des UDDI-Verzeichnisses wird jeder Web-Service über einen weltweit eindeutigen Schlüssel identifiziert, dem UDDI-Key. Unter folgenden Adressen ist ein Zugriff auf die UDDI-Registry möglich: und Rollen im Web Service Konzept Service Broker (Registry) Service Description Find WSDL + UDDI Publish WSDL + UDDI Service Requester Web Service Client or another Web Service Bind Service Provider Web Service + Service Description Abbildung 4: Zusammenwirken der Komponenten SOA steht für Service-Orientierte-Archritektur und ist eins der fundamentalen Web-Service- Architektur-Prinzipien. Bei SOA geht es darum, wie die Service-Komponenten beschrieben und organisiert sind, um einen dynamischen und möglichst automatisierten Zugriff bzw. die Suche und Benutzung zu unterstützen. Die drei Hauptakteure bzw. Rollen in diesem Schema sind der Service-Requestor, der Servcie-Broker und der Servcie-Provider. - Der Service-Provider stellt einen Dienst bzw. einen Web-Service zur Verfügung und veröffentlicht/registriert diesen Dienst beim Service-Broker. Er ist also der Dienst- Anbieter. - Der Service-Broker registriert und kategorisiert den veröffentlichten Dienst des Providers. Zusätzlich stellt er Suchdienste oder Funktionen zur Verfügung, um registrierte Dienste zu finden. - Der Service-Requestor ist der Benutzer eines Service. Er sucht beim Service-Broker den von ihm gewünschten Dienst, um diesen dann zu benutzt. In diesem Schema existieren drei Grundoperationen diese lauten: Publish, Find und Bind. - Die Publish-Operation ermöglicht es einem Service-Provider, die Möglichkeiten und die Schnittstelle seines Dienstes beim Service-Broker zu registrieren. 6 Registratoren sind z.b. Microsoft, IBM und SAP

19 - Die Find-Operation ermöglicht es dem Servcie-Requestor beim Service-Broker einen einzelnen Service einer bestimmten Kategorie eines Service-Providers zu finden. - Die Bind-Operation macht es dem Service-Requestor möglich, den Dienst eines Servcie- Providers zu nutzen Entwicklung, Wiederverwendung und Ausführung Wir wollen in diesem Abschnitt kurz auf die allgemeine Vorgehensweise zur Entwicklung, Wiederverwendung und Ausführung von Web Services eingehen. Dabei steht weniger eine konkrete Technologie, wie z.b. Microsoft.net oder die SUN J2EE im Vordergrund, als vielmehr grundsätzliche Sichtweisen auf Web Services. Die Implementierung serviceorientierter Architekturen kann einerseits die Entwicklung eigener Web Services implizieren, andererseits können im Internet verfügbare Web Services im Sinne einer Black Box -Wiederverwendung genutzt werden. Im letzten Fall stehen keine Informationen über den Quellcode des Web Services zur Verfügung. Bei kommerziellen Anwendungen setzt die Verwendung eines solchen Web Services ein hohes Vertrauen in den potentiellen Anbieter voraus. Beide Szenarien sollen im Folgenden kurz erläutert werden, darüber hinaus soll auch auf den Sachverhalt des Wirkbetriebs von Web Services eingegangen werden. Entwicklung eines Web Services Für die Entwicklung eines Web Services ist im ersten Schritt die gewünschte Funktionalität mit Hilfe der genutzten Entwicklungsumgebung zu implementieren. Dabei kann es sich z.b. um Java-Klassen, SUN s EJB-Komponenten, Microsofts COM-Komponenten oder auch Visual Basic Anwendungen handeln. In einem folgenden Schritt gilt es, die durch den Web Service angebotenen Funktionen mit einer entsprechenden Schnittstelle zu versehen. Für diese Aufgabe werden zumeist entsprechende SOAP-Toolkits angeboten. Sie erzeugen auf der einen Seite eine wsdl-datei, diese spezifiziert welche Funktionen durch den Web Service angeboten werden, auf der anderen Seite wird das Binding zwischen der wsdl-schnittstelle und der eigentlichen Implementierung erzeugt. Zur Ausführung des Web Services wird eine entsprechende Runtime-Umgebung benötigt, welche über das http-protokoll eingehende SOAP-Anfragen an die eigentliche Implementierung weiterleitet. Neue Versionen von Web Servern bieten diese Erweiterung (z.b. Apache Tomcat Axis). Verwendung eines vorhandenen Web Services Die seit vielen Jahren verfolgte Zielstellung einer möglichst umfangreichen Wiederverwendung bereits implementierter Software findet durch die Web Service- Technologie eine weitere Optimierung. Da Web Services ihre Funktionen ausschließlich über eine wohl definierte Schnittstelle anbieten, bedarf diese einer exakten Beschreibung. Nur so können interessierte Entwickler diese auch tatsächlich im Rahmen der eigenen Anwendung verwenden. Die derzeit verwendete wsdl-beschreibung berücksichtigt nur den reinen funktionalen Umfang der Schnittstelle, Themen, wie z.b. nicht funktionale Anforderungen oder auch Vor- und Nachbedingungen werden maximal durch textuelle Beschreibungen erfaßt. Eine Übersicht frei zugänglicher Web Services findet sich z.b. unter Am waren dort 332 frei zugängliche Web Services verzeichnet. Die dort angebotenen Web Services beschränken sich zumeist auf sehr einfache Funktionen, wie z.b. die Umrechnung von Währungen. Das Angebot komplexerer fachlicher Funktionen (z.b. Bearbeitung von Kundenbestellungen), die im Kontext zu einem bestimmten Geschäftsprozeß (z.b. Bereitstellungsprozeß konkreter Produkte) stehen, ist derzeit noch sehr eingeschränkt. Weitere Informationen zu dieser Themenstellung finden sich z.b. unter [Schmietendorf 2003b].

20 Ausführung von Web Services Der Wirkbetrieb servicebasierter Lösungen kann mit dem anderer Anwendungen weitgehend verglichen werden, erfordert allerdings die Überführung des System-Management in ein, die Kundenbedürfnisse berücksichtigendes Service-Meanagement. Sofern im Internet angebotene Web Services im Rahmen der Anwendung verwendet werden, liegt die Zuständigkeit für die funktionalen und nichtfunktionalen Eigenschaften beim entsprechenden Anbieter des Web Services. In diesem Fall wird ein entsprechendes Vertragsmodell benötigt, welche die kommerziellen und technischen Rahmenbedingungen fixiert. Die dort zu treffenden Vereinbarungen sollten unter anderem Aussagen über die Kosten, den zu erbringenden Leistungsumfang, die erwartete Qualität, den Umgang mit Störungen oder auch die Vorgehensweise zum Leistungsnachweis bzw. dafür genutzte Messgrößen enthalten (siehe dazu auch [Schmietendorf 2003a]). Dabei kann eine statische und eine dynamische Vorgehensweise unterschieden werden. Während bei statischen Vereinbarungen bereits zum Zeitpunkt der Wirkbetriebsaufnahme funktionale und nichtfunktionale Eigenschaften weitgehend determiniert sind (die Vertragspartner sind bereits bekannt), wird bei einer dynamischen Vorgehensweise erst zum Zeitpunkt der Ausführung ein entsprechender Vertrag quasi on demand abgeschlossen. Insbesondere der zuletzt genannte Ansatz impliziert die Vision um Aufträge konkurrierender Web Services und erlaubt damit sehr dynamische Anwendungen, die sich leicht an neue Situationen (z.b. neue Kooperation von Unternehmen) anpassen können und ihre Nutzerfunktionen in einen wirtschaftlichen Kontext (z.b. Auswahl des günstigsten Mietwagenangebotes an einem konkreten Ort) stellen können. 3 EAI-Lösungen auf der Basis von Web-Services 3.1 Ausgangssituation Im folgenden wollen wir den aktuellen Stand zu Web Services und damit umzusetzenden EAI-Lösungen aufzeigen. Dabei gehen wir auf Unterschiede bzw. Gemeinsamkeiten zwischen traditionellen EAI-Lösungen und Web Services ein Web Services und EAI: Heutige Situation und Trends Web Services sind vom reinen technologischen Standpunkt nicht mit traditionellen EAI- Lösungen gleichzusetzen. Web Services sind primär eine weitere Technologie, welche die Implementierung von EAI ermöglicht und die traditionelle Point-to-Point Kommunikation technologieunabhängig gestalten kann. Durch die Nutzung derzeit verfügbaren Web Services, die eine lose Integration von Applikationen ermöglichen, kann innerhalb eines Unternehmens nur eine Teilmenge der EAI- Anforderungen abgedeckt werden. Denn der EAI-Ansatz stellt einen vollständigen holistischen Ansatz zur semantisch enggekoppelten Integration und Verbindung aller Applikationen und Systemen, die das Unternehmensbusiness unterstützen dar. Web Services, in ihrer aktuellen Form als lose gekoppelten Sammlungen von Diensten, können eher als eine ad hoc Lösung betrachtet werden, die schnell und leicht zu entwickeln ist. Die jetzige Generation von Web Services ermöglicht lediglich eine Integration zwischen Applikationen auf Funktionslevel. Sie sind in ihrer jetzigen Ausprägung nicht transaktionsorientiert und stellen grundlegende "request/response"-funktionalität bereit. Die nächste Generation von Web Services wird insbesondere fachlich begründete Funktionalität (auch Fachkomponenten genannt) berücksichtigen. Aus technologischer Sicht werden diese