20061025 \  Gastbeiträge \  Wachsen BPM- und Workflow-Welt zusammen?
Wachsen BPM- und Workflow-Welt zusammen?
„BPEL, WS-BPEL4, BPEL4PEOBLE, XPDL, BPMN, XML, UML, …“. Update des Artikels „BPM … alles ist so schön bunt hier“ aus dem Newsletter 20050218Newsletter 20050218
von Dr. Martin Bartonitz
Der Autor ist langjähriger Kenner des Business Process Management Marktes. Er entwickelte und betreute selbst BPM-Softwarelösungen von Unternehmen wie COSA und Saperion. Für PROJECT CONSULT war Dr. Bartonitz als Seniorberater längere Zeit in Business-Process-Manage-ment- und Workflow-Projekten tätig. Bei der Saperion AG in Berlin ist er als Produktmanager verantwortlich für die Workflow- und Business-Process-Management-Produkte;  
E-Mail: Ma
rtin.Bartonitz@Saperion.com.
Einleitung
Ich denke, es ist 18 Monate nach der Veröffentlichung meines ersten Artikels zu diesem Thema an der Zeit, zu resümieren: welche meiner Annahmen haben getroffen und welche neuen Trends zeichnen sich inzwischen ab? Wie geht es mit den Welten der Web-Service- und Human-Activity-Zentriker weiter?
Hinweis: da die Zahl der Akronyme im Umfeld des Geschäftsprozessmanagement eher weiter gestiegen ist als dass sich etwas gelichtet hätte, komme ich auch dieses Mal nicht umhin, den geneigten Leser bzgl. der Lesbarkeit zu warnen: es bleibt weiterhin ganz schön bunt hier!
Im September 2006 hatte ich die Gelegenheit, mich auf einer Veranstaltung der OMG – Object Management Group - hautnah über die Neuerungen am Markt der Standards informieren zu lassen. Ich muss gestehen, am Ende des Tages war ich doch eher enttäuscht als zuversichtlich. Denn es sieht doch so aus, dass sich die beiden Welten der Web-Service-Orchestrierung (BPM) und des Workflow Managements a la WfMC – Workflow Management Coalition - nicht so schnell zusammen finden werden, wie von mir erwartet (erhofft?).
Die folgende Grafik gibt einen Überblick über die Welt der wichtigsten Standards im BPM-Umfeld. Der Zeitstrahl ist nicht exakt, wichtig sind hier die Zusammenhänge. Auch sind nicht alle angrenzenden Standards, so z.B.  die Service Oriented Architecture betreffend, dargestellt. Die verantwortlichen Organisationen sind mit ihrem Gründungsjahr angegeben. Die Kästchen der 3 wichtigen Standards XPDL, WS-BPEL und BPMN sind zur besseren Lesbarkeit heller dargestellt. Ähnlichkeiten der Grafik mit den Swim Lanes der BPMN sind völlig ungewollt.
 
 
 
 
Abbildung 1:  
Der lange Weg der Standards im Umfeld der Geschäftspr
ozesse
Auch bestätigte sich mir, dass sich die Markteinführung des SOA - Service Oriented Architecture –sehr zäh gestaltet. Die Frage in den Teilnehmerkreis der Veranstaltung, wer denn schon eine SOA im Hause implementiert hat, wurde nur von etwa 6 der etwa 240 Teilnehmer der 3 Veranstaltungsorte positiv beantwortet. Einen beeindruckenden Grund für eine zwingend langsame Einführung hat einer der vortragenden Anwender gezeigt: eine riesige Tapete vorhandener Applikationen basierend auf Millionen von COBOL-Code-Zeilen. Da ist nicht Viel mit einem „Wir legen jetzt mal den Schalter auf SAO um“ drin.
Dagegen fehlte ich mit meiner Annahme, dass die BPMN – Business Process Modeling Notation – der BPMI – Business Process Management Initiative - in der UML – Unified Modeling Language –ggf. als Ersatz des Aktivitäten-Diagramms aufgehen würde. Zwar ist die BPMI Mitte 2005 vollständig in der OMG aufgegangen, aber auf der besagten OMG-Veranstaltung wurde festgestellt, dass die UML primär bei den Technikern Akzeptanz findet. Dagegen stehen die Anwender eher auf weniger detaillierte Modellierungsapplikationen und können sich besser mit einem Werkzeug auf Basis der BPMN anfreunden. Aus diesem Grund  wird es zukünftig  neben der  UML  weiter
 
