Standardisierung von Web Services - Integration semantischer und sicherheitsbezogener Aspekte

Inhalt

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einführung
1.1 Collaborative Business
1.2 Zielsetzung und Vorgehensweise

2 Grundlagen
2.1 Services und Service-orientierte Architekturen
2.2 Web-Services
2.3 Web-Service-Architektur
2.4 Einsatzfelder für Web-Services
2.4.1 Enterprise Application Integration (EAI)
2.4.2 Business-to-Business- (B2B) Integration
2.5 Standardisierung als Voraussetzung für Collaborative Business
2.5.1 Basistechnologie
2.5.2 Semantik
2.5.3 Sicherheit
2.6 Standardisierungsorganisationen

3 Web-Service-Basisstandards
3.1 XML
3.1.1 Einordnung
3.1.2 XML-Verarbeitung
3.1.3 Struktur und Schema
3.1.4 XML-Funktionsaufrufe
3.2 SOAP
3.3 WSDL
3.4 UDDI

4 Integration semantischer Aspekte
4.1 Semantische Beschreibungsansätze
4.2 EbXML – eine Ergänzung für Web-Services?
4.3 Semantic-Web
4.3.1 RDF
4.3.2 RDFS
4.3.3 OWL
4.4 Integration von Semantik in die Web-Service-Architektur

5 Integration von Sicherheitsaspekten
5.1 Sicherheit und Web-Services
5.2 XML Signature / XML Encryption
5.3 Integration von Sicherheitsaspekten in die Web-Service-Architektur

6 Fazit und Entwicklungspfade
6.1 Fazit
6.2 Entwicklungspfad für Web-Services

Literatur

Eidesstattliche Erklärung

Abbildungsverzeichnis

Bild 1: Grundlage Service-orientierter Architekturen [Barr2003, S. 20]

Bild 2: Web-Service-Architektur [Barr2003, S. 23]

Bild 3: Manuelle Prozessintegration im Unternehmen

Bild 4: Konventionelle EAI-Integrationsarchitektur [AlCa2004,S.78]

Bild 5: EAI-Integration über Web-Services (SOAP)

Bild 6: Manuelle Prozessintegration im B2B-Umfeld

Bild 7: Konventionelle B2B-Integrationsarchitektur [AlCa2004, S. 129]

Bild 8: B2B-Integration über Web-Services

Bild 9: Dimensionen der Web-Service-Standardisierung

Bild 10: Web-Service-Schichtenmodell [Knut2002, S.97]

Bild 11: XML-Sprachkonzept [Weit2001; S. 19]

Bild 12: Komplexität und Funktionalität von Beschreibungssprachen

Bild 13: Struktur eines einfachen XML-Dokuments

Bild 14: Referenzierung einer externen DTD aus einem XML-Dokument

Bild 15: XML-RPC

Bild 16: Aufbau einer SOAP-Nachricht

Bild 17: SOAP-Nachricht im RPC-Style (Request / Response)

Bild 18: SOAP-Nachricht im Document-Style (Request / Response)

Bild 19: Beispiel einer Service Description in WSDL

Bild 20: Interaktionsverhalten von Web-Services

Bild 21: Elemente und Zusammenhänge einer WSDL-Beschreibung

Bild 22: UDDI.org Struktur

Bild 23: UDDI-Inquiry und Response des API

Bild 24: UDDI-Datenmodell

Bild 25: Der Weg zu Semantic Web-Services [Jeck2004a, S. 55]

Bild 26: Graphische Notation von RDF-Tripeln

Bild 27: n-ärer Graph eines Statements

Bild 28: RDF-Tripel

Bild 29: RDF / XML-Notation

Bild 30: RDFS / XML-Notation

Bild 31: RDF / XML-Notation für eine einfache OWL-Ontologie

Bild 32: Point-to-Point- vs. End-to-End-Sicherheit

Bild 33: Ebenen der Web-Service-Sicherheit

Bild 34: Teilverschlüsseltes XML-Dokument (Element Encryption)

Bild 35: XML Signature mit Message Digest

Bild 36: SOAP-Nachricht mit signierter Payload

