Bauplan für moderne Software-Architekten

Thomas Erl, Gründer von SOA Systems, ist anerkannter Experte für SOA und Bestsellerautor zahlreicher Fachbücher zum Thema. Auf dem SOA-Forum hält er die Keynote und leitet einen Workshop

Der Wichtigkeit von Software-Services kann derzeit kein IT-Profi entkommen. Moderne Konzepte wie Cloud Computing, Servicevirtualisierung, Web-2.0-Mashups oder Dienstleistungs-Grids stellen die Software-Services auf eine neue Stufe. Um aber aus jedem Programm, das als Services verteilt werden soll, das Optimum herauszukitzeln, ist es zuallererst einmal wichtig zu verstehen, was eine Applikation überhaupt erst «serviceorientiert» macht.

Ein Service ist im Grunde eine Software mit ganz bestimmten Charakteristiken. Um diese Charakteristiken dauerhaft einzubauen, werden die Programme als Dienste modelliert. Diese Dienste können - zur Erfüllung jeweils neuer Business-Aufgaben - untereinander zusammenarbeiten und auf verschiedene Arten miteinander kombiniert werden. Ziel ist als «Idealzustand» eine serviceorientierte Unternehmens-IT, die sich durch folgende Eigenschaften auszeichnet:
- Inhärente Interoperabilität,
- Rechnen im Verbund,
- Diversifikation der Hersteller,
- schnelles ROI (Return on Investment),
- organisatorische Beweglichkeit
- und eine deutliche Entlastung der IT.
Unter Serviceorientierung ist also die Methode zu verstehen, mit der sich verteilte Applikationen und Lösungen schreiben lassen, die zu diesem Idealzustand führen. Mehr dazu auf der englischen Webseite www.whatissoa.com.

Am besten, Sie stellen sich die Serviceorientierung als Designparadigma oder Designphilosophie vor. Das Modell basiert auf einer Reihe von Designprinzipien, die auf jede als Dienst entwickelte Software angewendet wird. Diese acht Prinzipien sind: ein standardisierter Servicevertrag (Standardized Service Contract), lose Verbindungen unter den Diensten (Service Loose Coupling), deren Abstraktion (Service Abstraction), Wiederverwendbarkeit (Service Reusability), Autonomie (Service Autonomy), Zustandslosigkeit (Service Statelessness), Auffindbarkeit (Service Discoverability) und Verknüpfbarkeit (Service Composability). Eine detaillierte Definition dieser Begriffe finden Sie auf www.soaglossary.com.

Einer der grössten Vorteile, wenn man Dienste auf diese Art entwirft, besteht darin, dass sie auf natürliche Weise kompatibel werden. Dadurch lassen sie sich zu kreativen Kombinationen (Service Compositions) zusammensetzen und zwar ohne, dass auf traditionelle Integrationstechniken zurückgegriffen werden muss wie beispielsweise Data Model Transformation und Protocol Bridging. Weitere Informationen zu den SOA-Prinzipien finden Sie auf www.soaprinciples.com.

Was hat dies nun alles mit dem so oft verwendeten Akronym SOA zu tun? Bislang habe ich diese Abkürzung vermieden, weil sie im Grunde genommen zurzeit zwei Bedeutungen besitzt. Einerseits wird SOA von Herstellern und IT-Medien als eine Art Markenzeichen für alles gebraucht, was irgendwie mit Services zu tun hat. Weil der Begriff so oft verwendet wird, sorgt er für zahlreiche Missverständnisse. Wer allerdings serviceorientierte Lösungen erstellen muss, sollte schon eine genaue Vorstellung davon haben, was das ist. Das bringt uns zur zweiten und wesentlich wichtigeren Bedeutung von SOA: Eine serviceorientierte Architektur ist ganz einfach eine Technikarchitektur, die Service-orientierung unterstützt. Die Architektur ist dann serviceorientiert, wenn sie bestimmte Charakteristiken aufweist. Diese vier gemeinsamen Merkmale einer SOA sind:
- Sie wird vom Business getrieben,
- ist herstellerneutral,
- auf das Unternehmen fokussiert
- und rückt die Komposition der Services ins Zentrum.
Diese Eigenschaften beeinflussen das Architekturmodell, das für die Planung und den Bau eines serviceorientierten Ökosystems sowie für die unterstützende Technikarchitektur und -infrastruktur verwendet wird.

Worin bestehen nun die grössten Herausforderungen bei der Einführung einer SOA-Lösung? Eine typische IT-Organisation muss viele Hindernisse überwinden, um die Serviceorientierung erfolgreich einzuführen. So kann es schwierig werden, die gleichen Prinzipien einheitlich auf alle Services anzuwenden, wenn sie von verschiedenen Projektteams stammen. Die Serviceorientierung macht daher auch eine Kehrtwende in der Arbeitsweise erforderlich, weg vom gewohnten, auf einen einzigen Verwendungszweck ausgerichteten (Silo based) Programmierprojekt.

Doch es gibt Hilfestellung bei der Bezwingung dieser Herausforderungen. So wurde unlängst ein Katalog von Designvorlagen (patterns) veröffentlicht. Jede dieser Vorlagen enthält eine bewährte Designlösung und -methode. Diese Designpatterns helfen schlussendlich dabei, Serviceorientierung bei der Software-Entwicklung einzuführen. Mehr dazu auf www.soapatterns.org.

Eines der Designpatterns nennt sich Domain Inventory. Viele Organisationen nehmen an, dass die einzige Möglichkeit, sich der Service-orientierung zu verschreiben, darin besteht, das Prinzip auf die gesamte Unternehmens-IT anzuwenden. Dies ist ein zwar ambitiöses, aber oft auch unrealistisches Ziel, das zu sehr viel Frustration führen kann. Das gilt besonders dann, wenn einzelne Mitglieder einer IT-Abteilung die Prinzipien nicht unterstützen.

Eine Alternative zu dieser unternehmensweiten Adaption besteht darin, mehrere Gruppen von Services zu etablieren, sogenannte Serviceverzeichnisse (Service Inventories). Es handelt sich dabei im Grunde um eine Sammlung von Diensten, die unabhängig von anderen Sammlungen standardisiert, verwaltet und geregelt sind. Jedes Service Inventory kann mit seinen eigenen Designstandards gebaut und erweitert werden. Ziel ist es, eine Sammlung von Services zu erstellen, die mehrere sinnvolle Verwendungszwecke haben, aber dennoch vom Umfang her noch verwaltbar bleiben. Existiert mehr als ein solches Service Inventory, dann spricht man von Domain Service Inventories, weil sie ein ganzes Segment (domain) des Unternehmens abdecken. Domain Service Inventories sind ein sehr erfolgreiches Konzept. Sie haben auch das Vorurteil ausgeräumt, dass SOA-Projekte immer gross angelegt sein müssen. Das hat vielen IT-Organisationen dabei geholfen, die Serviceorientierung zu adaptie-ren - ohne grosse Vorinvestitionen. Es gibt aber noch zahlreiche weitere Designpattern, die helfen können. Wichtig ist, dass man letztendlich den Sinn hinter dem serviceorientierten Computing im Auge behält, egal, ob man sich an konkreten Designpattern oder an den -prinzipien orientiert. Dieser Sinn liegt in der Verwirklichung des oben erwähnten «Idealzustands». So lässt sich auch besser verstehen, warum Serviceorientierung einzigartig ist und warum es von uns verlangt, die Erstellung von verteilten Applikationen in einer bestimmten Art und Weise anzugehen.