hin die eigenständige BPMN geben. Übrigens ist die von der BPMI anfangs spezifizierte BPML – Business Process Management Language – zugunsten der weniger mächtigen WS-BPEL – Business Process Execution Language 4 Web Service - der OASIS – Organization for Advancement of Structured Information Standards – inzwischen aufgegeben wurde.
Dass sich die BPMN tatsächlich anschickt, sich zu einem profunden Standard zu entwickeln, lässt sich an der langen Liste von ca. 40 Firmen ablesen, die schon entsprechende Werkzeuge anbieten (siehe unter http://www.bpmn.org). Nachdem IDS Scheer mit der Version 7 ihres ARIS auch die UML-Diagramme unterstützt ist, scheint es nur noch eine Frage der Zeit zu sein, dass alternativ zu den EPKs zukünftig Prozesse in diesem Tool auch in BPM-Notationen gemalt werden können. Hinzu kommt, dass aus den BPMN neben der Prozessausführungssprache PBEL auch die XPDL – Process Definition Language mit X für XML-basiert - der WfMC geschrieben werden kann, und vice versa. Die WfMC hat mit der Version 2.0 der XPDL aus Oktober 2005 neben einigen bisher fehlenden Elementen der BPMN auch die notwendigen grafischen Elemente (Pools, Swim Lanes, Gateways und Events) mit in die Beschreibungssprache integriert, so dass nun ein bidirektionaler Austausch zwischen XPDL und BPMN möglich ist.
 
 
 
Abbildung 2:  
Process MetaModell der XPDL 2.0 mit BPMN-spezifischen Erweiterungen (grau)
Die neue Version 2.0 der WS-BPEL Spezifikation ist aktuell im Review und steht damit kurz vor der Veröffentlichung. Der Schritt hin zur direkten Unterstützung von „menschlichen Aufgaben“ (manual tasks) innerhalb der Prozesse ist weiterhin nicht unterstützt, d.h. es fehlen die notwendigen Zuordnungen von Resourcen, Rollen, Organisationseinheiten oder Systemen. Auch die grafischen Elemente werden vermisst, wie diese dagegen nun seitens der XPDL unterstützt wird, so dass weiterhin ein Lesen einer BPEL-Definition in ein BPMN-Tool nicht möglich ist. Nur beschränkt unterstützt werden Unterprozesse durch „scope“. Ganz fehlen Elemente für die Simulation wie geschätzte Zeit, Wahrscheinlichkeit von Zuständen, Kostenstelle etc..
Es gab Mitte 2005 eine Veröffentlichung eines 18 Seiten-starken White Papers „BPEL4People“ von einer Arbeitsgruppe, die aus Mitarbeitern der IBM und von
 
SAP zusammengesetzt war. Das Ziel dieser Gruppe war es, das Menscheln in die BPEL einzubringen. Leider gab es bis Dato keine weiteren Publikationen. Allerdings gab es von einem der Teilnehmer der schon erwähnten OMG-Veranstaltung den Hinweis, dass IBM diese Spezifikation mittlerweile umgesetzt hätte. Hier bleibt es also noch spannend: wird diese Erweiterung den Weg zu OASIS als Hüter der BPEL-Spezifikation finden?
Obwohl mittlerweile eine Reihe von Werkzeugen auf dem Markt angeboten werden, um BPMN-Diagramme zu erstellen und anschließend daraus BPEL- oder XPDL zu erzeugen, so muss doch folgendes kritisch angemerkt werden: der BPMN fehlt im Gegensatz zur UML oder den EPKs – Ereignisgesteuerte Prozess-Ketten – des Herstellers IDS Scheer eine zugrundeliegende Design-Methodik. Ob das die Anwender aber davon abhalten wird, ihre Geschäftsprozesse mittels BPMN zu beschreiben? 
 
 
 
Abbildung 3:  
Beispiel eines Diagramms nach der BPM-Notation mit Swim Lanes, Activities, Transitions,
Events and Gateways
 
Reicht PBMN-Modellierung für die Ausführung?
Ich habe gerade ausgeführt, dass die BPMN-Diagramme nach XPDL oder BPEL exportiert werden können. So formuliert hört es sich an, als ob nun die Analysten, die BPMN nutzen auch gleich die notwendigen Informationen für den auszuführenden Code hinterlegen: weit gefehlt!
Wir werden vermutlich noch Jahre brauchen, bis ein Analyst ohne Zutun eines Entwicklers mittels eines Prozessmodellierungstools eine komplette Prozessanwendung fertigstellen kann. Ich hatte vor einer Dekade die Gelegenheit, mit einem Kollegen der Fa. IDS Scheer ein Konzept zu erarbeiten, das den Transfer von EPKs in ein konkretes Workflow Management System erlaubte. Prämisse war, dass nach dem Transfer kein weiterer Code im Prozess-Designer des WMS erfolgen durfte. Andernfalls hätte nach einem erneuten Transfer aufgrund einer Prozessanpassung die Codierung ebenfalls wieder erfolgen müssen. Zwei wichtige Erkenntnisse resultierten aus der Umsetzung:
 
   
 a)