Bild 37: Portfolio / Evolutionspfad für Web-Services

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einführung

Hinter dem Begriff Web-Service steckt weit mehr, als hinter den üblichen Floskeln, Akronymen und Schlagwörtern, welche die IT-Branche mit unverhohlener Euphorie proklamiert. Web-Services sind kein Selbstzweck, sondern adressieren grundsätzliche Anforderungen an IT-Infrastrukturen in einer hochgradig arbeitsteiligen und gleichzeitig wettbewerbsintensiven, globalen Wirtschaft.

Das praktische Einsatzspektrum von Web-Services wird entscheidend durch ihre Interoperabilität beeinflusst, die wiederum von der Verfügbarkeit gemeinsamer Konventionen und Standards abhängt. Die folgende Einführung verdeutlicht diese Perspektive und erläutert Aufgabenstellung und Zielsetzung der Arbeit.

1.1 Collaborative Business

In den letzten Jahrzehnten hat sich der Wettbewerb in nahezu allen Branchen auf nationaler wie internationaler Ebene zunehmend verschärft. Kein Unternehmen kann sich ineffiziente Geschäftsprozesse leisten, denn unzufriedene Kunden und hohe Kosten lassen sich auf Dauer auch durch hervorragende Produkte und Dienstleistungen nicht kompensieren. Viele Unternehmen sahen und sehen sich deshalb gezwungen, die eigene Wettbewerbsfähigkeit nachhaltig zu steigern, um im Wettbewerb zu bestehen.

Seit Ende der 70er Jahre stand deshalb die Optimierung innerbetrieblicher Prozesse und Informationsflüsse im Rahmen von MRP- (Material Resource Planning) und später dann ERP- (Enterprise Resource Planning) Projekten im Fokus vieler Unternehmen.

Heute setzt sich zunehmend die Erkenntnis durch, dass die Optimierung unternehmensinterner Prozesse zwar eine notwendige, jedoch keine hinreichende Voraussetzung für die Wettbewerbsfähigkeit eines Unternehmens ist. In einer vernetzten, hochgradig arbeitsteiligen Wirtschaft stehen eben nicht mehr einzelne Unternehmen im Wettbewerb, sondern komplette Wertschöpfungsketten aus Kunden, Zulieferern und Partnern. „Die Bildung von zwischenbetrieblichen Kooperationen wird für die beteiligten Akteure immer häufiger zum Instrument der Verbesserung ihrer Wettbewerbsposition in einer globalen Weltwirtschaft“ [BuKö00, S. V].

EDI (Electronic Data Interchange) stellt zwar seit nahezu 30 Jahren einen Standard für die überbetriebliche, elektronische Geschäftsabwicklung zur Verfügung, der in vielen Fällen zu signifikanten Prozessoptimierungen beigetragen hat. Aufgrund der hohen Implementierungskosten und divergierender Standards hat sich EDI allerdings nur als Koppelung zwischen großen Firmen und bei stabilen, auf Dauer ausgelegten Geschäftsbeziehungen etablieren können [Hack2004, S. 1ff]. Virtuelle Wertschöpfungsketten sind jedoch weder auf große Firmen beschränkt, noch notwendigerweise von längerer Dauer.

Dieser Erkenntnis tragen verschiedene, neuere Begriffe und Konzepte, wie ERP II (Enterprise Resource Planning 2nd Generation) [Gart00] oder Collaborative Business [Wett2003] Rechnung. Beiden Konzepten ist gemein, dass sie die Kooperationsfähigkeit von Unternehmen, d.h. die Fähigkeit zur Integration in unternehmensübergreifende Geschäftsprozesse, als wettbewerbskritischen Faktor definieren und das Internet als geeignetes Kommunikations- und Koordinationsinstrument betrachten. Hieraus ergeben sich neue Anforderungen an die Konzeption und Integration der diese Prozesse unterstützenden IT-Systeme.

