Netcetera
Service-oriented Architecture (SOA) geistert als Begriff durch die ICT-Branche. Dass damit meist ein pragmatischer Ansatz zur Vereinfachung von IT-Konzepten gemeint ist, wird oft verkannt. Gerade bei komplexen Systemen in der Finanz-IT ist SOA eine Prüfung wert.
Vielleicht ist es Ihnen auch bereits aufgefallen: Beim Aufstarten des Acrobat Reader wird aufgelistet, welche Komponenten geladen werden, unter anderem «SOAP».
SOAP oder Simple Object Access Protocol wird zu Recht häufig in einem Atemzug mit Webservices genannt: Es dient als Transportmechanismus für den Austausch von Daten zwischen dem Benutzer eines Webservice und dessen Anbieter. Applikationen wie der Acrobat Reader unterstützen den Aufruf von Webservices zum Beispiel im Zusammenhang mit Formularen und ermöglichen so die Anzeige von aktuellen Daten wie etwa einer Preisliste. Oder einfach gesagt: Webservices liefern Daten, wie wir sie von Webseiten her kennen, in maschinenlesbarer (also standardisierter) Form. Auf diese Weise können Funktionen eines Webangebots (das auf die Interaktion mit dem Menschen ausgelegt ist) auch in Applikationen benutzt werden. Aus technischer Sicht liegt das nahe beim Remote Procedure Call – also dem Ausführen von Funktionen, die nicht lokal verfügbar sind. Die Erweiterung dieser Überlegung zur Service-oriented Architecture (SOA) liegt auf der Hand. Dort werden einzelne unabhängige Dienste im Netzwerk so zur Verfügung gestellt, dass diese von anderen Applikationen einfach gefunden und benutzt werden können. Dabei sind Webservices eine sinnvolle, aber nicht die einzige mögliche Implementation einer solchen Architektur. Dieser Artikel gibt einen Überblick über die Kernkomponenten einer serviceorientierten Architektur und zeigt auf, worauf bei der Umsetzung speziell zu achten ist.
Das System als Zusammenspiel von Komponenten
Informatiksysteme unterstützen den Produktionsprozess mit dem Ziel, die Abwicklung zu optimieren. Das gilt für die Herstellung von Autos ebenso wie für die von Hypotheken. Im dynamischen Markt verändern sich die Anforderungen laufend – sei es, weil neue Produkte entwickelt, produziert und vertrieben werden sollen, oder sei es, weil effizientere Produktionsmethoden zur Anwendung kommen.
Die unterstützenden Informationssysteme passen sich diesen neuen Anforderungen fortwährend an. Zusätzlich sorgt eine zweite Triebkraft für Veränderungen in der Informatik: Die Entwicklung der Technologie selbst. Die Folge ist, dass Informationssysteme sich zu wahren babylonischen Türmen auswachsen, deren Kontrolle oder Veränderung anspruchsvoller und aufwendiger werden. Hier folgt SOA ganz dem Ansatz von «separation of concerns»: Das komplexe System wird in einzelne Komponenten aufgebrochen. Diese Teilsysteme sind dann für sich wieder überschaubar und kontrollierbar. Und ganz im Sinne der objektorientierten Programmierung (OO) sollen diese Komponenten gegen aussen wohl definierte und dokumentierte Schnittstellen anbieten, die komplett von der eigentlichen Implementation entkoppelt sind.
Dieser Ansatz funktioniert selbstverständlich auch als Leitbild, wenn eine Architektur neu konzipiert wird. Spannend wird er aber besonders bei der Neugestaltung von bestehenden Systemen. Bei der häufigsten Vorgehensweise werden Fassaden vor bestehende Systeme gestellt, diese Fassaden bieten gegen aussen die von SOA verlangte Schnittstelle. Hilfreich ist dabei, dass Webservices technologieneutral definiert werden: Sie können verschiedene Betriebssysteme und Programmiersprachen miteinander verbinden, was die erwünschte bessere Integration einzelner Systeme fördert
Analogie zwischen SOA und OO
Ist die Zwischenschicht an Fassaden erst einmal etabliert, lassen sich einzelne Komponenten gezielt und problemlos auswechseln, da ihre Benutzung gleich bleibt. Das schafft Handlungsfreiheit: Anstelle des gesamten Produktionssystems können nun gezielt diejenigen Komponenten bearbeitet werden, deren Erneuerung den besten Nutzen verspricht.
Hinzu kommt die Wiederverwendbarkeit dieser Komponenten. Als Beispiel kann der Prämienrechner nicht mehr nur für die Offertenstellung im Back-Office verwendet werden, sondern er steht auch für andere Abteilungen wie das Marketing oder den E-Kanal zur Verfügung. Damit werden redundante Systeme vermieden und Daten konsistent bereitgestellt. Der Kunde erhält die gleiche Offerte, unabhängig davon, wo sie erstellt wurde. Schliesslich können die einzelnen Services zentral verwaltet werden, zum Beispiel in Bezug auf die Verfügbarkeit, aber auch in Bezug auf die Zugriffskontrolle.
Deshalb wird oft eine Analogie zwischen SOA und Objektorientierung (OO) gesehen: OO hat die systematische und kontrollierte Modularisierung des Sourcecodes ermöglicht, SOA leistet das Gleiche für ganze Produktionssysteme. Entsprechend hoch sind die Erwartungen an SOA. Beliebte Schlagworte im SOA-Umfeld sind: Reduzierte Timeto- Market, geringere Produktions-, Betriebsund Wartungskosten bei geringerem betrieblichem Risiko, erhöhte Agilität und – in der Tat sehr wichtig – die Wiederverwendung der Funktionalität über alle Kanäle hinweg.
«Aber das ist ja nichts Neues», werden nun sicher viele denken. Bekannte Ansätze bieten viele der Möglichkeiten von SOA ebenfalls. Ausserdem lassen sich auch die Ideen der Objektorientierung mit einer prozeduralen Programmiersprache umsetzen – Analoges gilt auch für SOA. Trotzdem lassen sich zwei wichtige Merkmale identifizieren, die SOA gegenüber anderen Ansätzen auszeichnen: Erstens vereinfacht die Wahl des gut etablierten Kommunikationskanals über HTTP die Verbindung einzelner Systeme über verschiedene Grenzen hinweg. Und zweitens werden die einzelnen Komponenten explizit nur lose gekoppelt (obschon der Vertrag zwischen den Komponenten mithilfe der Web Service Definition Language – WSDL – scharf definiert wird). Dies kommt in der Unabhängigkeit von Programmiersprache und Betriebssystem zum Ausdruck und zeigt die lose Kopplung auch dadurch, dass auf der Client-Seite kein Code benötigt wird, der von der Service Implementation abhängig ist.
Die letzten Hürden für das SOA-Konzept
Wie bereits angedeutet, machen diese Erwartungen auf der technischen Seite eine Reihe von Komponenten und Prozessen notwendig:
- Der Service muss in maschinenlesbarer Form beschrieben werden (WSDL)
Ein zentrales Element von SOA ist die Idee, dass Funktionen – oder schärfer: Geschäftsregeln – aus den einzelnen Applikationen, in denen sie heute oft zu finden sind, herausgerissen und einzeln angeboten werden sollen, sodass sie möglichst oft wiederverwendet werden können. Von verschiedenen Applikationen und in verschiedenen Kanälen (Web, Interactive Voice, Callcenter und Back-Office etc.).
- Webservices müssen angeboten werden
Dies ist eine Aufgabe, die die Applikationsserver gerne übernommen haben. Alle führenden Anbieter von Applikationsservern unterstützen heute Webservices und den dazugehörigen Transport-Layer SOAP. Dass die Wahl auf Webservices und nicht etwa auf andere Service-Architekturen gefallen ist, hat mit der Verbreitung des Internets zu tun: In aller Regel sind Verbindungen via HTTP über alle Firewalls hinweg zugelassen, was die Interoperabilität fördert.
- Jemand muss Webservice-Anbieter und Benutzer zusammenbringen
Hierzu dient ein zentraler Dienst (UDDI), der die angebotenen Funktionen etwa einer Firma kennt und Benutzer so zum entsprechenden Webservice führen kann.
Unterwegs in Richtung Semantic Web
Alle diese Voraussetzungen sind heute geschaffen – Systeme können gemäss der SOA geplant und gebaut werden. Wird Serviceoriented Architecture nun den Segen bringen, den man sich davon erhofft? Die Zeichen stehen gut. Das beschriebene Problem von komplexen und verschachtelten Informatiksystemen existiert heute in der Tat. Zum Wiedererlangen der Handlungsfreiheit bietet sich hier der schrittweise Übergang in eine Komponenten Architektur an. In den SOA-Projekten haben wir gelernt, dass die Rolle des Service-Managers ein Schlüssel zum Erfolg ist. Seine Aufgabe ist es, die Services optimal auf die Bedürfnisse abzustimmen, ihre Granularität festzulegen und Duplizität zu vermeiden. Das Lifecycle Management und die Versionierung der Services gehören ebenfalls zu seinen Aufgaben. Ohne die Kontrolle dieses «Bibliothekars» besteht die Gefahr, dass sich das SOA-Projekt im Gestrüpp von ähnlichen oder unvollständigen Services verfängt. SOA und Webservices sind wichtige konzeptionelle Neuerungen für Informationssysteme. Bereits heute bieten Firmen wie Google ihre Dienstleistung auch als Webservice an. Für Anbieter von Preisvergleichen drängt es sich auf, ihre Daten via Webservices direkt mit den Herstellern abzugleichen. Durch die Kombinierbarkeit können solche Services zu immer neuen Produkten zusammengestellt werden und damit die gewünschte Agilität unterstützen. Wie das erwähnte Beispiel zeigt, ist es heute fast schon selbstverständlich, dass bei der Suche nach einem Produkt auch die Preise der Lieferanten angezeigt werden. Damit wird das Semantic Web noch ein Stück konkreter.