© sumnersgraphicsinc, Fotolia.com

Der Wechsel von klassischen monolithischen IT-Landschaften hin zu einer flexiblen, dezentral aufgebauten Service-orientierten Architektur (SOA) macht häufig den Weg frei für Open Source.

Irgendwie hat es nicht so ganz geklappt mit dem Marketing. Obwohl fast alle IT-Anbieter dem SOA-Trend der letzten Jahre folgten und ihre Produkte offensiv bewarben, scheitern die Ideen der Service-Orientierung in den meisten Unternehmen schon an der Pforte.

Viele Admins verbinden heute mit dem Schlagwort und den vielen kryptischen Abkürzungen nur Produktstrategien diverser Hersteller und die Notwendigkeit, sich für die eine oder andere Workflow-Engine zu entscheiden. SOA haftet die Aura einer Marketingblase an und viele Admins drehen sich weg, genervt vom Klingeln der Verkäufer, wenn sie nur den Begriff hören.

Service-Orientierung

Dabei hat das Konzept eine Menge zu bieten, gerade mit Open-Source-Software.Eine SOA versteht Anwendungen als Anbieter von Services, ein Dienst bildet dabei einen mehr oder weniger umfangreichen Arbeitsschritt oder Teilablauf eines Geschäftsprozesses ab, der sich über eine offene Schnittstelle plattformübergreifend aufrufen lässt (Abbildung 1).

Abbildung 1: In der Idealform einer SOA modelliert das Management die Businessprozesse in Software, die die entsprechenden Dienste in einer Orchestration-Engine organisiert. Offene Standards wie Web Service Description Language spezifizieren die Services, Abläufe und Prozesse, aus denen sich der Input und Output für die Benutzer ergibt.

Das bedeutet aber, die meist monolithischen Anwendungen in heutigen Unternehmen, die von der Benutzeroberfläche bis zur Datenhaltung alles selbst erledigen, zu öffnen und sie nach und nach in einzelne Services zu zerlegen. Als Lohn der Mühe stehen im Idealfall am Ende dieser Transformation flexibel kombinierbare Services, die einzelne Ablaufschritte implementieren.

In der Realität erweist sich die Einführung einer Service-orientierten Architektur folglich weniger als Produktentscheidung, sondern als Paradigmenwechsel für das IT-Management, bei dem auch freie Software ins Spiel kommt. Eine SOA auf Basis von Open-Source-Komponenten ist fast immer eine kostengünstige Alternative, zunehmend auch für mittelständische Unternehmen. Es zählt die Möglichkeit des behutsamen, schrittweisen Aufbaus, aber auch, dass sich neue Konzepte ohne das Risiko teurer Fehlinvestitionen erkunden und die Softwarepakete vor dem Einsatz auf Herz und Nieren testen lassen.

Historisch gewachsen

Die IT-Landschaft typischer Unternehmen besteht neben der Bürosoftware auf den Mitarbeiter-PCs und den Werkzeugen zur elektronischen Kommunikation (Intranet, E-Mail) auch aus betriebswirtschaftlicher Standardsoftware (wie ERP- oder CRM-Systeme) und Speziallösungen für unternehmenskritische Aufgaben auf Großrechnern, etwa das Verwalten der Produktdaten oder das Steuern der Produktion.

Daneben existieren Individuallösungen auf Basis von Client-Server- oder Web-Technologien. Während all diese Anwendungen überwiegend die operativen Geschäftsprozesse des Unternehmen unterstützen, machen dispositive Systeme auf der Basis von Data Warehouses und Business Intelligence das Unternehmen besser strategisch plan- und steuerbar.

Öffnen und integrieren

Jedes dieser Programme bildet in der Regel ein in sich geschlossenes System, das alle benötigten Funktionen wie Benutzeroberfläche, Business-Logik und Datenhaltung selbst implementiert. Abhängig von der Art der Software variiert der Umfang der integrierten geschäftlichen Abläufe und (Teil-)Prozesse, bei ERP- oder CRM-Systemen ist er erfahrungsgemäß größer, bei individuellen Fachanwendungen eher kleiner. Zudem sind die Programme historisch gewachsen und basieren auf heterogenen Technologien und Plattformen. Dies erschwert es, Daten über offene Standards auszutauschen.