Klassische ERP-Systeme, wie das mittlerweile über zehn Jahre alte SAP R/3 des Walldorfer Softwareherstellers SAP, sind monolithische Anwendungssysteme. Sie sind aus einem Guss und enthalten eine Vielzahl von Funktionalitäten, ungeachtet dessen, ob ein bestimmtes Unternehmen diese überhaupt benötigt. Schnittstellen zu externen Systemen existieren häufig nur auf Datenbank- und Quellcode-Ebene oder müssen fallweise in aufwändigen Integrationsprojekten implementiert werden.

Für eine unternehmensinterne Integration, die i.d.R. auf eine längere Dauer ausgelegt ist, können die daraus resultierenden Aufwände noch toleriert werden. Eine fallweise und automatisierte ad-hoc-Koppelung im Rahmen von unternehmensübergreifenden Geschäftsprozessen ist jedoch nicht möglich.

Kollaborative Geschäftsprozesse fordern Service-orientierte Architekturen mit modularen Softwarekomponenten, die ihre Funktionalitäten als Services gekapselt über standardisierte Technologien und Schnittstellen zur Verfügung stellen. Einerseits sollen so ohne substantielle Schnittstellen- und Integrations-aufwände unternehmensinterne IT-Systeme gekoppelt werden. Andererseits soll die Kommunikation mit externen Systemen von Geschäftspartnern hergestellt und so Unternehmen möglichst automatisiert zu virtuellen Wertschöpfungsketten kombiniert werden. Auf diesen Überlegungen basiert das Konzept der Web-Services.

Web-Services haben sich in den letzten Jahren vom vielversprechenden Konzept zu einer mittlerweile anwendungsreifen Integrationstechnologie entwickelt. Dennoch ist die Realität noch weit entfernt von der Vision lose gekoppelter, virtueller Wertschöpfungsketten. Viele Unternehmen arbeiten zwar an Web-Service-Projekten, in der unternehmensübergreifenden Geschäftsabwicklung haben sich Web-Services jedoch noch nicht durchsetzen können, wenn auch die Zahl der B2B- (Business to Business) Implementierungen relativ und absolut zunimmt [Cant2003].

Ein wichtiger Grund für die noch geringe, jedoch wachsende Zahl der unternehmensübergreifenden Web-Service Projekte ist die noch nicht abgeschlossene, aber stetig voran schreitende Standardisierung von Web-Service-Spezifikationen.

Wenn Standards fehlen, müssen die Konventionen, denen die Kommunikation folgen soll, von Fall zu Fall neu verhandelt werden, was eine automatisierte Koppelung unmöglich macht. Nur wenn Standards definiert sind, kann die unternehmensübergreifende Kommunikation formalisiert und elektronisch abgebildet werden.

1.2 Zielsetzung und Vorgehensweise

Die Standardisierung von Web-Services ist zwar mittlerweile fortgeschritten, dennoch existieren eine Reihe von Standardisierungslücken, welche die Diffusion von Web-Services gerade in der unternehmensübergreifenden Geschäftsprozessabwicklung bislang behindern.

Zielsetzung dieser Arbeit ist es, anhand der vorgestellten Web-Service-Basisstandards XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) und UDDI (Universal Description, Discovery, and Integration), Defizite bezüglich der semantischen Repräsentation, sowie der Berücksichtigung von Sicherheitsaspekten aufzuzeigen. Diese Defizite können mit weiteren Standards (Co-Standards) und Spezifikationen kompensiert werden. Die Arbeit geht insbesondere darauf ein, wie semantische und sicherheitsbezogene Standards in die Web-Service-Architektur integriert werden können.

Nach dieser Einführung wird im zweiten Kapitel erläutert, was sich hinter dem Begriff Web-Service verbirgt. Anhand des Web-Service-Architekturmodells wird aufgezeigt, wie Web-Services interagieren und welche Einsatzfelder sie für die inner- und überbetriebliche Integration von IT-Systemen erschließen. Dabei wird deutlich, dass die Standardisierung von technischen, semantischen und sicherheitsbezogenen Aspekten die grundlegende Voraussetzung für die Diffusion von Web-Services in der Praxis, insbesondere im Collaborative Business ist. Die Herausbildung und formale Proklamation von Standards erfolgt i.d.R. durch Standardisierungsorganisationen wie dem W3C oder OASIS, die ebenso vorgestellt werden.

