Ein Prozessthema

Wolfgang Beinhauer ist Leiter Marktstrategie Team Web Application Engineering beim Fraunhofer Institut für Arbeitswirtschaft und Organisation, Stuttgart.

Nur wenige Themen werden derzeit so heiss diskutiert wie Service-orientierte Architekturen (SOA). Demnach verwandeln sich grosse, monolithische Silos von Unternehmenssoftware in kleine, flexibel miteinander kombinierbare Funktionsmodule, die mühelos mit grafischen Werkzeugen zu neuen Anwendungen zusammengesetzt werden. Von Echtzeitunternehmen ist die Rede, bei denen der Chef sich allmorgendlich damit beschäftigt, die Abarbeitung seiner jüngst umgestalteten Prozesse auf Kontrollmonitoren zu überwachen und anhand von Zeitungsmeldungen über neue Trends in Echtzeit anzupassen. Das ganze passiert völlig ohne Eingriff eines Programmierers, allenthalben wird Geld eingespart, und die neu gewonnene Innovationsfähigkeit der Industrie befähigt die Unternehmen zu neuen Masseneinstellungen. Ein überzeichnetes Bild? - Wenn man manchen Versprechungen Glauben schenken mag, wohl nicht. Um so erstaunlicher ist es, dass die konkrete Umsetzung service-orientierter Integrationsprojekte vergleichsweise träge in Gang kommt, wo doch die Vorteile augenscheinlich auf der Hand liegen. In der Tat finden sich nur wenige grosse Projektreferenzen, und manche entpuppen sich bei genauerem Hinsehen als konventionelle Integrationsprojekte, denen aus Imagegründen das Schild «SOA» angehängt wurde. Was also sind die Gründe für die zögerliche Haltung vieler Unternehmen zu Serviceorientierung?

SOA-Hemmnisse

Bei der Suche nach Ursachen für den bislang trägen Einstieg in die Serviceorientierung stösst man auf vielfältige Probleme. So gibt es technische Schwierigkeiten, die zum Teil mit dem Reifegrad zugrundeliegender Schlüsseltechnologien zusammenhängen, aber auch wirtschaftlich-organisatorische Probleme, wie etwa die Schwierigkeit, einen Nachweis der wirtschaftlichen Rentabilität einer Investition in eine SOA zu führen. Bei Investitionsentscheidungen ist eine grosse Unsicherheit zu verzeichnen, was den richtigen Zeitpunkt angeht, aber auch hinsichtlich der Frage, welche Technologien und Produkte sich langfristig etablieren werden. Zu gross erscheint das Risiko, sich durch übereilte Beschlüsse in eine Sackgasse mit auslaufenden Entwicklungen zu manövrieren oder neue Abhängigkeiten von Anbietern aufzubauen.

Verschiedene Ansätze

Kernidee einer service-orientierten Architektur ist die Integration durch Dekomposition, das heisst die Zerlegung grosser, monolithischer Anwendungen in kleinere Softwaremodule, genannt Services. Diese werden durch Ablaufbeschreibungen, die so genannte Orchestrierung, flexibel miteinander kombiniert. Dieses Vorgehen wirft unmittelbar zwei Fragen auf: Wie werden grosse Anwendungen so zerteilt, dass ihre Zerlegung sinnvoll miteinander kombinierbare Module ergibt? Und, zweitens: Wie lassen sich Services wieder zu komplexen Anwendungen zusammensetzen? Die erste Frage zielt primär auf eine probate Methodik ab, geeignete Prozesse und Komponenten zu identifizieren und die Granularität der Services festzulegen. An dieser Stelle soll der zweite Aspekt genauer beleuchtet werden, für den sich ein technologischer Konsens der Anbieter abzeichnet. Grosse Einigkeit besteht bereits über das Grundmuster einer service-orientierten Architektur: Ein robuster Kommunikationskanal, der Enterprise Service Bus (ESB), bildet das Rückgrat einer SOA. An ihn angeschlossen sind zwei Kategorien von Services: Applikationsservices, die die Geschäftslogik in Form von Anwendungsbausteinen oder Ablaufbeschreibungen enthalten, und Infrastrukturservices, also solche, die Infrastrukturaufgaben übernehmen, wie etwa Authentifizierung, Protokolladaption oder Parameterkonversion. Die Services kommunizieren nun untereinander durch Nachrichtenaustausch, wobei die Lokalisierung der angesprochenen Services und die Zustellung der Nachrichten Aufgabe des ESB ist. Daneben hat sich als zweite zwingende Komponente einer SOA-Suite eine Laufzeitumgebung etabliert, die es erlaubt, formal beschriebene Abfolgen von Serviceaufrufen zur Prozessautomatisierung abzuarbeiten.