Schnittstellen für Monolithen

Dass derart monolithische, heterogene Landschaften so verbreitet sind, ist ein Produkt der organisatorischen Praxis: In den meisten Fällen organisieren die einzelnen Bereiche oder Abteilungen ihre IT eigenverantwortlich. Zwangsläufig decken die Anwendungen dann die Bedürfnisse der für sie verantwortlichen Organisationseinheiten sehr gut ab, während sie übergreifende Prozesse und Anforderungen stiefmütterlich behandeln. Interoperabilität ist in diesen Szenarien eher zweitrangig entwickelt. Die Geschäftsprozesse in Unternehmen jedoch laufen fast immer orthogonal zur Aufbauorganisation ab, sie sind einheiten- und damit auch systemübergreifend.

Wenn mit der Zeit der Wunsch nach Integration der Softwarekomponenten wächst, bauen die Entwickler in der Regel Schnittstellen als Punkt-zu-Punkt-Verbindungen zwischen einzelnen Programmen ein. Damit aber gerät die IT-Landschaft immer komplexer und mit jedem neuen System steigen die Kosten exponentiell.

Paradigmenwechsel

Mit der Idee der Service-Orientierung und der darauf aufbauenden Service-orientierten Architektur (SOA) entsteht so erstmals ein Ansatz, die Abbildung der Geschäftsprozesse durch die Unternehmens-IT nachhaltig zu verändern und zu optimieren.

Die Idee dahinter ist die Abkehr von den ungeliebten Inselprogrammen und eine grundsätzliche Reorganisation der IT-Prozesse: SOA vereinheitlicht die Verbindung der einzelnen Services entlang der Geschäftsprozesse (Service Orchestration) sowie die Interaktion mit den Benutzern prozessübergreifend und verlagert sie in zentrale Workflow- oder Service-Orchestration-Engines (Prozessabläufe) und Enterprise-Portale (Benutzeroberflächen).

Die größte Herausforderung stellt der Paradigmenwechsel in der Organisationsstruktur dar: Die Abteilungen verlieren ihre Verantwortung für die monolithischen Anwendungen. Sie sind zukünftig nur noch für ihre Services zuständig, die aber wiederum für alle Mitarbeiter bereitstehen. Die IT-Abteilungen geben Kompetenzen an die Business-Seite ab und konzentrieren sich auf Verfügbarkeit und Betrieb der Services und der Infrastruktur-Komponenten.

REST, SOAP und WSDL

Auch wenn die Services mit unterschiedlichen Technologien wie JMS [1] oder Corba [2] realisierbar sind, versteht man im Kontext einer SOA unter Services meist Webdienste. Diese stellen eine standardisierte Form des Aufrufs von Funktionen auf Basis des HTTP-Protokolls dar. Zwei Varianten sind üblich: REST (Representational State Transfer) und SOAP-Webservices (ursprünglich für Simple Object Access Protocol).

Während ein REST-Service über den Typ des HTTP-Request und die Request-Parameter aufgerufen wird und die Antwort im HTTP-Response meist als beliebiges XML-Dokument zurückliefert, erfolgen bei SOAP Aufruf und Antwort des Service durch die Übertragung standardisierter XML-Nachrichten über HTTP. SOAP ist ein offener Standard des W3C [3].

Alle Webservices stellen eine standardisierte Beschreibung der von ihnen angebotenen externen Schnittstelle in Form eines WSDL-Dokuments (Web Service Description Language) bereit [4]. WSDL ist ein XML-Dialekt, ursprünglich insbesondere für die Verwendung mit SOAP-Services konzipiert (SOAP-Binding), unterstützt es in Version 2.0 auch die Beschreibung von REST-Services (HTTP-Binding).

REST-Webservices lassen sich in der Regel ohne ein spezielles Toolkit erstellen. Analog zur Entwicklung einer dynamischen Webseite implementiert der Programmierer sie etwa mit Servlets oderJSPs in Java, ASP.NET, dem quelloffenen Mono-Framework oder PHP.

Axis2

