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.

Wieder Wiederverwendung

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 [3] ). 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.

» weiterlesen