Die Anforderungen an die höhere Granularität der Prozessdokumentation aus Sicht des Analysten war nicht mit einer möglichst einfachen Handhabung durch den Anwender in Deckung bringen. Im ersten Fall sollen auch Tätigkeiten dokumentiert werden, die nicht durch das WMS unterstützt werden müssen. Im zweiten Fall macht es wenig Sinn, für jede Tätigkeit eine eigene Workflow-Aktivität vorzusehen, da der Anwender hierbei zu häufig die Maustaste anklicken muss. Der Kompromiss war, dass der Analyst zugunsten der Anwender auf den höheren, möglichen Detaillierungsgrad verzichten musste.
   
 b)
Die Nutzung einer elektronischen Standardanwendung bedeutet immer eine Anpassung der Geschäftsprozesse an vorhandene Restriktionen. Das galt auch für das Ziel-WMS. Es war zwar einerseits möglich, innerhalb von ARIS den Satz der Attribute um die speziellen Workflow-Attribute zu erweitern. Andererseits mussten bzgl. der ARIS-seitigen Modellierung weitere Beschränkungen in Bezug auf das WMS in Kauf genommen werden.
Meine seitdem gesammelten Erfahrungen sagen mir, dass wir auch zukünftig je nach Anwendungsschwerpunkt entweder detaillierte Prozessanalysen mit einem reinen Modellierungs- und Analysewerkzeug durchführen oder mit Hilfe eines Prozess-Designers eines BPMS oder WMS arbeiten. Im ersten Fall wird es weiterhin so sein, dass es eine manuelle Tätigkeit zur Komplettierung des ausführbaren Prozesses braucht. Im Zweiten Fall verzichtet der Analyst auf den Detaillierungsgrad und nutzt die dokumentarischen Fähigkeiten des BPMS-/WMS internen Prozess-Designers.
Fazit: Machen Sie sich keine zu großen Hoffnungen, Ihre „doppelten“ Aufwände für die analytische Prozessbeschreibung und der technischen Umsetzung schon bald per Knopfdruck eliminieren zu können.
Welche Bedeutung hat das „B“ in BPEL?
Vergleicht man die beiden Prozessausführungssprachen XPDL und BPEL, so drängt sich einem Selbstbeteiligten an Geschäftsprozessen doch die Frage auf, warum sich das „B“ für Business in das Akronym BPEL eingeschlichen hat. Ich bin davon überzeugt und so zeigt sich mir auch mein eigenes Geschäftsleben, dass noch immer der Mensch mit seinem spezifischen Wissen um die Geschäftsprozesse den Gang der Dinge bestimmt. Beim Lesen der BPEL-Spezifikation beschleicht mich ein wenig die Unruhe, scheinen doch die Prozesse sich ohne das Zutun des Menschen zu verselbständigen.
Aber malen wir nicht den Teufel an die Wand, wissen wir doch, dass der Mensch aus Sicht der BPEL indirekt beteiligt bleibt. Es müssen die Web Services nach Bedarf so gestaltet sein, dass der Mensch als Entscheidungsträger an den entscheidenden Stellen integriert wird.
Die folgende Tabelle zeigt im Überblick die Unterschiede der beiden Prozessbeschreibungssprachen.
   