Das dritte Kapitel widmet sich der Vorstellung der Web-Service-Basisstandards. Hierbei wird herausgearbeitet, dass diese Standards technische Aspekte, sozusagen die Mechanik von Web-Services, sehr umfassend beschreiben. Semantische und sicherheitsbezogene Fragestellungen können mit diesen Standards alleine nicht adäquat repräsentiert werden. Welche weiteren Standards sich hierfür anbieten und wie diese in die Web-Service-Architektur integriert werden können, zeigen die folgenden zwei Kapitel.

Semantische Aspekte lassen sich durch Metadaten und Ontologien beschreiben. Existierende Ontologien wie UNSPSC (Universal Standard Products and Services Classification) und eCl@ss, oder Frameworks wie RosettaNet und ebXML (electronic business XML), berücksichtigen zwar semantische Aspekte in der unternehmensübergreifenden Kommunikation, sind aus verschiedenen Gründen jedoch nicht zur Integration in das Web-Service-Architekturmodell geeignet. Dahingegen stellen die vorgestellten Technologien der Semantic Web Initiative des W3C (World Wide Web Consortium), namentlich RDF (Resource Description Framework) / RDFS (RDF Schema) und OWL (Web Ontology Language) eine gangbare Möglichkeit dar, Web-Services um semantische Inhalte zu ergänzen. Wie RDF und OWL in die Web-Service-Architektur integriert werden können, wird anhand von verschiedenen Ansätzen und Beispielen erläutert.

Web-Service-Basisstandards alleine sind nicht in der Lage, alle Anforderungen an sichere Web-Services zu erfüllen. SOAP kann zwar über tiefer liegende Schichten wie HTTP (Hypertext Transport Protocol) bzw. SSL (Secure Socket Layer) die Sicherheit während der Übertragung gewährleisten, nicht jedoch nach Abbau der SOAP-Kommunikation. Eine Möglichkeit, Sicherheit über die SOAP-Verbindung hinaus und damit auf Nachrichtenebene zu garantieren, erschließt sich mit den W3C-Standards XML Signature und XML Encryption. Da XML Encryption und XML Signature im Gegensatz zu SOAP keine dedizierten Web-Service-Standards sind, stellt sich dann die Frage, wie sie in die Web-Service-Architektur eingebunden werden können. Die Antwort auf diese Frage wird anhand von verschiedenen Ansätzen beispielhaft erläutert.

Das sechste und abschließende Kapitel fasst die Ergebnisse dieser Arbeit zusammen und zeigt anhand empirischer Untersuchungen zum Einsatz von Web-Services in der Praxis den aktuellen und zukünftig möglichen Entwicklungspfad für Web-Services auf. Hierbei wird deutlich, dass sich Unternehmen den Herausforderungen dieser neuen Technologie sukzessive stellen, indem sie Web-Services zuerst unternehmensintern einsetzen und danach auf die unternehmensübergreifende Kommunikation mit Zulieferern, Kunden und Partnern ausdehnen.

2. Grundlagen

Als Basis für die weitere Ausarbeitung werden zunächst Begrifflichkeiten, Funktionsweisen und Einsatzmöglichkeiten von Web-Services dargestellt, um dann die für die weitere Betrachtung relevanten Standardisierungsbereiche herauszuarbeiten.

2.1 Services und Service-orientierte Architekturen

Kollaborative Geschäftsprozesse erfordern Service-orientierte Architekturen aus modularen Softwarekomponenten, die ihre Funktionalitäten als Services gekapselt über standardisierte Technologien und Schnittstellen zur Verfügung stellen.

Grundlegend für Service-orientierte Architekturen ist das Verständnis des Service-Begriffs. Services in Service-orientierten Architekturen lassen sich nicht mit dem Dienstleistungsbegriff der wörtlichen Übersetzung beschreiben. Vielmehr sind solche Services exakt definierte, gekapselte und eigenständige Funktionalitäten. “A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.” [Barr2003, S. 19]

