Das A in SOA steht für Architektur. Nun hat der Software-Architekt gelernt, dass gute Architekturen technologieneutral sind. Abhängigkeiten zu Produkten und Tools sollten für Architekturen völlig tabu sein. Oder, wie es Thomas Müller zum Thema Käuflichkeit einer SOA formuliert: „Die IT ist Dienstleister um [Geschäftsprobleme eines Unternehmens] zu lösen, nicht um Technologie zu erstellen, für die es vielleicht mal irgendwann ein Geschäftsproblem geben wird.“ In der Tat darf bezweifelt werden, dass Infrastruktur-Produkte und Entwicklungstools über den Erfolg einer SOA Initiative entscheiden. Da die Frage nach Open oder Closed Source aber nur auf der Ebene von Produkten und Tools sinnvoll gestellt werden kann, scheint sie zunächst von nachrangiger Bedeutung. Es besteht allerdings die Gefahr, dass eine übermäßige Beschäftigung mit dem Thema SOA von der eigentlichen Aufgabenstellung ablenkt.

Hier sollen die Grundlagen einer SOA nicht wiederholt werden. Es existieren bereits gute Analysen [1]. Danach hat SOA im Wesentlichen drei verschiedene Aspekte: Komponenten, Geschäftsprozesse und Integration. Im Zentrum stehen jedoch die Services als „Bürger erster Klasse“. Ernst zu nehmende Auseinandersetzungen mit SOA stellen mittlerweile auch die Wichtigkeit des „richtigen“ Service-Zuschnitts in den Vordergrund. Der hängt nämlich stark vom fachlichen Umfeld (Domäne) ab, in der die IT wirken soll. Ohne eine grundlegende Übereinkunft über die wesentlichen Objekte, ihre Attribute und ihre Beziehungen ist das Design stabiler fachlicher Services nicht möglich – ein anerkanntes fachliches Datenmodell ist Voraussetzung.

Wer sich nun vor der nicht-trivialen Aufgabe drückt, bleibt in puncto SOA bei der Bereitstellung von Infrastruktur stecken. Es ist in der Tat zu beobachten, dass vor allem IT-getriebene SOA-Projekte einen starken Fokus auf Infrastruktur haben. Damit allein kommen die versprochen Vorteile einer SOA aber nicht zum Tragen. Hier wiederholt sich das „Spaghetti Missverständnis“ der EAI aus der vergangenen Dekade. Es reicht eben nicht, die heterogenen Punkt-zu-Punkt Verbindungen der IT-Landschaft durch einen einheitlichen Kommunikationsmechanismus zu ersetzten. Ohne guten fachlichen Schnitt und ein gemeinsames Verständnis der essenziellen Objekte und Beziehungen werden nur Services mit begrenztem Scope und kurzer Lebensdauer entstehen. Schlimmstenfalls sind die Services nur für einen Klienten in einem bestimmten Kontext nutzbar und werden im nächsten Projekt oder Release wieder ersetzt.

Trotz SOA sind die Abhängigkeiten in der Systemlandschaft nicht kleiner geworden und mithin die Flexibilität nicht größer. SOA hat sich wie eine weitere Sedimentschicht auf Ihre Systemlandschaft gelegt und sie vielleicht sogar noch ein wenig komplexer und umständlicher gemacht.

Wie fast immer bei Paradigmenwechseln in der IT muss auch bei SOA das Versprechen von besserer Wiederverwendung als Begründung herhalten. Das Kunststück für den Architekten ist also die Trennung der stabilen Bestandteile der Software von den sich ändernden. Hier ist den Services die Rolle zugedacht, durch gutes Design möglichst lange unverändert vielen Klienten in unterschiedlichen Geschäftsprozessen ein wohl definiertes Stück Arbeit abzunehmen. Dagegen wird der variable Teil, die Verknüpfung dieser Dienste zu sinnvollen Geschäftsprozessen, in eine Art „obere Verdrahtungsebene“ separiert.

