SOA richtig verstehen und verwenden

Bisherige IT-Landschaften sind von verschiedenen Anwendungen geprägt, die viel Wissen über einen speziellen Bereich des Unternehmens enthalten. Selbst wenn diese Anwendungen sauber aufgebaut sein sollten, ist es meistens schwierig, Teile der Anwendungen für andere Zwecke einzusetzen. Das liegt daran, dass kaum ein Projekt ohne massiven Druck von außen wiederverwendbare Komponenten für andere Projekte entwickeln wird. Die Entwicklung solcher Komponenten ist aufwendig und schwer planbar. Solche Komponenten sind daher nicht im Interesse eines Teams, sein Projekt zeitgerecht fertig zu stellen. Im Gegenteil: Nicht selten entwerfen die Entwicklungsteams einzelne Teile ihrer Anwendungen so, dass eine Wiederverwendung sogar innerhalb der eigenen Anwendung schwierig ist. Die Folge dieser Fehlentwicklung: Es entstehen Anwendungslandschaften mit vielen Redundanzen. Die Wartung ist solcher Anwendungen ist aufwendig, Änderungen und Neuentwicklungen oftmals sehr ineffizient.

Ende des Burgendenkens

Serviceorientierte Architekturen sind angetreten, dieses "Burgendenken" zu beenden. Eine serviceorientierte Architektur legt hierzu die verborgenen Funktionen innerhalb der Anwendungen bloß und versucht, sie für alle Anwendungen zu öffnen. Das wichtigste Rezept hierzu ist eigentlich sehr einfach und altbekannt: Die Anwendungen werden in wiederverwendbare Services aufgeteilt, zu denen öffentliche Schnittstellen existieren.

Ein Beispiel hierzu: Es besteht die Anforderung an mehrere Anwendungen eines Unternehmens, tabellarische Ansichten in PDF-Dokumente umzuwandeln. Die verschiedenen Anwendungen haben das bisher so gelöst, dass sie einen speziellen Dokumentgenerator innerhalb einer Anwendung implementiert haben. Jedes Team hat hierbei immer wieder die gleiche Probleme lösen müssen. Die historisch gewachsenen Strukturen werden beim Wechsel zu einer serviceorientierten Architektur aufgebrochen: Hier tritt an die Stelle der verschiedenen internen Dokumentgeneratoren ein singulärer Service, der für alle Anwendungen Dokumente an einer zentralen Stelle zeugen kann (siehe Bild).

Die speziellen Dokumentgeneratoren der verschiedenen Anwendungen waren maßgeschneidert auf die Anwendungsfälle und Dokumentvorlagen, die die Anwendungen benötigten. Mit der Implementierung eines zentralen Services ist der Anspruch an diesen generischen Dokumentgenerator sehr viel höher. Durch die höhere Last im Vergleich zur Einzelanwendung muss er über eine sehr robuste Implementierung verfügen. Dadurch, dass die Last viel höher ist, muss er zudem skalierbar sein. Der Service muss außerdem alle Anwendungsfälle der verschiedenen Clients abdecken, damit er seine Aufgabe erfüllen kann. Durch die Vielzahl der Anforderungen ist das Design einer öffentlichen Schnittstelle schwieriger als bei einer speziellen Implementierung für nur eine Anwendung.

Vorteile: Zentrale Verantwortung

Was sind die Vorteile eines solchen Services? Das Wissen über die Dokumentgenerierung liegt bei einem Team, das den Service verwaltet, und ist nicht mehr verstreut in diversen Anwendungsteams. Es gibt eine zentrale Stelle, die gewartet und verbessert werden muss. Es ist viel lohnender, den Service hochverfügbar auszulegen, so dass viele Verbraucher gleichzeitig darauf zugreifen können. Würde das eine der Anwendungen selbst übernehmen, müsste sie sich mit einer Infrastruktur beschäftigen, die abseits des Tagesgeschäfts liegt. Und nicht zuletzt gibt es strategische Pluspunkte: Dem Servicekonsumenten ist vollkommen egal, welche Implementierung mit welchem Framework sich hinter dem Service verbirgt. Er hat eine generische Schnittstelle, die für ihn das Maß der Dinge ist. Ein gutes Servicedesign erlaubt es der IT, Datenbankschemata, DBMS und Frameworks einfach hinter einer Fassade auszutauschen, wenn das aus strategischen und Kostengesichtspunkten angesagt ist.