Standards und Technologien

Geht es nun eine Ebene tiefer von den Grundstrukturen auf verwendete technologische Standards, trifft man auf zahlreiche Initiativen und De-facto-Standards, deren Reifegrad recht unterschiedlich zu bewerten ist. Da jeder Standard nur soviel wert ist, wie ihm die Key Player am Markt beimessen, hilft bei der Bewertung der Zukunftssicherheit ein Blick auf die Hersteller. Während die grundlegenden Web Service Standards und Protokolle Soap (Simple Object Access Protocol), WSDL (Webservices Description Language) und UDDI (Universal Description, Discovery and Integration) schon nicht mehr in der Diskussion stehen, ist mit BPEL (Business Process Execution Language) ein bereits weit verbreiteter Standard zur Formalisierung von Ablaufbeschreibungen jüngst noch einmal in Bewegung gekommen. Vertrauen gibt hier jedoch die Tatsache, dass mit der Generalistin IBM, der Datenbänklerin Oracle, der Application-Server-Spezialistin Bea und Microsoft vier Key Player aus unterschiedlichen Bereichen zusammengefunden haben und somit ein entsprechendes Momentum am Markt geschaffen haben. So hat IBM bereits im vergangenen Jahr ihre Software-Produktpalette rund um Websphere auf Serviceorientierung ausgerichtet, und auch Oracle hat gerade auf dem Gebiet der Prozessautomatisierung einen grossen Schritt in Richtung Serviceorientierung getan und damit zur Festigung von BPEL beigetragen. Zum weiteren Aufbau des Web Service Stack hat sich mit der Web Services Interoperabiliy Organization (WS-I) ein Industrieverband aus Anwendern und Technologen formiert. WS-I, dem inzwischen über 130 Mitglieder angehören, hat so bereits die Verabschiedung des sicherheitsrelevanten Standards WS-Security für sichere Nachrichtenkonversation auf den Weg gebracht. Weitere Standardisierungen, unter anderem WS-Transaction zur Sicherstellung der Transaktionssicherheit, werden folgen. Ein weiterer für die Praxis besonders wichtiger Aspekt ist die Konnektivität zu Legacy-Systemen. Die in den meisten Produkten zum Aufbau service-orientierter Architekturen enthaltenen Adaptoren und Konnektoren arbeiten als Verbindungsglieder, die bestehende Altsysteme als Inseln an eine SOA andocken, was dem Gedanken der Serviceorientierung widerspricht. Um die volle Interoperabilität zu gewährleisten, auch unter Nutzung der in der Praxis wichtigen Kommunikationsstandards JMS und MQ Series, wurde das momentan von Apache verwaltete Web Service Invocation Framework (WS-IF) entwickelt, das ebenfalls von den Grossen am Markt intensiv genutzt wird. Auch kleinere Hersteller wie Capeclear oder Progress Software haben hier innovative, aber gleichwohl standardkonforme Integrationssuiten auf den Markt gebracht. Die Entwicklung des Web Service Stacks wird damit jedoch nicht abgeschlossen sein. Insbesondere zum Ausdruck von Service Level Agreements (SLA) oder zur besseren Steuerung von Nutzungsschnittstellen müssen zusätzliche Protokolle festgelegt werden. An dieser Stelle zeigt sich schliesslich, dass die Verbreitung service-orientierter Architekturen erst noch an ihrem Anfang steht. Angesichts des überwältigenden Industrie-Kommitments ist am Erfolg jedoch nicht zu zweifeln.

Service orientierte Architekturen sind in erster Linie ein Prozessthema. Der Erfolg eines Projekts zur service-orientierten Ausrichtung der Middleware wird sich an der geeigneten Auswahl der unterstützten Prozesse bemessen - das heisst insbesondere, dass der fachseitigen Anforderungserhebung besondere Bedeutung zukommt. Darüber hinaus sind neben allen technischen Belangen auch akzeptanzbildende Massnahmen bei den Mitarbeitern gefragt. Währenddessen kommt der Auswahl passender Produkte eine nur untergeordnete Bedeutung zu. Dies ist auch insoweit wenig überraschend, als das Paradigma der Serviceorientierung ja gerade die Interoperabilität heterogener Systeme anstrebt. Für die Durchführung eines Pilotprojekts entlang eines unternehmensinternen Kernprozesses und die damit verbundene Wertschöpfung sind die erforderlichen technischen Rahmenbedingungen jedoch gegeben.