Services kommunizieren, um eine bestimmte Aufgabenstellung, die z.B. die Abwicklung eines Geschäftsprozesses umfasst, zu lösen. Service-orientierte Architekturen können als Konglomerat von miteinander kommunizierenden Services interpretiert werden. “A service orientated architecture is essentially a collection of services. These services communicate with each other.” [Barr2003, S. 19]

Voraussetzung für die Konzeption und Implementierung von Services ist die Zerlegung der jeweiligen Anwendungslogik in einzelne, atomare Funktionen. Die Verteilung der Anwendungslogik auf unterschiedliche Services bedingt eine intensive Kommunikation zwischen den an einem Geschäftsprozess beteiligten Services. Nur wenn die beteiligten Services dieselbe Sprache sprechen, d.h. interoperabel sind, ist gewährleistet, dass die Kommunikation der Dienste reibungslos verlaufen kann. Voraussetzung hierfür sind standardisierte Schnittstellen, die eine stark formalisierte Kommunikation erzwingen.

Die Kommunikation kann vom simplen Datentransfer bis hin zur komplexen Koordination von zwei oder mehr Services im Rahmen einer umfangreichen Geschäftsprozessabwicklung reichen. Ähnlich dem konventionellen Client-Server-Modell übernimmt während der Kommunikation ein Service die Rolle des Service-Providers, der andere die des Service-Requestors. Der Service-Requestor, sozusagen der Client, baut eine Kommunikationsverbindung auf und sendet eine Anfrage an den Service-Provider. Dieser verarbeitet die Anfrage und sendet eine Antwort zurück an den Service-Requestor.

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Grundlage Service-orientierter Architekturen [Barr2003, S. 20]

2.2 Web-Services

Eine Möglichkeit zur Implementierung Service-orientierter Architekturen sind Web-Services. Was sich genau hinter diesem Begriff verbirgt und wie er im Kontext der nachstehenden Arbeit zu interpretieren ist, soll im folgenden dargestellt werden.

Eine sehr allgemeine und generische Auslegung beschreibt Web-Services als Anwendungen, auf die andere Anwendungen über das Internet zugreifen können: „Web services, in the general meaning of the term, are services offered by one application to other applications via the World Wide Web“ [Sun2003].

Unter Berücksichtigung des oben (Kap. 2.1 ) definierten Service-Begriffs sind Web-Services exakt definierte, gekapselte und eigenständige Funktionalitäten, die über das Internet bzw. über standardisierte Internettechnologien bereitgestellt werden. Diese Definition deckt sich weitgehend mit der des UDDI Konsortiums. „Web-Services are self-contained, modular business applications that have open, Internet-oriented, standards-based interfaces” [UDD2001a, S.1].

Implementierungsnäher beschreibt eine Definition der Web Services Architecture Working Group des W3C Web-Services: „A Web-Service is a software system identified by a URI (Uniform Ressource Identifier), whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web-Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols” [W3C2004a].

Hieraus lassen sich bereits konkrete Details ableiten, z.B. die Verwendung der Metasprache XML und von Standard-Internetprotokollen. Die Definition enthält darüber hinaus konkrete Hinweise zur Funktionsweise und lmplementierung von Web-Services. Sie werden definiert (defined), beschrieben (described), identifiziert (identified) und interagieren (interact).

Mit zunehmender Anwendungsreife und Herausbildung erster Standards kann diese Definition weiter ausdifferenziert werden. Demnach ist ein Web-Service “a custom end-to-end application that interoperates with other commercial and custom software through a family of XML interfaces (like SOAP, UDDI and WSDL) to perform useful business functions” [Lati2003].

Ähnlich, jedoch detaillierter, stellt sich die folgende Definition dar. “The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available” [Webo2004].

Hier wird konkret festgelegt, wozu welche Standards bei der Implementierung von Web-Services herangezogen werden:

1. Web-Services werden in der Metasprache XML definiert.
2. Web-Services interagieren über das Standardprotokoll SOAP.
3. Web-Services und ihre Schnittstellen werden über WSDL beschrieben.
4. Web-Services werden über den globalen Verzeichnisdienst UDDI registriert und identifiziert.