Nachteile: Der Startaufwand

Was sind die Nachteile eines solchen Services? Der größte Nachteil ist, dass es zunächst länger dauern wird, einen Service zu etablieren. Dafür gibt es mehrere Gründe, zum Beispiel die Abstimmung der Anforderungen. Auch das Servicedesign ist anspruchsvoller als die spezielle Schnittstelle innerhalb einer Anwendung. Ein weiteres Problem ist die Verfügbarkeit der Services. Jede Anwendung möchte dem Endanwender natürlich mindestens die Verfügbarkeit der Servicefunktion garantieren, über den die gesamten Anwendung verfügt. Die Praxis zeigt, dass sich die Anforderungen verschiedener Anwendungen eines großen Unternehmens selten unter einem Hut bringen lassen. Zum Beispiel ist eine häufige Anforderung an Services, dass diese generell hochverfügbar sind, obwohl sich das aus Kostengründen natürlich ausschließt."

SOA ist aktueller denn je, weil einfacher umsetzbar

Die ganze Diskussion über SOA ist natürlich überhaupt nichts Neues. Verteilte Anwendungen auf Servicebasis sind so alt wie das Internet. So wurde bereits zu Zeiten von CORBA über die gleichen Services und ihre Verfügbarkeit diskutiert, über die wir jetzt im Rahmen einer SOA-Architektur reden. Wo ist der Unterschied? Der Unterschied ist, dass es deutlich einfacher geworden ist, solche "Servicelandschaften" aufzubauen, da mittlerweile leistungsfähigere Bausteine und Werkzeuge zum Aufbau einer serviceorientierten Architektur zur Verfügung stehen: moderne Services, Client-Anwendungen, Serviceverträge, Enterprise Service Bus, BPM, Mediation, Governance, Entwicklungsumgebungen sowie Frameworks und Konnektoren.

Die Bestandteile einer SOA im Überblick

Die SOA-Bausteine: Moderne Services

Moderne Services sind das zentrale Element einer serviceorientierten Architektur. Sie können zum Beispiel als SOAP- oder Rest-Web-Services mit der Unterstützung diverser Entwicklungsumgebungen und Frameworks vergleichsweise einfach implementiert werden. Einige SOA-Suiten lassen zu, Services grafisch zu implementieren (siehe etwa Screenshot "Flowservices" auf der vorherigen Seite) Dies erleichtert Entwicklern den Einstieg, die nicht über viel Erfahrung mit C# oder Java verfügen. Solche Services bieten einzelne Dienstleistungen wie die eingangs erwähnte Dokumentgenerierung an. Anwendungen, die solche Dienstleistungen offerieren, bezeichnet man als Service-Provider oder Serviceanbieter. Serviceanbieter müssen nicht ausschließlich aus dem eigenen Unternehmen kommen. Es gibt eine Vielzahl externe Webservices wie zum Beispiel Wetterservices, Landkartenservices, Services für die Währungsumrechnung und zum Anzeigen von Börsenkursen.

Die SOA-Bausteine: Client-Anwendungen

