Service-orientierte Architekturen

Wo SOA an seine Grenzen stößt

05.02.2009
Von Gernot Schäfer

Autarke Dienste im Service-Layer

Um in Prozessmodellen autark verwendbare Dienstaufrufe bereitstellen zu können, bedarf es einer umfangreichen Harmonisierung der Applikationsbausteine für die Kundenverwaltung auf allen Ebenen:

  • Applikationslogik ("Kunde erfassen"),

  • Applikationsarchitektur (.NET versus RPG),

  • semantisches Datenmodell ("Kunde" versus "Interessent") und

  • Datenbanksyntax (Feld-"Mapping").

Erst wenn sie durchgängig standardisiert sind, können die Funktionsbausteine der verschiedenen Applikationen in der nächsten Ebene, dem Service-Layer, als autark aufrufbare Dienste mit folgenden Komponenten hinterlegt werden:

  • Schnittstellen für den Zugriff auf Funktionen und Daten,

  • ein Service-Contract, der Berechtigungen und Ablaufbedingungen des Dienstes spezifiziert, und

  • eine Service-Implementierung mit der technischen Realisierung des Dienstes.

Prozesse im Orchestration-Layer

Die nächste Ebene, der Orchestration-Layer, bildet die Geschäftsprozesse ab. Eine Anwendung wird dabei als Sequenz von Dienstaufrufen modelliert. Steuern lässt sie sich über den auf dieser Ebene abgebildeten Prozessfluss sowie mit Hilfe der unterschiedlichen Schritte, Entscheidungspunkte und Verzweigungen in den definierten Workflows.

Eine SOA-Plattform lässt sich nur dauerhaft wirtschaftlich betreiben, wenn sie eine flexible Abbildung der Geschäftsprozesse im Hinblick auf die bestehenden Applikationen erlaubt. Der Orchestration-Layer braucht ein standardisiertes Set von Funktionsbausteinen, die über Applikationsgrenzen hinwegreichen. Sonst entspräche er einem Orchester, in dem alle Musiker mit unterschiedlichen Partituren arbeiteten.