Die Themen Web-Services (WS) und Service-orientierte Architekturen (SOA) werden heiß diskutiert und in der Softwareentwicklung als ein wichtiges, neues Architekturparadigma für eine breite Klasse von Anwendungen gehandelt. Wie bei vielen anderen populären Themen in der IT sollte auch hier für alle Beteiligten die Devise gelten, sich verantwortungsvoll und möglichst emotionslos mit der neuen Technik auseinander zu setzen. Beobachtet man aber diesbezüglich die Diskussionen, so fällt auf, dass vor allem die Chancen betont werden - die Risiken treten dagegen in den Hintergrund.

SOA verspricht weitreichende Interoperabilität heterogener Plattformen, basierend auf allgemein anerkannten Standards wie XML, Soap und WSDL. Schnell hat man aber erkannt, dass die Qualitätsattribute dieser WS-Standards der ersten Generation im Hinblick auf eine sichere, zuverlässige Kommunikation kaum ausreichen, um unternehmenskritische Systeme aufzubauen. Beispielsweise lässt sich mit den bisher in gängigen Entwicklungswerkzeugen implementierten Standards nicht einmal garantieren, dass ein Web-Service-Aufruf am Ziel überhaupt ankommt.

Trotz oder gerade wegen dieser Schwachpunkte investieren alle "Big Player" massiv in die Definition, Verabschiedung und Umsetzung der zweiten Generation der WS-Standards, die sich auf WS-Security, WS-Reliability oder WS-Atomictransaction beziehen. Allein diese Tatsache macht den SOA-Trend zu einer bemerkenswerten Erscheinung - selten waren sich die großen Hersteller so einig wie in ihrer kollektiven Vision einer Service-orientierten Welt. Zu gerne möchte man den Kunden endlich Lösungen anbieten können, die sich durch ihren Service-orientierten Aufbau eng an reale Geschäftsprozesse anlehnen und diese besser widerspiegeln als die verteilten Komponentenmodelle der Vergangenheit.

Was bei der Diskussion allerdings oft vergessen wird, sind die gravierenden Risiken, die man sich auf zahlreichen Ebenen des Software-Engineering einhandelt, wenn man allzu euphorisch und schlecht vorbereitet auf den SOA-Zug aufspringen will. Die Gefahren lauern in fast allen Disziplinen - umso wichtiger ist die intensive Beschäftigung mit dem Thema bei allen Beteiligten vom Programmierer bis hin zum Entscheider.

Entwickler erwartet eine radikal veränderte Welt

Die Welt des Entwicklers verändert sich an einer Service-Schnittstelle radikal. Vieles, was in einer lokal arbeitenden, objektorientierten Welt noch praktikabel war, ist Gift für performante Web-Service-Lösungen. Das fängt schon bei den zu übertragenden Daten an: Man bevorzugt an Service-Schnittstellen wenige, grob granulare Aufrufe mit vielen Daten vor "Chatty Interfaces" wie sie für lokale Objekte gerne verwendet werden.

Services machen regen Gebrauch von XML-Sprachen. XML wird verwendet, um festzulegen, wo ein Service zu finden ist (UDDI), um Service-Schnittstellen zu definieren (WSDL), und vor allem auch, um Daten zu transportieren (Soap). XML ist aber als Lingua franca mit all ihren Standards entgegen der landläufigen Meinung und trotz ihrer Beliebtheit alles andere als trivial. Jeder, der sich einmal genauer mit den Feinheiten von XML-Schema und XML-Namespaces oder komplexen XSLT-Skripten befasst hat, kann dies nur bestätigen. Immerhin versuchen die Hersteller aktueller WS-Entwicklungs-Tools, diese Komplexität weitestgehend zu kapseln. Ob es jedoch eine gute Idee ist, wenn die Schnittstellen-Definition eines Web-Service in XML formuliert und veröffentlicht wird, dem Entwickler aber verborgen bleibt, scheint fraglich. Erste Erfahrungen aus der Praxis zeigen: Zumindest Entwickler, die für die Server-Seite des Service verantwortlich zeichnen, werden früher oder später zu XML- und XML-Schema-Profis - ob sie wollen oder nicht.

Komplexität am Client nicht unterschätzen

Doch auch die auf den ersten Blick trivial erscheinende Client-Seite eines Web-Service hält ausreichend Komplexität parat: Serviceaufrufe erfolgen im Normalfall über mehr oder weniger zuverlässige Netzwerke mit variablen Latenzzeiten, die stark vom aktuellen Datenaufkommen abhängen. Deshalb sollte die Faustregel gelten, Web-Services möglichst asynchron aufzurufen. Dies verschafft der Client-Seite die Möglichkeit, die Zeit bis zur Antwort des Service sinnvoll zu nutzen. Das ist besonders wichtig, wenn der Service von einem User Interface aus aufgerufen wird, um die Benutzeroberfläche nicht einzufrieren, bis die Antwort des Service eintrifft.

Asynchroner Aufruf erfordert Multithreading