Alle genannten Programmiersprachen unterstützen auch SOAP-Webservices, jedoch variiert die Abdeckung des SOAP-Standards. Für Java besteht mit dem Axis2-Toolkit [5] aus dem Apache-Projekt ein leistungsfähiges Open-Source-Framework, das zusammen mit einem Java-Webcontainer wie Tomcat [6] beliebige Java-Klassen als Webservice nutzbar macht.

Noch einfacher gelingt das mit dem Wizard aus dem Eclipse Web Toolkit (WTP), den Abbildung 2 zeigt. Als Beispiel aus dem Bankwesen implementiert die gezeigte Java-Klasse modellhaft die Verarbeitungsschritte eines stark vereinfachten Kredit-Genehmigungsprozess. Axis2 generiert dabei automatisch auch das WSDL-Dokument. Zudem bietet es mit WSS4J auch Unterstützung für den WS-Security-Standard.

Abbildung 2: Der Wizard der Eclipse-IDE erzeugt automatisch einen Webservice aus einer beliebigen Java-Klasse mit Hilfe des Axis2-Framework aus dem Apache-Projekt.

Der grafische Editor aus dem Eclipse Web Toolkit hilft beim manuellen Erstellen und Bearbeiten von WSDL (Abbildung 3). Damit sich die damit erstellten Webservices gleich testen lassen, enthält Eclipse einen Wizard, der zu einer vorgegeben WSDL-Beschreibung eines Service einen einfachenen, passenden Java-Client mit Benutzerschnittstelle generiert (Abbildung 4).

Abbildung 3: Grafische Darstellung der WSDL-Beschreibung des Kreditprozess-Service im WSDL-Editor von Eclipse, mit dem sich auch WSDL-Dokumente erstellen und bearbeiten lassen.

Abbildung 4: Der Eclipse-Wizard generiert auf Wunsch aus der WSDL-Beschreibung automatisch einen Testclient für den Kreditprozess-Service, der sofort in Aktion treten kann.

Zukunftsmusik

In der Zukunftsvision einer SOA soll dann die Business-Seite mittels grafischer Werkzeuge ihre Geschäftsprozesse durch die Kombination von Services selbst modellieren, verändern und die Ergebnisse möglichst direkt einer Workflow-Engine zur Ausführung übergeben. Dies flexibilisiert die Unternehmens-IT und erlaubt es den Fachabteilungen stärker als heute, die IT optimal an den Anforderungen auszurichten. Bis zur kompromisslosen Realisierung dieser Vision scheint der Weg jedoch noch lang.

Die grafische Modellierung der Geschäftsprozesse erfolgt meist mit ereignisgesteuerten Prozessketten (EPK) oder Aktivitätsdiagrammen in der Unified Modeling Language (UML). Im Kontext von SOA dagegen kommt allerdings zunehmend die Business Process Modeling Notation (BPMN) zum Einsatz [7]. Deren grafische Darstellung von Geschäftsprozessen ähnelt UML-Aktivitätsdiagrammen und eignet sich aufgrund der intuitiven Semantik auch für Fachspezialisten und Nicht-IT-Profis.

Geschäftsprozesse modellieren unter Linux

Anwender von Linux und anderen Betriebssystemen können die BPMN-Diagramme mit der Eclipse-IDE dank eines quelloffenen Plugins aus dem Eclipse-Project STP (SOA Tools Platform) komfortabel modellieren [8]. Abbildung 5 zeigt darin den im Beispiel gewählten Ablauf der Kredit-Genehmigung.

Abbildung 5: Ein BPMN-Diagramm im Eclipse-Plugin zeigt grafisch den Ablauf der Kreditgenehmigung in einer fiktiven Bank. Der Kundenbetreuer erfasst die Daten, bevor der Kreditspezialist die Bonität prüft und eine Entscheidung trifft. Im Beispiel erweist sich der Kunde als kreditwürdig, der Kundenbetreuer kann das seinem Antragsteller mitteilen und den Kreditvertrag abschließen.

Die abgerundeten Rechtecke repräsentieren jeweils einen Prozessschritt (Task), der dem Aufruf eines entsprechenden Webservice entspricht. Das BPMN-Plugin speichert die erstellten Diagramme in einer Datei mit der Endung ».bpmn« in einem eigenen XML-Format, das sich gut weiterverarbeiten lässt.