Client-Anwendungen verwenden die zuvor genannten Services und werden daher Service Consumer oder Servicekonsumenten genannt. In der Regel erhalten sie von Services Daten zu einer Anfrage, um sie zu visualisieren. Ein anderer Anwendungsfall ist, wie im Fall des eingangs genannten PDF-Services, die Daten in ein anderes Format transformieren zu lassen. Um sich mit Services zu verbinden, muss eine Client-Anwendung einen Service "entdecken". Zur Entdeckung gehört zu wissen, dass der Service existiert, wie seine Schnittstelle beschaffen ist und welche Anforderungen sie erfüllt. Dazu bietet der Serviceanbieter potentiellen Konsumenten Dienstleistungen über eine Service Registry an, in denen die Schnittstellenbeschreibungen der Services veröffentlicht sind (siehe etwa Bild unten).

Die Service Registry verändert die Kommunikation des Unternehmens erheblich, denn diese Schnittstellenbeschreibungen können direkt über die Oberfläche einer Registry erforscht werden. Noch effizienter ist es, Services und deren Beschreibungen gleich über die Entwicklungsumgebung zu finden. Der Entwickler ist mit aussagekräftigen Beschreibungen des Services sofort in der Lage, entsprechenden Quellcode für die Integration des Services mit Hilfe eines Adapters zu erzeugen. Möglich wird dieses Verfahren über einen normierten und daher sehr genau definierten Servicevertrag (Service Contract).

Die SOA-Bausteine: Serviceverträge

Der Servicevertrag besteht üblicherweise aus einem fachlichen und technischen Teil. Der fachliche Teil beschreibt den Service in natürlicher Sprache und definiert hierbei die verschiedenen Adressen, unter denen der Service erreichbar ist. Der fachliche Teil des Vertrags sollte zudem festlegen, welche nichtfunktionalen Anforderungen der Service erfüllt, zum Beispiel wie die Verfügbarkeit des Services und die Antwortzeiten ausgelegt sind.

Der technische Teil des Services ist im Fall eines SOAP-Services (Simple Object Access Protocol) eine WSDL-Datei. Die Web Service Definition Language (WSDL) ist eine speziellen Sprache zur Beschreibung der Schnittstelle eines Webservices auf Basis der XML. Eine WSDL enthält sechs XML-Hauptelemente: Datentypen, Nachrichten, Schnittstellen, Datenbindung und Services mit ihren Endpunkten. Nachrichten definieren, wie Anfragen gestellt und Antworten erhalten werden. Hierbei werden Transportobjekte ausgetauscht, deren Datentypen und Datenstrukturen in der WSDL in Form von XML exakt beschrieben werden. Um die Datenstrukturen zu definieren, verwendet man hierzu eine oder mehrere XSD-Dateien.

Die SOA-Bausteine: Enterprise Service Bus

Aus dem Integration-Server der Enterprise Application Integration (EAI) hat sich das Konzept des Enterprise Service Busses entwickelt. Der Enterprise Service Bus ist hierbei zumeist nicht ein einzelnes SOA-Produkt, sondern eine Infrastruktur, die aus mehreren Produkten besteht. Die Idee hinter diesem Message Bus ist, Serviceanbieter und Servicekonsumenten analog einer EAI-Architektur zu trennen, um eine lose Kopplung zu erreichen (siehe Bild). DerESB transportiert die Nachrichten der Servicekonsumenten selbstständig zu den Stellen, wo sie durch Serviceanbieter weiterverarbeitet werden.

Die SOA-Bausteine: Mediation

Die Trennung zwischen Serviceanbieter und -konsumenten lässt sich durch ein Servicemediator noch weiter unterstützen. Der Mediator stellt hierbei den Servicekonsumenten nicht den physischen Originalservice zur Verfügung, sondern lediglich einen Stellvertreter, den man meist als virtuellen Service bezeichnet. Der virtuelle Service wird vom Originalservice abgeleitet. Ausschließlich dessen Endpunkte werden bei einer Mediation in der SOA-Registry publiziert. Wird der ESB mit einem Mediator konfiguriert, fängt dieser die gesamte Kommunikation zwischen Serviceanbieter und den Clients ab. Er kann Requests hierbei überwachen, filtern, transformieren und routen. So kann kontrolliert werden, ob zugesicherten SLAs des Servicevertrags eingehalten werden. Außerdem ist der Mediator in der Lage, ein Load Balancing durchzuführen. Er kann dabei Anfragen vollkommen unsichtbar für den Servicekonsumenten je nach Last einfach an verschiedene Instanzen eines Services weiterrouten.

