SOA auf Basis von Open-Source leicht gemacht

Services sind universell, stabil, wieder verwendbar, Workflows dagegen spezifisch für einen Kunden oder eine Anwendung und müssen flexibel änderbar sein. Daher ist es wichtig, diese Schichten zu trennen, insbesondere dann, wenn projektübergreifende Lösungsbausteine und kunden- oder projektspezifische Anwendungsteile voneinander isoliert werden müssen. Die Praxis zeigt jedoch, dass die Workflows nie geändert werden, ohne dass es eines neuen oder geänderten Services bedarf.

Es gibt jedoch ein gutes Argument dafür, Workflow Engines einzusetzen: Mitunter lassen Prozessketten nicht „am Stück“ abarbeiten. Beinhalten die Geschäftsprozesse Haltepunkte, an denen auf äußere Ereignisse gewartet werden muss, ist eine Workflow Engine unverzichtbar. Insbesondere, wenn die Prozesse insgesamt länger laufen (Stunden oder gar Tage). Hier ist es unumgänglich, den Kontext der Instanz dieses Geschäftprozesses persistent zu speichern. Ein Spezialfall von Prozessen mit Haltpunkten sind solche, die manuelle Bearbeitungsschritte, also die Interaktion von Anwendern, enthalten. Im Wesentlichen haben sich zwei relevante Standards für die Entwicklung und Ausführung von Workflow-Engines etabliert: die Business Process Execution Language (BPEL) und die XML Process Definition Language (XPDL). Hierfür eignet sich beispielsweise WfM Open, eine Open-Source-Implementierung für eine XPDL-Engine.

Open-Source-Komponenten lassen sich etwa über Standards zusammensetzen, die quasi den Kleber zwischen den Werkzeugen bilden können. So eignet sich XMI für Modelle, die ein Generator-Framework weiterverarbeiten kann. Dass die Werkzeuge in der Praxis gut zusammenpassen, liegt in der Struktur der Open-Source-Landschaft. Niemand tritt hier mit dem Anspruch an, eine Komplettlösung zu liefern. Man ist also darauf angewiesen, miteinander „zu können“. Hier sind es die Quasi- oder Industriestandards, an denen man nicht vorbeikommt, wie Eclipse, das die verschiedenen Tools zusammenschweißt. Eine weitere Quelle für aufeinander abgestimmte und Standards bildende Komponenten ist das Java-Umfeld mit seinem JCP (Java Community Process).

Neben der Auswahl der passenden Technik und Tools ist es entscheidend, das Unternehmen auf SOA und die Verwendung von Open-Source-Tools vorzubereiten. Danet-Mann Görg empfiehlt: „Bis eine IT clever genug ist, solche „Wunderwerke“ zu erschaffen, sollte sie sich darauf konzentrieren, SOA in der Planung und Implementierung von IT-Strukturen für komplexe Aufgabenstellungen zu verstehen und zu testen.“ Dabei liegt der Fokus auf der Designphase. Hier wird eher ein Dokumentations- und Diskussionsforum benötigt, in dem Teams ihre Erfahrungen und Lösungsansätze austauschen, Anforderungen klären und Inhalte (Semantik) von Diensten und Parametern dokumentieren können. Benötigt wird eine Plattform, die alles bietet, was Lösungsarchitekten und -entwickler brauchen, um einen Baustein einsetzen zu können – ein „internes Corporate Wikipedia“. Diese Online-Sammlung von Informationen in einem Unternehmen, die sich dadurch auszeichnet, dass jeder unbürokratisch mitarbeiten und Beiträge leisten kann, unterstützt den Change-Prozess weitaus besser ein UDDI.