Merkmal
XPDL
BPEL
Zielsetzung
Offener Austausch von Prozeß-Definitionen
(WfMC Interface 1) und Dateifo
rmat für BPMN
Spezifikation von ausführbaren und abstrakten Geschäftsprozessen auf Basis von Web Services
Prozess-
Teilnehmer
„Participants“: Resource, Role,
Org Unit, Human, Sy
stem
Dynamische Zuor
dnung mittels Rules während Laufzeit
Intern keine Zuordnung von Teilnehmern, Externe im Message Flow über “Partner (Links)”
Technische Schnittstellen
Diverse, z.B. Web Service, EJB, Pojo, Script, Rule
Web Services (WSDL)
Binding beliebig
Manuelle Tasks
Explizite Definition von Aktivitäten als “TaskManual”
Nicht explizit unterstützt
Modularisierung
Unterprozesse werden unterstützt
Eingeschränkt möglich durch „scope“
Simulation
Enthält Attribute für Time Estimation, Cost Unit u.a.
Nicht explizit unterstützt
Datenfluss
Nur bei Übergabe während Start und Ende eines Subprozesses
Collaboration zwischen parallelen Web Services
Laufzeitverhalten, Problembehandlung
Für langlaufende automatische Aktivitäten (Teilprozesse) keine expliziten Definitionen
Enthält „fault handler“, “compensation handler” und „transaction demarcation“
Austausch mit BPMN
Die Version 2.0 enhält neben Koordinaten und Shape-Größen die Elemente Pool, Lane, Gateway und Event, d.h. bidirektionaler Austausch mit BPMN möglich
Keine grafischen Elemente,
Nur unidirektionaler Austausch von BPMN nach BPEL möglich.
Tabelle 1:  
Gegenüberstellung der Merkmale von XPDL und BPEL (Teile der Tabelle en
tstammen dem Foliensatz „BPEL und Human Workflow, Sept. 2006“, der Fa. Zühlke und wurden vom Autor ergänzt.)
Für die WfMC stehen Aktivitäten, die Ausdruck der Tätigkeiten vorrangig ausgeführt von Menschen sind, im Zentrum ihrer Spezifikation. Die Spezifikation der OASIS ist verstärkt aus Sicht der Entwickler von B2B-Umgebungen geschrieben, deren Herausforderung die Beherrschung des Zusammenspiels von Applikation (Web Services) ist, dies zudem über Enterprise-Grenzen und häufig über längere Zeiträume (> mehrere Stunden) hinweg. Hier scheint der Mensch "nur" als Bediener von Oberflächenelementen eine Rolle zu spielen. Es gibt daher (?) auch in der neuen Version 2.0 keine Aktivitäten-Elemente in der Prozessbeschreibungssprache.
BPMS Referenzmodell
Ich hatte in meinem ersten Artikel Bezug auf „das“ Referenzmodell der BPMI verwiesen und wurde mehrfach nach einem offiziellen Dokument gefragt. Leider kann ich nicht mehr den damals genutzten Originaltext der BPMI auffinden. Jedoch habe ich parallel dazu einen Artikel von David McGoveran im Business Integration Journal gelesen, der eine Einführung in die Thematik BPM und BPMS geschrieben hat. Aus diesen Ausführungen lässt sich die folgende Grafik ableiten.
Um diesen Artikel nicht zu sprengen, möchte ich auf weitere Erklärungen verzichten und den geneigten Interessenten bitten, den genannten Artikel dafür zu nutzen.
 
 
 