Das Herauslösen der Geschäftsprozesse aus den Anwendungen ist ein ganz wesentlicher Aspekt der Restrukturierung in Richtung SOA. Hierfür ist eine unterstützende Infrastruktur in Form einer so genannten Workflow-Engine in der Regel angemessen. Hier haben sich zwei Standards zur Beschreibung der Workflows etabliert: BPEL und XPDL. Diese Engines nehmen viel Arbeit ab:

• die Verwaltung der Prozesse (anlegen, modifizieren, löschen, auffinden)
• Persistierung der Prozesse und ihrer Attribute und Status (Stichwort Wiederanlauf)
• Transaktionssteuerung
• (Basisinfrastruktur für die) Fehlerbehandlung
• Unterstützung für manuelle Arbeitsschritte

Von einer eigenen Implementierung sollte abgesehen werden, es gibt zahlreiche Produkte, auch als Open Source und lizenzkostenfrei (z. B. WfMOpen [2] ). Bei sehr kleinen und einfachen Anwendungen kann man diese Schicht auch hart kodieren. Java ist auch nicht weniger flexibel als BPEL und im laufenden Betrieb ändert erfahrungsgemäß niemand Workflows. Es wäre vermutlich aber Zeitverschwendung, die oben aufgelisteten Features einer Engine zu implementieren.

Workflows sind in ihrer Logik speziell für ein Projekt oder einen Kunden zugeschnitten. Die Substanz Ihrer Anwendungen steckt hingegen in den Services. Sie bilden die Quelle für Wiederverwendung. Pflege und Ausbau dieses „Kapitals“ einer IT-Landschaft hat höchsten Stellenwert.

Services, die einen fachlichen Zusammenhang haben, werden sinnvollerweise gruppiert. So entstehen Module oder Komponenten. Auch das ist – wie so vieles bei SOA – nichts Neues: Komplexe Aufgabenstellungen werden partitioniert. Beim Schnitt der Komponenten wird auf hohen inneren Zusammenhang (Kohäsion) geachtet und so die Abhängigkeiten zwischen den Bauteilen minimiert.

Neu ist vielleicht der Aspekt, dass Komponenten (Anwendungen sind zu grob-, einzelne Services zu kleingranular) Ihre Entwicklungseinheiten (Teams, Versionen, Deployments) bestimmen. Eine ordnende Hand – zum Beispiel ein Architektur-Board – stellt dabei sicher, dass der Nutzer der Vision eines flexibel kombinierbaren Baukastens mit Elementen, die aufeinander aufbauen und einander ergänzen, näher kommt. Hier erfordert SOA kein besonderes Tooling und keine spezielle Infrastruktur. Es wird sorgfältig angewendet, was gutes Software Engineering ausmacht. Einheitliche Infrastruktur und Entwicklungswerkzeuge fördern die Homogenität im Baukasten. Der Software-Dienstleister Danet, Arbeitgeber des Autors, setzt hier beispielsweise auf „Mainstream“ und Quasi-Standards im Java-Umfeld (eclipse, cvs, ant, JUnit, J2EE, Hibernate, etc.).

Ein wichtiger Aspekt beim Komponentenbau ist der Fokus auf die Dienste, die sie bereitstellen. Sie stehen im Mittelpunkt und geben einer Komponente erst Ihre Berechtigung. Das ist vielleicht der wesentliche Unterschied zur klassischen Anwendungsentwicklung, wo Schnittstellen oft erst im Nachhinein konzipiert wurden. Konzeption und Dokumentation der Schnittstellen von Komponenten (= Services im engeren Sinne) ist elementar. Wie aber beschreibt man Services? Eindeutig in Signatur und Semantik? Java API (javadoc) ist sprachspezifisch, IDL ist mit Corba aus der Mode gekommen. WSDL (Web Service Definition Language) ist ein pragmatischer Ansatz, wenngleich Experten zu bedenken geben, dass damit nicht alle Aspekte beschrieben werden können.

