Enterprise Application Integration (EAI) befasst sich mit dem Aufbau einer technischen Infrastruktur und mit der Integration von Geschäftsprozessen. Das Konnektoren-Modell löste einen Großteil der Probleme – aber eben nicht alle. Web Services versprechen den Aufbruch zu neuen Horizonten. Denn sie ermöglichen nun auf Grund allgemein akzeptierter Internetstandards auch die Integration von Applikationen, die früher nur schwer einzubinden waren. Der technologische Fortschritt bietet damit die Basis zur Erschließung neuer Geschäftspotenziale. Das grundlegende Modell von Web Services ist nicht neu – unter dem Client-Server-Label ist eine serviceorientierte Applikationsarchitektur seit vielen Jahren gebräuchlich. Konzeptionell betrachtet ändert sich in einer verteilten Infrastruktur auch mit den Web-Services-Ansätzen wenig. Ein Client (Service User) fordert von einem Server (Service Provider) Dienste an, die dieser durch die Abarbeitung bestimmter Funktionen bereitstellen kann. Entscheidend ist, über welche Eigenschaften und Funktionen ein Client und ein Server verfügen müssen, damit beide sich verstehen.
Für die Kommunikation zwischen beiden führt das Modell der Web Services Funktionen ein, damit der Server seinen Dienst über die XML-basierte Beschreibungssprache WSDL (Web Service Description Language) zur Verfügung stellt. WSDL kümmert sich – unabhängig vom konkreten Kommunikationsprotokoll – um die Definition einer strukturierten Form der Kommunikation. Die WSDL-Spezifikation geht von einer abstrakten Interaktion zwischen Service-Provider und Service-User aus, bei der beide Nachrichten übermitteln. Jede Message verfügt über strukturierte Inhalte. Einzelne Übertragungen oder auch einzelne Nachrichten haben die Form von Operationen – konkretisiert als Funktionsaufruf mit Rückgabewert.

Web Services: eine Request-Reply-Sequenz

Die abstrakte, protokollunabhängige Definition umfasst Daten-, Message- und Port-Typen. Durch Binding-Definitionen wird die abstrakte Beschreibung der Dienste auf konkrete Schnittstellenspezifikationen für ein bestimmtes Kommunikationsprotokoll abgebildet. Die Message-Typen werden in der XML Schema Definition (XSD) festgelegt. Ein herausragendes Merkmal von XSD ist die umfangreiche Unterstützung von Datentypen. Eine Operation kann aus ein bis drei Messages bestehen: einer Input, einer Output und möglicherweise einer Fault Message, für deren Behandlung eigens Vorkehrungen zu treffen sind. Abhängig davon, ob bei einer Operation eine Input und eine Output Message oder nur eine von beiden auftritt, gibt es verschiedene Typen von Operationen in einem Port-Typ. Zusammen genommen bildet die gesamte Request-Reply-Sequenz einen Web Service.

Denkbar ist nun eine Internet-Situation, in der der Service-User den Service-Provider nicht kennt. Neben Client und Server kommt dann die dritte Säule des Web-Services-Modells zum Tragen: die UDDI-Registrierdaten-bank (UDDI = Universal Description, Discovery and Integration). Sie soll öffentlich im Internet zugänglich sein und programmatische Beschreibungen von Unternehmen sowie den Diensten enthalten, die sie unterstützen. Zwischen Modell und Realität klafft jedoch wie so oft (noch) eine Lücke. Mehrere Hindernisse stellen sich der Nutzung von UDDI gegenwärtig noch in den Weg: Kaum jemand wird seine Service-Leistungen in einem Business-to-Consumer-Szenarium unentgeltlich anbieten – es bleibt das Problem der Abrechnung solcher Dienste. Zudem ist auch im Business-to-Business-Segment kein Modell bekannt, das die UDDI-Services benötigen würde. Darüber hinaus müssten zusätzliche Anforderungen hinsichtlich Workflow-Funktionalität, Zuverlässigkeit, Transaktionsverhalten und Sicherheit erfüllt sein.

Web Services im Umfeld von Enterprise Application Integration

Bis sich der Ansatz der Web Services im unternehmensübergreifenden Einsatz durchsetzt, dürfte noch einige Zeit vergehen. Einerseits sind eine Reihe von technologischen Hürden zu bewältigen, und andererseits müssen sich klare Einsatzgebiete abzeichnen. Ganz anders sieht es unternehmensintern aus. Gerade dort, wo eine Enterprise Application Integration ansteht, existieren vielfältige Ansatzpunkte.