Abbildung 4:  
BPMS Referenz Modell abgeleitet aus dem Artikel „An Introduction to BPM & BPMS“ veröffentlicht 2004 von David McGoveran im Business I
ntegration Journal
 
Wie passt Microsoft mit den Windows Workflow Foundation Classes in diese Welt?
Microsoft hatte schon mit dem BizzTalk Server die BPEL-Welt erreicht. Nun ist neben dieser Prozess-Engine noch eine weitere hinzugekommen. Auf Basis des .NET 3.0 Frameworks können nun hierin Workflows per Drag and Drop zusammen gebaut werden.
Laut Gartner ist der Zielmarkt dieser Technologie rein im Umfeld der Microsoft-Produkte zu sehen sowie im Low-Level-Workflow-Segment. Ein typisches Beispiel ist ein Freigabeprozess für ein beliebiges Dokument der MS Office Suite. Hierbei könnte die Workflow-Engine des SharePoint-Servers genutzt werden.
Die Modellierung der Workflows erfolgt in der Entwicklungsumgebung von Visual Studio, d.h. die Nutzung der Workflow Foundation Classes erfolgt durch den Programmierer von Software. Ein Workflow-Client, wie dies von typischen WMS angeboten wird, gibt es nicht. Möglich ist aber die Nutzung von Outlook oder den Oberflächen von SharePoint. Office 2007 ist laut Microsoft komplett in der Workflow Foundation unterstützt.
Das Prozessmodell lehnt sich nicht an der BPM-Notation an. Die Speicherung der Prozessdefinitionen erfolgt im Format XAML, d.h. weder im BPEL- noch im XPDL-Format. Dass nicht BPEL genutzt wurde, wird mit der fehlenden Unterstützung des Human
 
