WS-Flow Language
WSFL ist die Abkürzung für Web Services Flow Language. WSFL ist Teil der sogenannten WS-*-Spezifikationen als industrieller Standard des World Wide Web Consortium W3C. Die Web Services Flow Language (WSFL) ist eine von IBM entwickelte XML-Sprache zur Beschreibung von Web Services-Geschäftsprozess. WSFL definiert per XML ein Modell eines gerichteten Graphen von durch Kontrollflüssen und Datenflüssen verbundenen Aktivitäten, welche in einer Workflow-Engine abgearbeitet werden kann. Die Ideen von WSFL flossen unter anderem in WS-BPEL ein. Die Web Services Flow Language unterstützt zwei Arten von Kompositionen und Choreographien: Flow-Modelle, beschreiben die Geschäftsprozesse Globale-Modelle beschreiben die gesamten Partnerinteraktionen.
WSFL ist die Abkürzung für Web Services Flow Language. WSFL ist Teil der sogenannten WS-*-Spezifikationen als industrieller Standard des World Wide Web Consortium W3C.
Die Web Services Flow Language (WSFL) ist eine von IBM entwickelte XML-Sprache zur Beschreibung von Web Services-Geschäftsprozess.[1] WSFL definiert per XML ein Modell eines gerichteten Graphen von durch Kontrollflüssen und Datenflüssen verbundenen Aktivitäten, welche in einer Workflow-Engine abgearbeitet werden kann.
Die Ideen von WSFL flossen unter anderem in WS-BPEL ein.
Die Web Services Flow Language unterstützt zwei Arten von Kompositionen und Choreographien:
- Flow-Modelle, beschreiben die Geschäftsprozesse
- Globale-Modelle beschreiben die gesamten Partnerinteraktionen.
Flow-Modelle
[Bearbeiten | Quelltext bearbeiten]Die Leistungseinheit in WSFL ist eine Aktivität und wird mittels Knoten in einem verknüpften Diagram dargestellt, der dataLink und controlLink stellen den Datenfluss und den Kontrollfluss zwischen diesen Aktivitäten dar. Ein DataLink gibt an, dass seine Quellaktivität Daten als Teil des Kontextes der Prozessinstanz an die Flow Engine weiterleitet, die wiederum (einen Teil) dieser Daten an die Zielaktivität des DataLink weitergeben muss. Daten fließen immer über controlLinks. Der controlLink-Pfad muss jedoch nicht direkt sein und kann mehrere Aktivitäten umfassen. Der dataLink ermöglicht bei Bedarf die Spezifikation einer Zuordnung zwischen einem Quell- und einem Zieldokument.
Es gibt höchstens einen ControlLink zwischen zwei Aktivitäten und das Modell muss azyklisch sein, so dass Schleifen innerhalb des Kontrollflusses verboten sind. Das Modell unterstützt jedoch wiederkehrende Aktivitäten unter Verwendung eines Exit-Bedingungsmechanismus, der so lange läuft, bis die Exit-Bedingung wahr wird. Das Kontrollflussmodell unterstützt Forks (Aktivitäten mit mehr als einem ausgehenden Übergang) und Joins (Aktivitäten mit mehr als einem eingehenden Übergang). Aktivitäten, die keine eingehenden Übergänge haben, werden als Startaktivitäten bezeichnet, ähnlich wie Aktivitäten ohne ausgehende Übergänge als Endaktivitäten. Wenn ein Flow-Modell instanziiert wird, werden alle seine Startaktivitäten ermittelt und für die Ausführung eingeplant.[2]
Globale-Modelle
[Bearbeiten | Quelltext bearbeiten]Das globale Modell bietet die Möglichkeit, Interaktionen zwischen Geschäftspartnern zu modellieren. Dabei ist allerdings zu beachten, dass ein globales Modell lediglich eine Zuordnung zwischen Ein- und Ausgängen ist. Im Gegensatz zu EbXML BPSS können Geschäftssemantik wie Ablehnung, Servicequalität, Rechtsverbindlichkeit, garantierte Lieferung auf Anwendungsebene nicht durch ein globales Modell spezifiziert werden. WSFL-Kooperationen sind etwas nützlicher als XLANG-Verträge, da sie das Mapping mit bidirektionalen Diensten ermöglichen, aber noch weit von ebXML BPSS entfernt sind.[2]
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Web Services Flow Language (WSFL). 4. Februar 2002, abgerufen am 26. Oktober 2018 (englisch).
- ↑ a b ebpml: WSFL. Archiviert vom (nicht mehr online verfügbar) am 29. Juli 2017; abgerufen am 26. Oktober 2018 (englisch). Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