Herzstück jeder SOA ist eine Workflow-Engine, die die Webservices zu Geschäftsprozessen verbindet und deren Prozess-Instanzen (Workflows) ausführt.

Orchestrierung

Man bezeichnet diese flexible Kombination von Webservices auch als Service Orchestration, die Workflow-Engine entsprechend als Orchestration-Engine. Die Engine verwaltet den Status aller laufenden Prozessinstanzen und setzt sie im Fehlerfall automatisch wieder auf. Daher benötigen die meisten Workflow-Engines eine leistungsfähige Datenbank als persistentes Gedächtnis.

Innerhalb der Orchestration-Engine beschreibt die standardisierte Web-Service Business Process Execution Language (WS-BPEL, BPEL) in Form einer XML-Struktur die Geschäftsprozesse [9]. Jeder BPEL-Prozess setzt als Kombination von Webservices auf WSDL auf. Um ihn auszuführen, brauchen die Workflow-Engines neben dem BPEL-Code auch die WSDL-Beschreibungen aller beteiligten Webservices.

Verschachtelt

Umgekehrt stellt die Workflow-Engine einen BPEL-Prozess selbst wieder als Webservice bereit. Das führt zu einer komplexen Hierarchie der Geschäftsprozesse, bei der jeder Prozess andere als Unterprozesse enthalten kann. BPEL bildet unter anderem diese Geschäftsprozesse mit einer Struktur aus hierarchischen Blöcken ab. Die einzelnen XML-Tags bilden dabei die Syntax einer Prozess-Programmiersprache, wobei die normalen Anweisungen zur eigentlichen Datenverarbeitung immer aus Aufrufen von Webservices bestehen:

<bpel:invoke name="Bonitaet_pruefen"partnerLink="KreditServiceLink"portType="KreditService"operation="berechneBonitaet"inputVariable="berechneBonitaetRequest"outputVariable="berechneBonitaetResponse"/>

Daneben gibt es in BPEL Datenstrukturen und Variablen, die von XML-Schemas definiert sind, sowie Kontrollstrukturen zur Ablaufsteuerung. Weil aber in typischen Geschäftsprozessen nicht nur IT-Systeme die einzelnen Schritte durchführen, haben IBM und SAP für Interaktionen mit Benutzern (zum Beispiel zur Ein- oder Ausgabe von Daten) eine Erweiterung namens BPEL4people [10] entwickelt, die auch menschliche Aktionen standardisiert beschreiben kann.

Von BPMN zu BPEL

Um die Vision einer SOA zu verwirklichen, muss es aber möglich sein, einen grafisch mit BPMN modellierten Prozess möglichst intuitiv in Form von BPEL in einer Workflow-Engine zu verteilen. Bei der Abbildung von BPMN nach BPEL muss der Entwickler den Tasks entsprechende Services zuordnen. Auch wenn die BPMN-Spezifikation hierfür bereits eine elementare Abbildung von BPMN- auf BPEL-Sprachkonstrukte definiert, erweist sich das in der Praxis jedoch als nicht gerade trivial [11].

Zum einen bestehen zwischen BPMN und BPEL prinzipielle Unterschiede: BPMN-Diagramme bilden einen Ablauf-orientierten gerichteten Graphen, während BPEL-Code eine Blockstruktur hat. Dies schließt es prinzipiell aus, jeden beliebigen BPMN-Prozess überhaupt 1:1 in BPEL zu übersetzen [12]. Für die meisten in der Praxis relevanten Fälle sollte dies aber eigentlich möglich sein [13].

Open Source – Fehlanzeige?

Trotzdem besteht hier auch ein praktisches Problem: Für die Abbildung auf BPEL braucht es zahlreiche zusätzliche Informationen, die ein BPMN-Diagramm zunächst nicht enthält, etwa die WSDL-Beschreibungen der Services, Strukturdefinitionen der im Prozess verwendeten Geschäftsobjekte und vieles mehr.