Workflow sowie Sub-Workflow begründet, siehe http://forums.microsoft.com. In dem referenzierten Link wird darauf hingewiesen, dass eine Unterstützung hinsichtlich BPMN und BPEL von Partnern erwartet wird.
Für mich ist die Strategie von Microsoft mit den Doppelwelten des BizzTalk und des SharePoint Servers noch nicht ganz griffig. Jedoch scheint mir für Firmen, die schon jetzt eigene Applikationsentwicklungen unter .NET mit Visual Studio betreiben und komplett auf MS Office setzen die zusätzliche Nutzung der Workflow Foundation für kleinere Prozesse ein logischer Schritt.
Zusammenfassung
Ich bin auch nach 18 weiteren Monaten weiterhin der Meinung, dass es reicht, die jeweils passende, erprobte Formel für die jeweils klar umgrenzte Anforderung zu nutzen. D.h. es wird auch weiterhin ein sinnvolles Nebeneinander der verschiedensten Systemansätze geben. Auch wenn dies bedeutet, dass sich die Unternehmen bei der Auswahl ggf. durch Experten unterstützen lassen müssen.
Nach dem aktuellen Stand der Standards bleibt folgendes Fazit für die Hersteller von BPMS oder WMS:  sie sollte sich langsam darauf einrichten, ihre Prozesse grafisch nach den BPM-Notationen der OASIS zu modellieren und je nach Prozessschwerpunkt, d.h. Web-Service- oder Mensch-zentriert die Prozess-Definitionen in WS-BPEL oder XPDL zu speichern. Es ist gut denkbar, dass in 5 Jahren die drei bis fünf Top BPMN-Tools die drei bis fünf BPMS/WMS-Tools voll unterstützen werden. D.h. die Hersteller können sich dann vermehrt um ihre Kernkompetenzen kümmern: die Einen um das Dokumentieren und Optimieren der Prozesse und die Anderen um das Ausführen und Auswerten.
Übrigens sind in etwa gleich viele Produkte (ca. 40) auf den Seiten der genannten Organisationen gelistet, die die Unterstützung der jeweiligen Standards angeben. Es gibt sicherlich auch eine Dunkelziffer von nicht gemeldeten Produkten. So ist mir z.B. bekannt, dass das nicht gemeldete Produkt COSA Workflow mittlerweile auf das eigene Prozessbeschreibungsformat komplett verzichtet und XPDL nutzt.
Alles Weitere in der Zusammenfassung meines ersten Artikels erachte ich nach wie vor als stimmig und möchte es daher nochmals wiederholen:
Schaue ich mir die Situation des Prozessmanagements in Deutschland an, so sehe ich überwiegend abteilungsweite Realisierungen für die einfache Geschäftsfallbearbeitung, meist im Zusammenhang mit Dokumentenmanagement. Die wenigsten Häuser arbeiten schon abteilungsübergreifend. Ich denke, dass dies in der nächsten Zeit auch noch so bleiben wird. Das wiederum bietet aber auch den kleineren Herstellern (WMS/DMS/ECM/WCM), Nischen mit speziellen Fachlösungen zu finden.
Für die Anwender bedeutet es, dass man sich derzeit um Standards eigentlich nicht so richtig einen Kopf machen muss. Einerseits sind die Großen bei allen wichtigen Standardisierungen dabei und zum anderen kommt es vermutlich auch dann immer noch darauf an, „was am Ende hinten raus kommt.“ Damit soll gemeint sein, dass es keine Weltformel für Prozesssteuerungen geben kann und wird und es immer auf die dedizierten Anforderungen ankommen wird, gegen die die potentiellen Kandidaten sich werden messen müssen.
Und wenn sie vorhaben, ein handfestes BPMS- oder WMS-Projekt anzugehen, denken Sie besonders in diesen Projekten an das übliche "Menscheln" während des zu vollziehenden Kulturwandels in ihrem Unternehmen und ergreifen Sie Maßnahmen zur Sicherstellung einer reibungslosen Einführung. Nicht umsonst weisen uns die Systemtheoretiker hierauf hin:
"Je mehr ein System Änderungen erfährt, desto größer wird sein Widerstand."
Glossar zum Beitrag
  
