Eine erfolgreiche SOA sollte die einheitliche und best-mögliche Abbildung von Geschäftsprozessen sichern.
Deswegen sollte es auch Bestandteil einer erfolgreichen SOA sein, Abbildungsvorschriften zu definieren – und zwar:
wie die Dienste definiert werden (s. o.)
wie die Geschäftsprozesselemente (Aktivitäten und Ereignisse) in die Dienste abgebildet werden
Dann ist es sogar möglich, diese Abbildungen zu automa-tisieren, also aus den Prozessdefinitionen, Dienstschnitt-stellen zu generieren. MDA und SOA können sich also sinnvoll ergänzen.
Unabhängig von der Vorgehensweise ist die bestmögliche Unterstützung des Geschäfts das Ziel einer SOA, das sich durch die Geschäftsprozesse und den daran beteiligten Menschen definiert. „Top-down“ und „Bottom-up“ sollten damit in beiden Fällen die Definition des Sollprozesses realisieren. Während der Top-down-Ansatz die Prozessde-finition als Ausgangspunkt bzw. Vorlage benutzt, sollte sich beim Bottom-up-Prozess der Soll-Prozess ergeben.
Ansonsten müsste der Soll-Prozess, der dann zum Ist-Prozess wird, angepasst werden. Im Folgenden wird der
„Top-Down“ Ansatz betrachtet. Hier gibt es viele Ent-wurfsmöglichkeiten, sodass der Leitfaden hier nur eine Empfehlung darstellen kann.
Ausgangspunkt: Die Prozessdefinition
Aus dem Ziel lässt sich die Anforderung ableiten, dass die Elemente der Geschäftsprozesse auf die technischen Ope-rationen der Dienstschnittstellen so genau wie möglich abgebildet werden müssen.
Die gängigsten, fachlichen Beschreibungen von
Geschäftsprozessen sind die ereignisorientierten Prozess-ketten (EPKs) und Sequenzdiagramme bzw. UML-Modelle.
Hier unterscheidet man Aktivitäten von Ereignissen.
Bei einer Aktivität, fordert ein Akteur (z. B. eine Organi-sationseinheit) einen anderen Akteur (z. B. eine andere Organisationseinheit) auf, etwas zu tun.
Beispiel: Der Vertrieb fordert das Auftragsmanagement auf, einen neuen Auftrag anzulegen.
Bei einem Ereignis kommuniziert ein Akteur (z. B. eine Organisationseinheit), dass sich etwas ereignet hat. Der Zustand eines Prozesses hat sich also geändert. Auf dieses Ereignis können andere Akteure mit Aktivitäten reagieren.
Beispiel: Das Auftragsmanagement signalisiert (das Ereignis), dass ein Auftrag erzeugt worden ist. Daraufhin reagiert der Vertrieb, indem er mit dem Kunden Kontakt aufnimmt und ihm mitteilt, dass der Auftrag angenom-men worden ist.
Betrachtet man die Kommunikation zwischen zwei Akteuren, ist es also besonders wichtig, darauf zu achten, ob ein Akteur aufgefordert wird, etwas zu tun (Aktivität) oder ob er auf ein Ereignis reagiert und selbst entscheidet,
Organisationseinheit
(z. B. Vertrieb) Organisationseinheit
(z. B. Auftragsmanagement)
Organisations-einheit
Aktivität: „tue etwas“
Bsp.: „Neuen Auftrag anlegen“
Ereignis: „es ist etwas passiert“
Bsp.: „Auftrag angenommen“ Ereignis: „es ist etwas passiert“
Bsp.: „Auftrag angenommen“
intern:
Bsp.: „erstelle Auftrag“
Fachlicher Prozess org. intern:
versende E-Mail
Ereignis: „es ist etwas passiert“
Bsp.: „Auftrag an Kunde übermittelt“
Abbildung 18: Abbildung einer Prozessdefinition mit Aktivitäten und Ereignissen in UML-naher Darstellung
was zu tun ist (z. B. organisationsübergreifend: Ereignis mit einer selbst initiierten internen Aktivität).
Architekturentwurf Schritt 1 – Identifzierung der Dienste
Als erstes stellt sich die Frage, welche Dienste benötigt werden und wie man sie aus den Geschäftsprozessen ableiten kann.
Hierfür gibt es keine pauschale Antwort. Dabei ist auch wichtig zu betrachten, ob der Schwerpunkt der SOA in einer unternehmensweiten oder der anwendungsinter-nen (Prozess-)Ebene liegt.
Bei der Betrachtung unternehmensweiter Prozesse sind die Akteure gute Dienstkandidaten, also z. B. ein Vertriebs-dienst oder ein AuftragsmanagementVertriebs-dienst. Hier finden sich die Fachabteilungen wieder.
Anwendungsintern sind die fachlichen Objekte wie die Bestellung oder der Auftrag bzw. der Bestell- und Auf-tragsdienst gute Kandidaten.
Architekturentwurf Schritt 2 – Abbildung der Aktivitäten und Ereignisse
Die Abbildung der Aktivitäten und Ereignisse hängt sehr stark davon ab, wie der Prozess gesteuert wird und auch welche technischen Ansätze verwendet werden.
Bei der Prozess-Steuerung unterscheidet man die direkte Steuerung („Orchestrierung“) von der indirekten Steue-rung („Choreographie“).
Bei der Orchestrierung wird die Prozessdefinition (z. B.
von einem EPK nach BPEL überführt) in eine zentrale Steuerungskomponente geladen, die dann den Prozess verwaltet. Anhand der Prozessdefinition werden zur Lauf-zeit Prozessinstanzen erzeugt, deren Zustände durch die Prozess-Steuerung verwaltet werden. Ein neuer Zustand, also ein Ereignis ist damit das Ergebnis einer Aktivität eines Dienstes.
Beispiel: Nach der Definition des Bestellprozesses wird die Definition des Prozesses in eine Steuerungskompo-nente geladen. Zur Laufzeit wird eine neue Instanz eines Bestellprozesses erzeugt, wenn ein Kunde eine Bestellung auslöst. So wird von der Prozess-Steuerung die Aktivität
„Neuen Auftrag Anlegen“ im Auftragsmanagementdienst ausgelöst, sobald ein Auftrag angelegt werden soll. Nach erfolgreicher Beendigung überführt die Steuerungskom-ponente die Instanz des Prozesses in den Zustand „Auf-trag Angelegt“. Danach löst die Steuerungskomponente im Vertriebsdienst die Aktivität „Benachrichtige Kunde“
aus. Nach der Beendigung setzt die Steuerungskompo-nente den Zustand „Auftrag an Kunde übermittelt“.
Fazit: In diesem Szenario stellen Dienste typischerweise nur Aktivitäten in Form von Operationen bereit. Diese sollten zur Wiedererkennung den Namen der Aktivität aus der Prozessdefinition tragen. Es findet eine synchrone, Punkt-zu-Punkt Kommunikation mit der Prozess-Steue-rung statt.
Auftrags-management
Auftrags-management
Vertrieb Vertrieb
Kunde Kunde
hat bestellt
Neuen Auftrag anlegen
Auftragsanfrage entgegengenommen
erstelle Auftrag
Auftrag erstellt
versende E-Mail
Auftrag an Kunde übermittelt
Abbildung 19: Prozessdifinition als Ereignisgesteuerte Prozesskette
Bei dem Choreographie-Ansatz wird der Prozess indirekt gesteuert. Dienste rufen sich gegenseitig auf.
Hier empfiehlt sich, die Implementierung der Aktivitäten und Ereignisse von der Prozessdefinition, der Verwaltung der Prozessinstanzen und -variablen zu trennen. Letzte-res kann die Steuerungskomponente z. B. über eine Rule Engine leisten.
Falls der Einsatz einer zentralen Prozesssteuerung nicht möglich ist (z. B. weil nicht geklärt werden kann, wer den Prozess steuern soll), ist es auch möglich, dass die Dienste ihren Teil der Steuerung selbst implementieren.
Schließlich müssen die Dienste nur wissen, welches Ereig-nis bzw. welche Aktivität ausgelöst werden muss, sobald die eigene Aktivität bzw. die Kommunikation des eigenen Ereignisses beendet ist. Auch parallele Ausführungen sind damit einfach zu realisieren.
Beispiel: Der Bestellprozess ist durch den Vertrieb gemein-sam mit dem Auftragsmanagement definiert worden.
Der Vertrieb hat einen Vertriebsdienst und das Auftrags-managent den Auftragsmanagementdienst implementie-ren lassen. Die Schnittstellen enthalten die vereinbarten Aktivitäten bzw. Ereignisse. Ein Kunde bestellt über das Vertriebsportal des Vertriebsmanagements. Das Portal
Auftrags-management
Auftrags-management
Vertrieb Vertrieb
Kunde Kunde
hat bestellt
Neuen Auftrag anlegen
Auftragsanfrage entgegengenommen
erstelle Auftrag
Auftrag angenommen
versende E-Mail
Auftrag an Kunde übermittelt
org. intern
org. intern Organisationseinheit
(z. B. Vertrieb) Organisationseinheit (z. B. Auftragsmanagement)
Aktivit: „tue etwas“
Bsp.: „Neuen Auftrag anlegen“
Ereignis: „es ist etwas passiert“
Bsp.: „Auftrag angenommen“
intern:
Bsp.: erstelle
Vertriebsdienst
Auftragsmanagement-dienst
Abbildung 20: Identifizierung von Diensten anhand von Organisationseinheiten auf Unternehmensebene. Auch andere Kriterien sind denkbar.
Zerlegung des EPKs in organisationsinterne und externe Prozesse für den besseren Vergleich
fordert den Auftragsmanagementdienst über die Aktivi-tät „Neuen Auftrag anlegen“ auf, den Auftrag anzulegen.
Mit der Anlage des Auftrags publiziert der Auftragsma-nagementdienst das Ereignis „Auftrag angenommen“.
Dieses Ereignis erhält u. a. der Vertriebsdienst. Er reagiert, indem er eine E-Mail generiert und dem Kunden zustellt.
Danach kommuniziert der Vertriebsdienst das Ereignis
„Auftrag an Kunden übermittelt“.
Es wird deutlich, dass der Choreographie-Ansatz Ereig-nisorientierung unterstützt, die man aus den ereignis-orientierten bzw. nachrichtenereignis-orientierten Architekturen (MOMs, EDA) kennt. Er unterstützt sowohl eine 1-zu-1 als auch eine Publish-/Subscribe-Kommunikation. Der Ansatz bietet sich vor allem dort an, wo es z. B. aus organisato-rischen Gründen nicht möglich ist, eine zentrale Prozess-Steuerung zu etablieren (wem gehört sie?) oder wenn die fachliche Abläufe durch die Verwendung von Ereignissen
„loser gekoppelt“ werden sollen. Beispielsweise kann sich-bei der Definition des Prozesses auf Unternehmensebene auf die Kommunikation zwischen den Organisationsein-heiten konzentriert werden, bei denen internen Teilpro-zesse durch externe Ereignisse ausgelöst werden, die nicht extern abgestimmt bzw. publiziert werden müssen.
Dabei muss jedoch nicht auf eine „engere Kopplung“
durch Aktivitäten („Tue etwas“) verzichtet werden. Beides ist gemeinsam einsetzbar.
Während der Choreographie-Ansatz flexibler und organi-satorisch einfacher zu etablieren ist, ist er in der SOA-Welt noch relativ neu. Die dazu gehörenden Standards sind noch nicht „marktreif“ bzw. akzeptiert. Der Orchestrie-rungs-Ansatz repräsentiert den momentanen Stand der Technik.