„SOAP, WSDL and UDDI are nowadays the core of Web services“ [AlCa2004, S.151]. Wie diese, im folgenden als Web-Service-Basisstandards bezeichneten Standards im Rahmen des Web-Service-Architekturmodells zusammenarbeiten, stellt das folgende Kapitel dar.

2.3 Web-Service-Architektur

Die Funktionalität des Web-Services wird als definierte und beschriebene Schnittstelle angeboten, die einen bestimmten Input verlangt und (gegebenenfalls) eine entsprechende Information als Ausgabe zurückliefert. Die hinter dem Web-Service liegende, technische Komponente ist nicht maßgeblich, allein die Kompatibilität des Web-Service bzw. dessen Schnittstelle ist entscheidend. Die Beschreibung der Schnittstelle wird in der XML-basierten Schnittstellenbeschreibungssprache WSDL vorgenommen.

Über diese Schnittstelle kann der Web-Service durch einen entfernten Funktionsaufruf angesprochen werden. Der entsprechende Funktionsaufruf wird durch das SOAP Protokoll realisiert. SOAP ist ein XML-basiertes Protokoll, das es, ähnlich konventionellen Remote Procedure Calls (RPCs), ermöglicht, Funktionsaufrufe auf entfernten Servern durchzuführen. Als Transportschicht wird dabei meist HTTP (Hypertext Transport Protocol) genutzt. SOAP wird deshalb oft als XML over HTTP bezeichnet, der eigentliche Funktionsaufruf als XML-RPC.

Zur Publikation der Web-Service-Beschreibung wird der globale, branchenübergreifende Verzeichnisdienst UDDI, selbst wiederum ein Web-Service, herangezogen. Das Zusammenwirken dieser Spezifikationen wird im Web-Service-Architekturmodell deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Web-Service-Architektur [Barr2003, S. 23]

1. Damit ein Web-Service (Service-Provider), von einem anderen Web-Service (Service-Requestor) gefunden werden kann, muss er in einem Directory wie UDDI registriert werden. Dazu wird der Web-Service in WSDL beschrieben und die Beschreibung als XML-Dokument über SOAP an das Directory übertragen und dort registriert. Die Service-Beschreibungen der registrierten Web-Services werden als XML-Dokumente in der Datenbank des Directories abgelegt.
2. Der Service-Requestor greift zur Identifikation eines geeigneten Web-Services mit einer SOAP-Anfrage, welche die Suchparameter enthält, auf das Directory zu. Wird ein geeigneter, den Suchparametern entsprechender Web-Service identifiziert, sendet das Directory das Suchergebnis via SOAP zurück an den Service-Requestor.
3. Nun ist der Service-Requestor in der Lage, den Service-Provider zu adressieren und eine Kommunikation aufzubauen. Geschäftsdaten werden dabei innerhalb der SOAP-Protokolls als XML-Nachrichten (Payload) ausgetauscht. Die Schnittstelle des Service-Providers verarbeitet die XML-Nachricht und gibt das Ergebnis der Verarbeitung an den Service-Requestor zurück.

2.4 Einsatzfelder für Web-Services

Einsatzmöglichkeiten für Web-Services bestehen grundsätzlich überall dort, wo eine Kommunikation zwischen IT-Systemen hergestellt werden soll. Grundsätzlich kann hierbei differenziert werden, ob es sich um unternehmensinterne oder -externe Systeme handelt.

Darüber hinaus werden seit geraumer Zeit Überlegungen angestellt, Web-Services nicht nur für die intermaschinelle, sondern auch für die Endbenutzerkommunikation einzusetzen [OAS2004b]. Dieses Einsatzfeld wird in der folgenden Betrachtung explizit ausgeklammert.

2.4.1 Enterprise Application Integration (EAI)

Viele Unternehmen haben über die letzten zehn Jahre massiv in den Auf- und Ausbau ihrer IT-Landschaften investiert und stehen nun vor einem Sammelsurium von IT-Systemen. Neben klassischen ERP-Systemen sind dies häufig CRM- (Customer Relationship Management) und SCM- (Supply Chain Management) Applikationen, sowie Web-Anwendungen, die unterschiedliche Plattformen und Technologien nutzen und bei größeren Unternehmen meist auf verschiedene Standorte verteilt sind. So entstanden einzelne „Information Islands“, isolierte Systeme ohne Kommunikationsschnittstellen zu weiteren Systemen des Unternehmens.