Dabei werden die Schnittstellen der zu integrierenden Anwendungen sowohl auf Client- als auch auf der Server-Seite als Web Services realisiert. Angesprochen ist hier der Kernbereich eines Integrations-Servers, der sich mit dem Datentransport und dem Abgleich (Mapping) zwischen internen Applikationen befasst. Die in WSDL vorliegenden und SOAP-unterstützenden Schnittstellen haben dabei den großen Vorteil, dass sie auf einer Standardtechnologie basieren, die von Anwendungen unterschiedlicher Hersteller verstanden und akzeptiert wird. Eine Applikation mit solch einem Interface zu versehen, betrifft nun weniger die gängigen ERP-, CRM- und SCM-Produkte, sondern Programme, für die keine vorgefertigten Adapter angeboten werden – sei es, weil sie nur selten in Integrationsprojekten benötigt werden oder weil es sich um eigenentwickelte Anwendungen handelt. Verfügen Applikationen über Web-Services-Schnittstellen, wird die Technologie auch eingesetzt werden, wo eine direkte Point-To-Point-Kommunikation zwischen internen Applikationen benötigt wird – beispielsweise bei der Anbindung eines neuen Web Front Ends an vorhandene Alt-Anwendungen. Daher bietet diese Technologie die notwendigen Werkzeuge, um einen bedeutenden Evolutionsschritt auf dem Gebiet verteilter Applikationen und der Systemintegration zu erreichen.
Zunächst einmal muss der Client SOAP unterstützen und benötigt dazu ein in WSDL erstelltes Stück Software. Um diese Brücke zwischen der Client-Anwendung und der SOAP-Message herzustellen, muss entweder Code mit einer Programmiersprache erzeugt werden oder Unternehmen setzen einen Integrations-Server ein, der mit einem Web-Services-Modul die Web-Services-Programmierung verbirgt.

Web Services auf der Client- und der Server-Seite

Web Services ermöglichen eine universelle Verbindung von unterschiedlichen, unternehmenskritischen Systemen, indem sie ein einfaches, standardisiertes Interface für alle Anwendungen bieten. Allerdings bieten Web Services alleine nur einen Teil des Integrations-Puzzles. Eine umfassende Integrations-Plattform muss Web Services mit einem professionellen Support für das Management semantischer Transformationen und Geschäftsprozesse kombinieren. Nur so lässt sich eine system- und unternehmensweite Integration von Anwendungen realisieren, deren zentralen Bestandteil das Business Process Management (BPM) bildet.

In der Auftragsannahme (Order Management) beispielsweise können Web Services den Kreditrahmen desjenigen, der eine Anfrage stellt, die Lagerverfügbarkeit der Waren, die Dauer der Lieferung zusätzlicher Mengen sowie die Preise überprüfen, die Bestellung bestätigen, Produkte ausliefern und die Abbuchung durchführen. Während jeder einzelne Web Service eine unabhängige Einheit darstellt, die spezifische Geschäftsvorgänge ausüben kann, ist die Kombination von Web Services mit BPM eine leistungsfähige Anwendung, die Zeit und Kosten bei Transaktionsprozessen einspart.

Fazit: Ein Integrations-Server – ausgestattet mit Web-Services-Modulen – spielt sowohl auf der Client- als auf der Server-Seite eine wichtige Rolle. Einer Applikation gegenüber, die eine Funktion aufruft, agiert die Integrationsplattform als Client und bindet weitere Systeme, von denen Daten benötigt werden, als Server ein. Die Kommunikation erfolgt ausschließlich über SOAP-Messages, die in WSDL dokumentierte Informationen austauschen. Mit Web Services lassen sich so, wie im Beispiel des Order-Managements skizziert, mehrstufige Geschäftsprozesse initiieren, die eine Vielzahl interner Systeme einschließen. Das Modell konsequent zu Ende gedacht, können einzelne Aktivitäten eines Geschäftsprozesses von mehreren Applikationen gemeinsam verwendet werden.

Vitria Technology GmbH

D–60528 Frankfurt

Telefon: (+49) 069/67733-0

www.vitria.com