Die SOA-Bausteine: Business Prozess Engine

Geschäftsprozesse sind der Kern von fachlichen Services. Sie lassen sich entweder mit Hilfe einer Programmiersprache wie zum Beispiel C# oder Java umsetzen. Eine Alternative zur festen »Verdrahtung« in einer klassischen Programmierungsprache ist es, sie mit WS-BPEL zu implementieren (Bild 4: BPEL). WS-BPEL ist die sogenannte "Web Service Business Process Execution Language". Wie der Name bereits sagt, geht es nicht nur um die Modellierung eines Geschäftsprozesse, sondern auch darum, dass sich diese Diagramme auch direkt ausführen lassen. Dazu benötigt man als Laufzeitumgebung eine Business Process Engine.

BPEL-Diagramme verbinden die Vorzüge der Modellierung mit denen der klassischen Programmierung: Die Prozesse können sehr leicht mit dem Fachbereich abgestimmt werden, da sie nicht in einer technischen Programmiersprache verfasst wurden. Im Gegensatz zu UML-Aktivitätsdiagrammen müssen sie nach Modellierung nicht erst von Grund auf neu programmiert werden. Ein weiterer Vorteil der BPEL-Diagramme ist ihre Flexibilität. Ändert sich die äußere Schnittstelle des Geschäftsprozesses nicht, können interne Details zur Laufzeit geändert werden. Dies geschieht vollkommen transparent für den Servicekonsumenten.

Die SOA-Bausteine: Entwicklungsumgebung

Um in einer SOA-Umgebung komfortabel entwickeln zu können, verfügen SOA-Suiten normalerweise über eine integrierte Entwicklungsumgebung (IDE). Sie versetzt den Entwickler in die Lage, auf alle Bausteine einer SOA-Suite zuzugreifen. Das bedeutet, er kann damit Service entwickeln, testen, verteilen und in der Service-Registry als virtuelle Services publizieren. Er ist damit in der Lage, Geschäftsprozesse zu modellieren, zu implementieren, zu testen und zu verteilen. Eclipse-basierte Umgebungen wie die von Mule und webMethods verfügen über eine Vielzahl spezieller Views und diverser Perspektiven. Die Entwicklungsumgebungen sind eng mit SOA-Frameworks verzahnt, mit denen zum Beispiel Client-Adapter erzeugt werden können.

Frameworks und Konnektoren

Eine SOA-Suite wird durch Frameworks und Konnektoren abgerundet. Spezielle Frameworks helfen, entsprechende Service-Adapter zu generieren oder Web-Anwendungen zu entwickeln. Jede SOA-Suite enthält mehr oder weniger viele Konnektoren für Anwendungen wie PeopleSoft, Salesforce, SAP oder Siebel. Ein weiterer wichtiger Bestandteil der SOA-Architektur sind Konnektoren für den Zugriff auf Host-Programme und zur Modernisierung von 3270-Masken.

SOA verspricht mehr Produktivität in der Softwareentwicklung

Das Konzept der serviceorientierten Architektur ist angetreten, Funktionen von Anwendungen als Service öffentlich zur Verfügung zu stellen. Services können über ein Service-Repository gefunden werden und sind über einen Enterprise Service Bus erreichbar. Sie verfügen über einen genau definierten Servicevertrag. Wird eine serviceorientierte Architektur bestimmungsgemäß eingesetzt, kann sie dazu beitragen, die Wiederverwendung von Services und die Produktivität der Softwareentwicklung zu verbessern.