Um die unternehmensinterne Geschäftsprozessabwicklung über verschiedene Applikationen hinweg zu ermöglichen, müssen diese miteinander kommunizieren. Ein Kundenauftrag, der z.B. über eine CRM-Web-Applikation aufgegeben wird, soll im Idealfall sofort im ERP-System als Auftrag verbucht, als Kundenbedarf reserviert, kommissioniert und versandt werden. Dadurch entstehende Bedarfe in der Materialwirtschaft sollen vom ERP-System an eine SCM-Applikation zur Bestellabwicklung übergeben werden.

„The problem of EAI appears, when all these different steps are to be combined into a coherent and seamless process“ [AlCa2004, S.69]. Häufig geschieht dies zunächst manuell. Die Kundenbestellung über die Web-Applikation geht als eMail (electronic Mail) bei einem Mitarbeiter im Vertrieb ein, der die Daten manuell im ERP-System erfasst. Nach der Reservierung und Bereitstellung im ERP-System werden dadurch entstehende Bedarfe von einem Mitarbeiter im Einkauf aus dem ERP-System manuell in eine SCM-Anwendung eingepflegt um Lieferabrufe durchzuführen.

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Manuelle Prozessintegration im Unternehmen

Die Konsequenzen liegen auf der Hand. Bei jedem Medienbruch wird der elektronische Prozess unterbrochen, es muss manuell eingegriffen werden, indem die Daten aus dem einen System extrahiert, dann neu formatiert und in das nächste System eingegeben werden. Mitarbeiterkapazitäten werden gebunden, Kosten und Durchlaufzeiten steigen und manuelle Fehler schleichen sich ein.

Diese Medienbrüche durch Integration der isolierten Systeme zu eliminieren, ist das Ziel von EAI-Projekten. Aufgrund der Heterogenität der involvierten Systeme ist i.d.R. eine Vermittlungsschicht, eine so genannte Middleware, notwendig, welche die Kommunikationsbeziehungen zwischen den Systemen herstellt und steuert. „Middleware facilitates and manages the interaction between applications across heterogeneous computing platforms” [AlCa2004,S.29].

Idealerweise fungiert die Middleware als zentrale Integrationsdrehscheibe und nicht als Plattform für verschiedene Punkt-zu-Punkt-Anbindungen. Dadurch lässt sich die Anzahl der notwendigen Schnittstellen und Verbindungen zwischen den Systemen erheblich reduzieren.

Viele der heute auf dem Markt befindlichen Middleware-Produkte unterstützen die individuelle Anbindung von Standardsoftwareprodukten durch vorkonfigurierte Schnittstellen, so genannte Adapter. Über die technische Kommunikation hinaus kann die Manipulation und Zuordnung von Geschäftsdaten (Conversion and Mapping) zur Vereinheitlichung der Dokumentenstrukturen implementiert werden. Message Broker ermöglichen darüber hinaus die Definition komplexer Routing-Logiken zur Steuerung des Datenflusses.

Abbildung in dieser Leseprobe nicht enthalten

Bild 4: Konventionelle EAI-Integrationsarchitektur [AlCa2004,S.78]

Die Kommunikation mit und über die Middleware erfolgt i.d.R. mittels RPCs, die über applikationsspezifische Adapter auf die einzelnen Systeme abgesetzt werden. Die Kommunikation zwischen den Applikationen verläuft bei den meisten Middleware-Produkten Nachrichten basiert.

Ergänzend bzw. alternativ zu bestehenden Integrationsszenarien können Web-Services im EAI-Bereich als Middleware-Schicht zur Integration von heterogenen Systemen eingesetzt werden [Beim2002]. Hierzu wird die Kommunikation der applikationsspezifischen Adapter mit Web-Service Technologien, i.d.R. SOAP, realisiert.

