Bislang werden Web-Services hauptsächlich als Aspekt der Softwareinfrastruktur betrachtet und die Diskussionen vor allem zwischen technisch orientierten Experten und der IT-Abteilung geführt. Insbesondere die Kernkomponenten des mit Hilfe der Extensible Markup Language (XML) beschriebenen Kommunikations-Layers, das Simple Object Access Protocol (Soap) und die Web Services Description Language (WSDL), erfreuen sich dank ihrer Nutzung von Internet-Technik sowie offenen Schnittstellen- und Protokollstandards einer wachsende Akzeptanz durch die Fachleute. So wichtig diese Debatte um Spezifikationen, Standardisierungsgremien und leistungsfähige Programmierwerkzeuge auch ist, wird das Konzept der Web-Services doch erst durch die darauf aufsetzenden Anwendungen und Geschäftsmodelle für Unternehmen nützlich.
Allgemein sehen Analysten wie Martin Haas, Project Manager Consulting bei IDC Central Europe, die strategischen Vorteile von Web-Services vor allem darin, dass sie die bisher starren Verknüpfungen zwischen Anwendungen und Anwendungskomponenten aufheben und durch anpassungsfähige, lose Verbindungen ersetzen (siehe Kasten "Das Versprechen" auf Seite 13). Dadurch können nicht nur Komponenten des eigenen Unternehmens, sondern auch externe Funktionen genutzt werden. Eine Integration über Web-Services verspricht zudem die Prozesskosten durch die Beseitigung von Medienbrüchen sowie die Einbindung von Partnersystemen zu senken.
Auch rechnen Marktbeobachter mit einem Mehrwert durch die Automatisierung der Wertschöpfungskette über spezialisierte Dienstleister. Letztere wollen sich zunehmend auf ihr Kerngeschäft konzentrieren (Logistik, Beschaffung, Abrechnung, Benutzerverwaltung etc.) und brauchen für die Kopplung an andere Systeme sauber definierte Schnittstellen, wie sie Web-Services versprechen. Dies ist gerade für Mittelständler interessant, die nicht über die finanziellen Möglichkeiten großer Konzerne verfügen und keine komplette Infrastruktur aufbauen können.
Unter kontrollierten Bedingungen testen
Laut IDC-Berater Haas durchlaufen Web-Services derzeit eine ähnliche Phase der Akzeptanz wie das Internet Mitte der 90er Jahre. Die in Unternehmen vorherrschende Meinung ist, dass das mit Web-Services verbundene Konzept ein interessantes und vielversprechendes Ziel darstellt, wenngleich die Technologie erst in einigen Jahren voll verfügbar sein werde (siehe auch Grafiken "Erwartungen an die Geschäftsprozesse" und "Erwartungen an den Marktprozess" auf Seite 13). Dies hält jedoch eine wachsende Gruppe von Anwendern nicht davon ab, die Nutzung von Web-Services-Technologien heute schon unter kontrollierten Bedingungen zu prüfen und in einzelnen Fällen produktiv einzusetzen.
Ein Beispiel ist der Rechenzentrumsdienstleister Sparkassen Informatik, der Finanzanwendungen von rund 270 Sparkassen betreut. In einer Machbarkeitsstudie zusammen mit IBM Global Services wollte das Unternehmen vor kurzem prüfen, ob Web-Services in Zukunft geeignete und leistungsstarke Standards für die hauseigene System- und Anwendungsarchitektur bieten können. Das Ziel liegt aus technischer Sicht darin, den externen Zugriff auf die Host-Anwendungssysteme mit Hilfe von WSDL und Soap zu implementieren und die Leistungsfähigkeit der neuen Schnittstelle zu testen. Diese Aufgabe übernimmt bisher eine selbst entwickelte "dynamische Schnittstelle". Sie erlaubt den transaktionsorientierten Backend-Zugriff auf bankfachliche Funktionen der MVS-Subsysteme und basiert auf der Messaging-Middleware "MQ Series" und dem Transaktionsmonitor Cics. Sie muss Corba, Enterprise Javabeans, DCOM, .NET sowie proprietäre Entwicklungen unterstützen.
Aussicht auf reduzierte Schnittstellen-Kosten
Nachdem Workshops die technischen Grundlagen des Projekts erklärt hatten, konnte anhand einer Testinstallation zwischen den Standorten Offenbach und Münster nachgewiesen werden, dass die Web-Services die Anforderungen erfüllen und beispielsweise die J2EE- und .NET-Welt interoperabel machen. Ebenfalls zeigte sich, dass es möglich war, mit Hilfe des Java-Entwicklungswerkzeugs "Websphere Studio Application Developer" eine Web-Services-Schnittstelle für mehr als 250 bankfachliche Funktionen automatisch zu erzeugen. "Die Generierung der WSDL-Datei dauerte nur wenige Minuten. Wenn sich an der darunter liegenden fachlichen Schnittstelle etwas ändert, dann wird einfach ein neues WSDL-File generiert", erklärt Manfred Rieck, Projekt-Manager IBM Global Services, Bereich Finance. Aufgrund der guten Resultate glaubt man bei der Sparkassen Informatik, durch die Kapselung der bisherigen Schnittstellen zu den externen Systemen vor allem die Kosten für Wartung und Anwendungsentwicklung senken und den Kunden neue Dienste einfacher, schneller und funktioneller bereitstellen zu können. Wann und in welchem Umfang nun der Umstieg auf Web-Services erfolgen soll, weiß Rieck allerdings noch nicht.
Die Aufwände, die neue Technologie zu implementieren, hält der Berater für "ausgesprochen gering". Insbesondere Anwender, die bereits die systemübergreifende Anwendungsintegration betreiben, neudeutsch: Enterprise Application Integration (EAI), könnten die Vorteile von Web-Services nutzen, "ohne Mehrkosten erwarten zu müssen". Die Komplexität heutiger Anwendungen wird allein durch den Einsatz von Web-Services indes nicht geringer, und es wäre auch verkehrt, sich bei der Beurteilung nur von technischen Aspekten leiten zu lassen. Vielmehr sollte sich die Entscheidung am Geschäftsmodell orientieren - eine strategische Sichtweise, die nach Riecks Erfahrung erst seit kurzem die Kundengespräche bestimmt.
Prozesse auf dem Prüfstand
Für Consultants, die laut dem Berater meist "so oder so im Haus des Kunden" sind, ergeben sich bei diesen Verhandlungen zudem neue Möglichkeiten, ins Geschäft zu kommen, da mit dem Aufbau von Web-Services-Architekturen auch bisherige Prozesse überdacht und optimiert werden könnten. Erste derartige Projekte habe man laut Wolfgang Dostal, IT Architekt IBM Global Services im Bereich Finance, bereits gemacht, wobei aber die Architektur nur für geschlossene Benutzergruppen und nicht für das Web konzipiert wurde. "Im ersten Durchgang versucht man, bestehende Prozesse zu optimieren und Medienbrüche aufzuheben, im zweiten Durchgang neue aufzusetzen oder Geschäftsmodelle umzusetzen", erklärt Dostal die Vorgehensweise.
Ein anderes Beispiel für eine schnellere und kostengünstige Integration bestehender Anwendungen mit Hilfe von Web-Services ist das Projekt "Oliva", das der Dienstleister Bertelsmann Mediasystems für sein Mutterhaus betrieben hat. Im Mittelpunkt stand hier eine in C++ entwickelte Software für die Kreditkartenautorisierung und Online-Überprüfung von Bankverbindungsdaten in Deutschland. Da eine Neuentwicklung der praxiserprobten Lösung laut Sales Manager Christian Modersohn keinen Sinn gegeben hätte, sollte sie nur einen in XML beschriebenen Kommunikationslayer erhalten, über den sich Shop-Systeme oder ähnliche Web-basierende Abrechnungsverfahren einfacher als bisher anbinden lassen.
Mit J2EE- und XML-Erfahrung leichtes Spiel
"Wir versprechen uns von dieser Art der Schnittstellen-Programmierung geringere Setup-Kosten für die Client-Anwendungen unserer Kunden", erklärt Modersohn. Die Erfahrung war auch hier, dass der Aufwand für die Generierung und Implementierung des Web-Service - in diesem Fall mit Hilfe der Entwicklungsumgebung "Weblogic Workshop" und des Applikations-Servers "Weblogic" von Bea Systems - sehr gering war. "Da sich hinter Web-Services keine grundlegend neue Technik verbirgt, können sich Experten, die Erfahrung mit J2EE, Applikations-Servern und XML haben, recht schnell mit Soap und WSDL anfreunden." Zusätzliche Beratungsdienstleistungen mussten in diesem Fall dank der Kenntnisse beim Bertelsmann-Dienstleister nicht eingekauft werden. Modersohn empfiehlt Unternehmen zu prüfen, ob sich die Leistung, die sie als Web-Service anbieten möchten, durch Methoden und Objekte abbilden lässt. "Kann diese Frage mit Ja beantwortet werden, sollte sich der Web-Service problemlos als Komponente behandeln lassen."
Während Unternehmen wie Bertelsmann mit Web-Services bestehende Anwendungs-Schnittstellen kapseln, geht es bei der Weiterentwicklung des Umweltdatenkatalogs (UDK) darum, den Benutzern zusätzliche Dienste über die XML-Schnittstelle anzubieten. Der Katalog ist ein Meta-Informationssystem, das die dezentral verwalteten Daten der Umweltbehörden in Deutschland und Österreich vereint. Fachleuten wird so eine katalogübergreifende Suche ermöglicht.
Neben einer Client-Server-basierenden Version des UDK, die in erster Linie zur internen Erfassung von Umweltdaten gedacht ist, gibt es mittlerweile eine Web-gestützte Variante, die der Recherche dient. Sie bietet neben Schnittstellen zum Deutschen Umweltinformationsnetz und dem Ingeo-Server, der Geodaten vorhält, auch ein XML-Interface, über das per Soap mit anderen Anwendungen kommuniziert werden kann. Damit wurde eine definierte Schnittstelle geschaffen, über die sich das Web-UDK in die Umweltinformationssysteme der Partner einbinden lässt, so dass weitere Metadatensysteme wie der bayerische Umweltkatalog nun virtuell bereitstehen.
Laut Erich Weihs, Regierungsdirektor und stellvertretender Referatsleiter, Schwerpunkt Informationssysteme, im bayerischen Umweltministerium, erlaubt der virtuelle UDK Informationssuchenden, in den Datenbeständen der verteilten Kataloge zu recherchieren, als ob sie in einem zentralen Katalog verwaltet würden. Ferner sei es möglich, über den Server Ausschreibungen zu veröffentlichen und die Bewerbungen automatisch per Mail an die Fachabteilungen weiterzuleiten.
Ginge es nach Weihs, sollte die Datenintegration und -speicherung künftig nur noch über XML erfolgen. So beschäftige man sich in seiner Abteilung seit Jahren mit der Metasprache und verwalte den eigenen Umweltkatalog auf der XML-Datenbank "Tamino" der Software AG. Unternehmen, die sich mit Web-Services beschäftigen, sollten sich nicht mit den Werbesprüchen der Hersteller abfinden, die mit ihren Tools die automatische Generierung von Web-Services verheißen, ohne dass man sich weiter mit XML beschäftigen müsse. "Das ist Schwachsinn. Die Unternehmen müssen sich mit XML auseinander setzen." Er rät, eine Lizenz für eine "gescheite Datenbank" zu erwerben und ansonsten nur Open-Source-Produkte für die Arbeit mit XML und Web-Services zu verwenden. Neben der Software gebe es zudem viele XML-Spezifikationen (Dokumentationen), die sich kostenlos aus dem Web laden und mit Tools wie "XML Spy" weiterbearbeiten ließen.
Zu den Unternehmen, die mit Web-Services nicht nur Informationen bündeln, sondern mit ihnen bereits Geschäftsmodelle umsetzen, gehört schließlich die Deutsche Telekom. Schon im März 2001 hatte man die Konzeption eines WAP-Portals abgeschlossen, erzählt Uwe Spiegel, Project Manager Authorized Java Center bei der für das Projekt verantwortlichen Dienstleistungstochter T-Systems. Das mittlerweile unter "T-Mobile Online" firmierende Angebot sollte von Anfang an nur die technische Infrastruktur, unter anderem inklusive eines Abrechnungssystems, stellen.
Provider sehen neues Geschäftsmodell
Alle Inhalte und Messaging-Dienste kommen hingegen über flexible, pflegeleichte und sauber definierte Web-Services-Schnittstellen von unterschiedlichen Third-Party-Anbietern. Dieser Ansatz eines "Web-Services-Providers" wird derzeit lebhaft zwischen Analysten debattiert und von Herstellern wie Microsoft beworben, verheißt er doch ein neues, erst durch Web-Services entstehendes Geschäftsmodell. Allerdings wird bezweifelt, dass ein Provider bei einer wachsenden und wechselnden Zahl angeschlossener Web-Services-Komponenten seinen Kunden noch eine gute Verfügbarkeit und Servicequalität der Angebote zusagen kann.
Laut Spiegel nimmt die Komplexität mit der steigenden Zahl von Komponenten nur theoretisch zu, denn in der Praxis muss das Prinzip "teile und herrsche" regieren. "Die Verfügbarkeit der Angebote liegt nicht in der Verantwortung von T-Mobile Online, sondern jeder Anbieter ist selbst verantwortlich für seine Module." T-Mobile Online spiele nur den übergeordneten Provider, der die Information via WAP versendet. Allerdings wird die Dienstequalität mit Hilfe von automatisierten Tests (Monitoring) regelmäßig geprüft, die Antwortzeiten gemessen und kontrolliert, ob und wie oft Inhalte abgefragt werden. "Danach kann man die Angebote nach Qualität ordnen und sich gegebenenfalls vom Zulieferer trennen."
Wenig Spielraum für Experimente
T-Systems verwende bisher nur Soap und WSDL, beobachte laut Spiegel aber auch neuere Web-Services-Standards intensiv. "Der Markt erlaubt momentan kaum Experimente mit neuen Standards. Man muss sich deshalb auf die machbaren Dinge konzentrieren." Web-Services erfüllten in dieser Hinsicht trotz ihres erst kurzen Lebens die in sie gesetzten Erwartungen.
Der oft zusammen mit Soap und WSDL genannte Standard Universal Description, Discovery and Integration (UDDI), der es erlauben soll, Web-Services zentral zu registrieren und zu veröffentlichen, sei zwar ein interessantes Thema, für das aber derzeit die Business Cases fehlten. "UDDI wäre zwar für die Deutsche Telekom ein interessanter Ansatz, mit dem sie sich als Trust-Center etablieren könnte, aber derzeit mangelt es noch an Tools, und auch die Akzeptanz ist nicht wie bisher erwartet."
Unternehmen sollten vor dem Einstieg in die Web-Services-Welt "sehr intensiv über den wirtschaftlichen Nutzen nachdenken und prüfen, ob es sich lohnt, beispielsweise eine voll funktionsfähige Schnittstelle nur wegen eines neuen Trends anzupassen". In Architekturen, in denen Systeme eng gekoppelt werden müssen, um eine hundertprozentige Transaktionssicherheit zu gewährleisten, wären Web-Services die falsche Wahl. "Für die Abbildung asynchroner Prozesse sind Web-Services derzeit nicht geeignet, da nur ein synchroner Aufruf spezifiziert ist. Für solche Szenarien sollte der Anwender daher eine Messaging-Lösung verwenden", sagt Spiegel. Ist hingegen eine lose gekoppelte Systemarchitektur geplant, in der keine wechselseitigen Abhängigkeiten im Workflow bestehen, könnten Web-Services ebenso Sinn geben, wie in heterogenen, wenig beeinflussbaren Systemlandschaften, wo sie über diverse Schnittstellen hinweg einen Standard setzen könnten.
Das VersprechenWeb-Services ermöglichen einem Unternehmen:
- die Aktivitäten (Funktionen) zu definieren, die es benötigt, um seine Geschäftsprozesse erfolgreich auszuführen;
- zu entscheiden, welche dieser Funktionen von seiner internen IT-Abteilung unterstützt und welche zufrieden stellend von externen Services abgedeckt werden können;
- zu entscheiden, welche der bereitgestellten Services Kunden, Partnern und Lieferanten extern verfügbar gemacht werden sollen;
- sicherzustellen, dass alle Funktionen nahtlos zusammenarbeiten und gleichzeitig flexibel genug sind, dass Povider ausgetauscht oder einzelne Funktionen ersetzt werden können;
- die Abhängigkeit von der zugrunde liegenden Technologie zu beseitigen;
- erprobte Funktionen zu nutzen oder neue zu implementieren, ohne dabei an Investitionen gefesselt zu sein, die in der IT getätigt wurden. Quelle: IDC
Abb.1: Erwartungen an die Geschäftsprozesse
Quelle: Cap Gemini Ernst & Young
Abb.2: Erwartungen an den Marktprozess
Quelle: Cap Gemini Ernst & Young