Akronym
Erklärung
AIIM
Association for Information and Image Management, since 1943
I
nternational authority on Enterprise Content Management (ECM), the tools and technologies that capture, manage, store, preserve, and deliver content in support of business processes.
BPDM
Business Process Definition Metamodell, Definition durch OMG, 2004
Brücke zwischen BPMN und potentiellen Prozessau
sführungssprachen wie BPEL und XPDL
BPEL / BPEL4WS
WS-BPEL
Business Process Execution Language for Web Services, IBM, Microsoft, SAP, BEA,…
XML-based language for standardizing business processes in a distributed or grid computing environment that enables separate businesses to interconnect their applications and share data. Designed as a combination of IBM’s WebServices Flow Language and Microsoft’s XLANG
BPM
Business Process Management, Definition durch BPMI
Methode als auch Verfahren zur kontinuierlichen Ve
rbesserung von Geschäftsprozessen unterstützt durch u.a. WMS.
BPMI
Business Process Management Initiation, gegründet 1999, Mai 2005 in OMG aufgegangen
Organisation von Herstellern, Beratern und Anwe
ndern zwecks Standardisierung der Architektur und Schnittstellen von BPMS.
BPML
Business Process Management Language, Definition durch BPMI, 2001
XML-basierte Geschäftsprozessbeschreibung. Zugun
sten WS-BPEL aufgegeben
BPMN
Business Process Management Notation, Definition durch BPMI, 2004
Grafische Notation zur Beschreibung von Geschäft
sprozessen, ist auf dem besten Wege, sich neben den EPKs und Petri-Netzen zum Standard zu werden.
BPMS
Business Process Management System, Definition durch BPMI
System zur Unterstützung von BPM mit dem Krei
slauf: Model, Execute, Monitor, Analyze & Improve. Ein WMS ist eine Teilkomponente.
ECM
Enterprise Content Management, siehe AIIM
OASIS
Organization for the Advancement of Structured Information Standards, since 1993
is a not-for-profit, international consortium that drives the deve
lopment, convergence, and adoption of e-business standards (in the area of Web Services). U.a. UDDI, WSS
OMG
Object Management Group, since 1997
not-for-profit consortium that produces and mai
ntains computer industry specifications for interoperable enterprise applications. U.a. MDA, UML, OMA, CORBA, …
SOA
Service Oriented Architecture,
In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. This provides for more flexible loose coupling of resources than in traditional systems architectures.
SOAP
Simple Object Access Protocol SOAP, defined by W3C
XML-Based lightweight protocol for exchange of i
nformation in a decentralized, distributed environment.
UDDI
Universal Description Discovery and Integration, Definition by OASIS
UML
Unified Modeling Language, Definition durch OMG, Version 2.0 in 2005
Grafische Notationen zur Beschreibung IT-spezifischer Aspekten zur Erstellung von Software, u.a. von G
eschäftsprozessen, hat das Zeug zum Standard zu werden.
W3C
World Wide Web Consortium, founded in October 1994 by Tim Berners-Lee, the inventor of the Web.
WfMC
Workflow Management Coalition, gegründet 1993
Organisation von Herstellern, Beratern und Anwe
ndern zwecks Standardisierung der Architektur und Schnittstellen von WMS.
WMS
Workflow Management System, Definition durch WfMC
System zur Automatisierung von Geschäftsproze
ssen.
WPDL
Vorgänger von XPDL, 1999
WSCI
Web Services Choreography Interface
XML-based language used to describe the flow of me
ssages exchanged by a Web Service in the context of a process. WSCI describes how WSDL operations are choreographed and which properties these choreographies expose, such as transaction and correlation.
WS-CPL
Web Services Conversation Preference Language
WSDL
Web Services Description Language, Definition by OASIS
is a general purpose XML language for d
escribing the interface, protocol bindings and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services.
WSFL
Web Services Flow Language, IBM
is an XML language for the description of Web Se
rvices compositions as part of a business process definition. It was designed by IBM to be part of the Web Service technology framework and relies and complements existing specifications like SOAP, WSDL, XMLP and UDDI.
WSS
specification provides a platform-independent way of describing services, discovering businesses, and integrating business services using the Internet.
XLANG
Siehe BPEL
XPDL
XML Process Definition Language, Definition durch WfMC, 2001 & 2005
XML-basierte Geschäftsprozeßbeschreibung, dient u.a. dem Austausch zwischen unte
rschiedlichen WMS.
YAWL
Yet another Workflow Language, definiert an der Queensland University of Technology in Australien in Zusammenarbeit mit Prof. Wil van der Aalst, der sich u.a. um das Benchmarken von WMS und Prozessbeschreibungssprachen mittels Workflow Pattern verdient gemacht hat.
 (MBa)
Weitere Kapitel
© PROJECT CONSULT Unternehmensberatung GmbH 1999 - 2016 persistente URL: http://newsletter.pc.qumram-demo.ch/Content.aspx?DOC_UNID=875a4f9f08594222002572c3004eef3d