Viele kommerziell erhältlichen SOA-Werkzeuge nutzen daher eigene, proprietäre Ansätze für die interaktive Definition dieser Zusatzinformationen. Leider besteht für die Abbildung von BPMN auf BPEL aufgrund der formalen Komplexität bisher kein offenes, allgemeines Konzept zur einfachen und pragmatischen Beschreibung dieser Abbildung. Dementsprechend fehlen bisher auch universell einsetzbare Open-Source-Werkzeuge – hier liegt heute sicherlich der größte Bedarf für weitere angewandte Forschungs- und Entwicklungsaktivitäten rund um SOA.

BPEL mit Open-Source-Software und Linux

Unter Linux stehen aber immerhin mehrere Open-Source-BPEL-Engines zur Verfügung, wobei nahezu alle freien Implementierungen auf Java aufbauen. Ob im Umfeld populärer Skriptsprachen zukünftig auch vergleichbare Projekte entstehen, bleibt spannend.

In jedem Fall ist eine BPEL-Engine eine Performance-kritische Infrastruktur-Komponente, die einen ausreichend dimensionierten Linux-Server voraussetzt. Zwei verhältnismäßig schlanke Java-basierte Implementierungen sind ODE [14] und Active BPEL [15]. Dank Java sind diese portabel und lassen sich analog unter vielen Betriebssystemen verwenden.

Derby, MySQL und Oracle

ODE ist die BPEL-Engine des Apache-Projekts. Es setzt lediglich einen Java-Webcontainer wie Apache Tomcat [6] voraus, in dem der Admin es einfach in Form eines ».war«-Archivs einspielt. Die persistente Speicherung des Workflow-Zustands übernimmt für ODE eine relationale Datenbank, zur Auswahl stehen Derby, MySQL oder Oracle.

Die normale Distribution nutzt das vorkonfigurierte und mitgelieferte Derby, für einfache Tests ist also keinerlei DB-Installation nötig. Im produktiven Einsatz kommen in der Regel wohl MySQL oder Oracle zum Einsatz. ODE stellt zur Administration selbst verschiedene SOAP-basierte Webservices bereit, über die Admins die Prozess-Instanzen verteilen und sie online überwachen.

Intalio Tempo

In Kombination mit dem eigenständigen Open-Source-Framework Tempo von Intalio [16] lassen sich mit ODE auch Benutzeroberflächen zu den mit BPEL4people modellierten Benutzerinteraktionen realisieren. Darüber hinaus bietet Tempo Funktionen zum Einbetten solcher Benutzeroberflächen in Enterprise Portale. Active BPEL von Active Endpoints ist hingegen eine integrierte Lösung, die von Haus aus auch BPEL4people unterstützt. Es läuft auf Wunsch ebenfalls in einem Java-Webcontainer, die gesamte Administration erfolgt über ein Webfrontend (Abbildung 6).

Abbildung 6: Grafische Administrations-Oberfläche von Active BPEL im Webbrowser. Sie unterstützt unter anderem das einfache Deployment und Monitoring von BPEL-Prozessen.

Als Datenbank arbeitet beispielsweise MySQL, voreingestellt ist jedoch eine In-Memory-Konfiguration, die die Prozesszustände nicht persistent speichert. Dafür kommt diese Version zum Testen auch ohne Datenbank aus.

Mit beiden BPEL-Engines sowie vergleichbaren freien und kommerziellen Lösungen lassen sich Geschäftsprozesse auf Basis von BPEL in einer SOA flexibel realisieren.

Beim Umstieg richtig vorgehen

Eine SOA einzuführen stellt für jedes Unternehmen eine große technische und eine noch größere organisatorische Herausforderung dar. Deshalb sollte es keine Top-down-Entscheidung des Managements sein, die womöglich noch mit einer unternehmensweiten Produktauswahl für eine einheitliche Workflow- und Portal-Umgebung einhergeht.

Viel besser ist es, die genannten Konzepte von unten her in ersten Einzelvorhaben zu erproben und diese dank offener Standards Schritt für Schritt zu größeren SOA-Inseln zu verbinden. Erst danach sollte die IT-Leitung das unternehmensweit einheitliche Vorgehen zur Transformation der übrigen Unternehmens-IT in eine SOA festlegen. Derart dezentrale, flexible Ansätze eignen sich dann besonders für den Einsatz von standardkonformen und kostengünstigen Open-Source-Komponenten. (mfe)