Implementiert man die Service-aufrufe asynchron, so bewirkt dies aber, dass typische Clients mit mehreren Aufgaben gleichzeitig umgehen können müssen - man spricht von Multithreading. Diese Nebenläufigkeit mehrerer Programmteile muss der Entwickler wiederum in seinem Code synchronisieren. Für viele Client-Entwickler stellt die solide Umsetzung von Multithreading eine neue Herausforderung dar, weil die zeitlichen Abläufe plötzlich einen entscheidenden Einfluss auf das Programmverhalten haben. Die Komplexität im Client steigt weiter an, wenn man sich über Offline-Fähigkeiten oder den Umgang mit Versionswechseln der verwendeten Services Gedanken macht.

Auswirkungen auf Beschreibung von Use Cases und Tests

Die Änderungen und erweiterten Möglichkeiten für die Implementierung servicebasierender Systeme ziehen Folgen für die Beschreibung von Use Cases und die Definition von Systemtests nach sich. Dadurch, dass anstatt sequentieller Abläufe nun asynchrone Serviceaufrufe erfolgen, entstehen für die Benutzer eines solchen Systems neue Möglichkeiten, Dinge parallel anzustoßen. Der gesamte Interaktionsfluss zwischen Benutzer und Programmoberfläche beziehungsweise zwischen zwei über Services interagierende Softwarekomponenten wird davon beeinflusst, wann welche Daten über eine Serviceschnittstelle angefordert werden. Fehlersituationen treten durch asynchrone Aufrufe eventuell erst verzögert auf und müssen gesondert behandelt werden.

Integrationstest sichert robuste Systeme

SOA-fähige Systeme sollten auch dann noch zur Verfügung stehen, wenn bestimmte Services temporär ausfallen. Die Bedeutung von Integrationstests wird folglich weiter steigen, um die geforderte Robustheit des Gesamtsystems zu gewährleisten. Hierbei wird auch deutlich, dass die Definition nichtfunktionaler Anforderungen für Service-orientierte Systeme von besonderer Bedeutung ist.

Softwarearchitekten stellen sicher die Gruppe dar, die sich bisher schon am intensivsten mit dem Thema SOA beschäftigt hat. Es gibt inzwischen einige Erkenntnisse, wie diverse technische Probleme umgangen werden können. So existiert eine Initiative namens WS-I (Web Service Interoperability), die sich um Interoperabilität der verschiedenen Technologien kümmert und entsprechende Profile und Tools veröffentlicht. Trotzdem vermisst man in einschlägigen Artikeln und Vorträgen echte praktische Erfahrungsberichte zu den architekturrelevanten Themen.

Offene Web-Services brauchen zweite Standardgeneration

Ein grundsätzliches Problem ist zum Beispiel, dass selten zwischen den verschiedenen Einsatzzwecken von Web-Services unterschieden wird. Die Benutzung von Services innerhalb einer Applikation als Remoting-Strategie unterscheidet sich in dramatischer Weise von ihrem Einsatz zur Öffnung eines Systems nach außen beziehungsweise zur Bereitstellung einer Integrationsplattform. Während Erstere - man könnte sie auch als Intra-Application-Services bezeichnen - je nach Anforderung zum Teil schon heute mit den aktuellen Entwicklungs-Tools umgesetzt werden können, scheinen Cross-System-Services auf die Verfügbarkeit der zweiten Generation der WS-Standards angewiesen zu sein.

Im Serviceumfeld wartet viel Neuland auf die Architekten, viele Fragen wurden bislang kaum beantwortet, weil noch die breite Basis an Erfahrungen fehlt (siehe Kasten "Fragen, die auf Antwort warten"). Doch egal wie die Antworten ausfallen: Web-Services sorgen tendenziell für eine stärkere Verteilung unserer Applikationen. Dies hat bisher noch nie zu einer Verringerung der Komplexität geführt - ganz im Gegenteil: Laut Martin Fowler, einem anerkannten Fachmann auf dem Gebiet verteilter Enterprise-Applikationen, ist das beste Entwurfsmuster für verteilte Applikationen, die Verteilung möglichst zu vermeiden.

SOA wird kommen - so viel steht fest. Wichtiger als der Zeitpunkt ist jedoch ein überlegtes Vorgehen, angepasst an konkrete fachliche Anforderungen, kombiniert mit einem langsamen Herantasten an die neue Technologie. Für Entscheider ist deshalb die zentrale Herausforderung, die vielen Hürden auf dem Weg zu einer erfolgreichen Service-orientierten Architektur schrittweise und im richtigen Tempo anzugehen.

Enterprise Service Bus für viele noch zu groß

Vieles lässt sich durch die adäquate Ausbildung des Entwicklungsteams abdecken, zusätzlich bedarf es jedoch jeder Menge an Erfahrung, um das theoretische Wissen in die Praxis umsetzen zu können. Um diese Erfahrung zu erlangen, ist es sinnvoll, eher klein zu starten und mit dem Gelernten zu wachsen. Der Versuch, bereits im ersten Service-getriebenen Projekt den viel zitierten "Enterprise Service Bus" umzusetzen, ist bei der gegebenen Komplexität mit größter Wahrscheinlichkeit zum Scheitern verurteilt. (ue)