Die Web-Service-Adapter zur Kommunikation mit den dahinter liegenden Systemen müssen im Einzelfall nach wie vor individuell codiert werden, um der Heterogenität dieser Systeme gerecht zu werden. Eine einzelne Web-Service-Schnittstelle kann diese Aufgabe nicht lösen. „Incorrectly assume that a single Web services interface can replace the need for hand-coded adapters and transformation logic” [Hamm2001, S. 15]. So bleibt abzuwarten, inwieweit Integrationssaufwände bei unternehmensinternen Projekten durch Web-Service-Technologien wirklich gesenkt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Bild 5: EAI-Integration über Web-Services (SOAP)

Die Kommunikation auf Protokollebene wird durch Web-Services auf jeden Fall standardisiert, was angesichts der traditionell proprietären Kommunikationstechnologien vieler Middleware-Produkte zu begrüßen ist [VeKu2002, S.2]. Mittlerweile unterstützen fast alle renommierten Hersteller von betriebswirtschaftlicher Standardsoftware und Integrationsinfrastrukturen offene Standards wie XML und SOAP, so dass bestehende Integrationsinfrastrukturen für Web-Services genutzt werden können. Der Investitionsschutz ist damit auch bei einer schrittweisen Einführung von Web-Service-Architekturen gewährleistet [Wich2003, S.11f].

2.4.2 Business-to-Business- (B2B) Integration

Im Unterschied zu EAI-Projekten werden bei B2B-Szenarien Systeme unternehmensübergreifend gekoppelt, um den Datenaustausch mit Kunden, Lieferanten oder Marktplätzen zu ermöglichen. Die Anforderungen sind grundsätzlich ähnlich denen in EAI-Integrationsprojekten, im Detail jedoch wesentlich anspruchsvoller, z.B. hinsichtlich der strukturierten Beschreibung von Geschäftsprozessen und Inhalten und der zugrunde liegenden Sicherheitsanforderungen [Wich2003, S.18].

Wie bei der manuellen Prozessintegration innerhalb des Unternehmens (Bild 3) werden die Systemgrenzen bei unternehmensübergreifenden Szenarien häufig durch manuelle Eingriffe überbrückt. Kundenaufträge schlagen in verschiedenen Medien, z.B. per Post, Fax oder Web-EDI-Transaktion im Unternehmen auf und werden manuell im ERP-System erfasst. Bestellungen werden aus dem Materialwirtschaftsmodul des ERP-Systems ausgedruckt und wiederum per Fax oder Post an den Lieferanten gesandt, der diese manuell als Auftrag in sein System eingibt.

Abbildung in dieser Leseprobe nicht enthalten

Bild 6: Manuelle Prozessintegration im B2B-Umfeld

Zur Überbrückung dieser Medienbrüche werden B2B-Integrationsprojekte initiiert, die häufig sehr komplex und aufwändig sind. Deshalb betreffen diese fast ausschließlich Geschäftsbeziehungen, bei denen sich dieser Aufwand auch lohnt, d.h. solche, bei denen die manuelle Integration besonders nachteilig hinsichtlich der dadurch anfallend Zeit, Kosten und Fehler ist. I.d.R. sind dies „statische, das heißt etablierte, langfristige Geschäftsbeziehungen zwischen bekannten Partnern“ [Hack2004, S.3].

Die Systeme der beteiligten Unternehmen werden dann als statische Punkt-zu-Punkt-Verbindungen über klassische Middlewaretechnologien, wie z.B. EDI (Electronic Data Interchange) oder SAP ALE (Application Link Enabling) integriert. Da auch im B2B-Bereich viele Integrationsplattformen auf proprietären Protokollen aufsetzen, sind häufig mehrere Middlewareplattformen notwendig, um unterschiedliche B2B-Koppelungen abzubilden. „The lack of a central middleware platform means that interactions are managed in a point-to-point manner, possibly using different middleware platforms to communicate with different parties” [AlCa2004, S. 129]. Diese Middleware-Produkte können über eine zusätzliche EAI-Middleware gekoppelt werden, die als Gateway zu den internen Systemen fungiert.

[...]