Ziel der Arbeit ist es ein Konzept zu entwickeln,
das Interoperabilität zwischen Workflow Management Systemen (WFMS)
ermöglicht. Dieses Konzept soll allgemeingültig sein und nicht
abhängig von bestimmten WFMS. Die WFMS tauschen dabei über eine
Schnittstelle Daten aus, um Workflows in einem anderen System zu starten,
anzuhalten oder weiterzuführen. Dabei werden Objekte, wie z.B. Dokumente,
die zur Bearbeitung des Workflows nötig sind, mitgeliefert. Weiterhin
sind Ausnahmebehandlungen möglich, wie der Abbruch eines Workflows.
Kontrollelemente wie Statusabfragen, Ereignisse und der Austausch spezifischer
Prozeßdaten, wie Attribute, werden von der Schnittstelle ebenfalls
unterstützt.
Auf Grundlage des entwickelten Konzeptes
wurde eine eMail-basierte Lösung mit den WFMS FlowMark von IBM und
WorkParty der Siemens-Nixdorf AG implementiert. Anhand eines aus dem bmb+f
-Projekt PoliVEST stammenden Szenarios, wurde eine exemplarische
Kopplung von Prozessen realisiert, die das entwickelte Konzept verdeutlicht.
Ein Vergleich mit den Standardisierungsbemühungen der Workflow Management
Coalition (WfMC) wird in der Diplomarbeit vorgenommen.
Jegliche Art einer Veröffentlichung ist nur mit vorheriger Genehmigung erlaubt.
WfC stellt kein Meta-WFMS da, sondern einen Service, der den Systemen die Kopplung ihrer Prozesse ermöglicht. WfC wurde so konzipiert, daß es sich auf einfache Weise mit bestehenden Schnittstellen eines WFMS implementieren läßt. WfC muß nicht in den Systemcode integriert werden, sondern ist ein externer Aufsatz, der bei Bedarf durch Prozeßaktivitäten angesteuert werden kann. Sobald ein WFMS die Möglichkeit bietet, externe Programme aufzurufen, Daten auszutauschen und eine API anbietet, kann WfC für dieses System eingesetzt werden.
Die Systeme bleiben intern unberührt, d.h. es wird z.B. keine Prozeßdefinition auf einheitlicher Grundlage angelegt und in die Repräsentation des jeweiligen Systems konvertiert, wie dies in dem Projekt WoTel versucht wurde [WoTel96], sondern der Gesamtprozeß wird in Teilprozesse zerlegt, die auf den jeweiligen WFMS ablaufen sollen. Die Teilprozesse werden in jedem System in der eigenen Spezifikation definiert und um Aktivitäten erweitert, die die Kooperation übernehmen. Diese Prozeßdefinitionen werden so abgelegt, daß sie von WfC instantiiert werden können. Am Übergang eines Teilprozesses in den nächsten wird nun die für die Verbindung zuständige Aktivität ausgeführt. Diese Aktivität startet ein Programm, den sogenannten WfCClient. Dieser erstellt aus den vom WFMS übernommenen Daten einen Request. Dieser Request wird im Rahmen einer Session dem WfCServer des adressierten Systems übermittelt. Die Übermittlung übernimmt ein sogenannter Connection Service, die Komponente in WfC, die einen bestimmten Kommunikationsservice implementiert. Ein solcher Request enthält alle benötigten Informationen für die gewünschte Aktion, die im adressierten System ausgeführt werden soll. Eine solche Aktion wäre z.B. den Prozeß Bestellung starten. Dieser Prozeß ist in einer Prozeßdefinition beschrieben, im adressierten WFMS als Muster abgelegt und instantiierbar. Weiterhin fügt der Client dem Request alle Objekte hinzu die nötig sind, um den Prozeß bearbeiten zu können. Dies wäre in obigem Beispiel die Bestellung als Dokument und evtl. noch einige Attribute, die die Bestellung eingehender beschreiben. Im adressierten System wird die Information aus dem Request durch den WfCServer extrahiert und die gewünschte Aktion ausgeführt. Im obigen Beispiel wird nun aus der Prozeßdefinition Bestellung eine Prozeßinstanz erzeugt, die Attribute mit den übergebenen Werten initialisiert und das Dokument der Instanz übergeben.
An den Übergängen von einem Teilprozeß in den nächsten, definiert WfC somit eine einheitliche Schnittstelle, die einen Datenaustausch und das Übertragen von Prozeßinformationen ermöglicht. Dies ist jedoch nicht das einzige unterstützte Szenario. Mit den von WfC zur Verfügung gestellten Aktionen können Prozesse und Subprozesse gesteuert und Statusberichte angefordert werden. Weiterhin können Prozesse Ereignisse (Events) austauschen, sich über Ereignisse synchronisieren oder über eine sogenannte Extension Applikations-spezifische Erweiterungen implementieren.
Vorteile bei diesem Ansatz ergeben sich bei der Entwicklung der Prozesse im jeweiligen WFMS, da Änderungen bzw. Erweiterungen für die Kopplung nur an den Übergängen der Teilprozesse auftreten. Andere WFMS sehen den Teilprozeß als ‘black box’, der nur über die definierten Schnittstellen mit ihnen kommuniziert. Diese Eigenschaft erfüllt die in [HHS96] gestellten Forderungen nach dem Prinzip eines Baukastens mit Standardprozessen:
‘Die Gestaltung der Prozesse bleibt im Sinne einer ‘black box’ dem jeweiligen Einzelfall überlassen’.
Damit kann ein Unternehmen eine Schnittstelle bereitstellen, unter der es bestimmte Leistungen anbietet, d.h. es werden Prozeßaliase angegeben und die benötigten Daten, wie Attribute oder Dokumente aufgelistet.
Mit dieser Vorgehensweise können auch Dokumenten Management Systeme angebunden werden, da die WfC-Komponenten bei der Umsetzung der Semantik der Aktionen zum System hin frei sind und somit die Aktionen in dem jeweiligen System nach Belieben implementiert werden können. D.h. die Auswirkungen der geforderten Aktion müssen nur nach außen hin ‘sichtbar’ sein, wie die Aktion im System umgesetzt wird ist nicht von Interesse. Man könnte dies auch mit einer Dienstleistung vergleichen, deren Ergebnis festgelegt ist, wie diese jedoch erreicht wird ist nebensächlich.
Man erhält sogar ein flexibleres Gesamtsystem, indem man die Prozesse so aufteilt, daß Stärken von einzelnen Systemen ausgenutzt und Schwächen anderer umgangen werden, wie z.B. Dokumentenverwaltung oder die Modellierung komplexer Prozeßabläufe. So könnte ein Unternehmen ein für einen bestimmten Bereich spezialisiertes WFMS in das firmenweit benutzte WFMS mittels WfC integrieren, d.h. es können in den firmenweit ablaufenden Prozessen, die Teilabläufe in den Spezialbereich integriert werden und ein solcher Prozeß direkt in das spezialisierte System übergehen.
Der WIS besteht wiederum aus zwei Modulen: einem WFMS-spezifischen Modul, das die Verbindung einer Komponente zum WFMS realisiert und für die Umsetzung des WfC-Konzeptes für das jeweilige WFMS zuständig ist. Die zweite Komponente ist das WfC-Basismodul, das für alle WFMS gleich ist. Das Basismodul bildet die Grundlage des WfC-Konzeptes, d.h. es implementiert die Mechanismen und Aktionen von WfC, die für alle WFMS gleich sind.
Der zu benutzende Connection Service wird in der wfc.ini unter DefaultConnectionService in Sektion WorkflowConnect festgelegt. Eine andere Möglichkeit ist es, den Connection Service dem WfCClient in der Kommandozeile anzugeben. Der Service muß aber innerhalb einer Session gleich bleiben. In der vorliegenden prototypischen Implementation wurde ein Connection Service mit eMail als Kommunikationsservice realisiert. Es wurde aber auf ein generisches Konzept geachtet, das es erlaubt, weitere Services als Connection Service zu integrieren.
Wird eine Komponente für ein bestimmtes WFMS A implementiert, so spricht man von der WfC-Komponente für WFMS A (z.B. WfCServer für WorkParty 2.1). Diese Komponente ist nur für dieses WFMS einsetzbar.
Homepage (http://www.dfki.uni-kl.de/~maus/)