Zumindest können die Datenstrukturen als Schema (XSD) in allgegenwärtigem XML beschrieben werden. Darüber hinaus ist, gerade zur Klarstellung der Semantik, textuelle Dokumentation – zum Beispiel in Form von Wikis – viel wichtiger als formale Register. Zur Laufzeit wohnen die Komponenten in Service Containern – J2EE Application Server (z. B. JBoss) bieten dazu viel Komfort. Je nach Anwendungsfeld machen auch leichtgewichtigere Alternativen Sinn.

Theoretisch kann das Aufbrechen monolithischer Anwendungen in Komponenten dazu führen, dass die „Make-or-buy Entscheidungen“ nun auf Komponentenebene getroffen werden. So verkündet SAP beispielsweise auf einer letztjährigen JAX Keynote das „versöhnliche Nebeneinander von SAP und Eigenbau dank SOA“. Man darf gespannt sein, wie das in der Praxis aussieht.

Komplexe Landschaften, zerlegt in Komponenten und Geschäftsprozesse, erfordern wiederum Integration der Bauelemente und die Kommunikation zwischen ihnen. Das ist so gesehen die Kehrseite der Modularisierung und erhöht die Komplexität des Gesamtsystems. Je loser die Kopplung, desto komplizierter gestaltet sich das Zusammenwirken, spätestens dann, wenn nicht nur der Gutfall Betrachtung findet. EAI Lösungen in Form von „Integration Backbones“ mildern das Problem, sollten aber kein Selbstzweck einer SOA Initiative sein. Insbesondere ist es wünschenswert, die Abhängigkeiten Ihrer Services und Komponenten von der Middleware zu minimieren. Dazu gibt es im Wesentlichen zwei Ansätze, so genannte „Invocation Frameworks“ (z. B. WSIF [3] ) und Generatoren, die den Kleber zwischen fachlicher Logik und technischem Kommunikationsmechanismus automatisch erzeugen.

Ein mittlerweile aufgeklärtes Missverständnis ist, dass SOA WebServices, also SOAP über HTTP, erfordere. Das ist nicht so. WebServices ist für Kommunikation über Unternehmensgrenzen hinweg (B2B) meistens die richtige Wahl, innerhalb von Unternehmen in der Regel nicht. Die Firma Danet verwendet dazu drei verschiedene Lösungsmuster: RMI/IIOP für enge Kopplungen zwischen Java Komponenten, XML über JMS für asynchrone, lose Kopplungen und WebServices für externe (B2B) Interfaces. Dabei wurde die Erfahrung gemacht, dass verfügbare Open-Source-Infrastruktur (z. B. Axis, ActiveAQ, JBoss Messaging, Xerces) sehr gut anwendbar ist. Eigenentwicklungen auf dieser Ebene sind für Dienstleister und Lösungshersteller normalerweise nicht sinnvoll. Auf der anderen Seite sind Abhängigkeiten von kommerziellen SOA und EAI Produkten eher hinderlich. In der Praxis wählen große Kunden Integrationsplattformen selbst aus und lassen Dienstleistern kaum Freiraum, während kleinere Kunden die Lizenzkosten kommerzieller Middleware nicht tragen können.

Die Analyse einer Domäne und ihre Zerlegung in fachliche Services und Komponenten ist keine einfache Aufgabe. Sie ist aber der Schlüssel für Wiederverwendung und darum geht es im Kern bei SOA. Wer Flexibilität und Wiederverwendung will, sollte sich aber nicht von „Fluchtzielen“ ablenken lassen, die die SOA Tool-Industrie allzu gerne anbietet.

Für bestimmte Projekte mögen ausgefuchste Repositories nötig sein, um hunderte von verschiedenen Artefakten einer SOA Landschaft zu verwalten und vielleicht brauchen manche Unternehmen den 8-spurigen SOA Integration Highway quer durch das Unternehmen. Für die meisten Architekten wird es aber vermutlich zunächst Wichtigeres geben.