Untersuchungen zur Erstellung eines Workflowmanagementsystems entsprechend dem Referenzmodell der WfMC Diplomarbeit Universität Rostock, Institut für Informatik, Lehrstuhl Softwaretechnik Albert-Einstein-Str. 21 18059 Rostock Vorgelegt von: Betreuer: Erstgutachter: Zweitgutachter: Christoph Herold Dipl.-Inf. Carsten Eichholz Prof. Dr. Forbrig Prof. Dr. Heuer Abgabedatum: 15. August 2005
Zusammenfassung Workflowmanagement (WfM) ist eine schnell wachsende Technologie, welche in immer größerem Ausmaße von Unternehmen verschiedener Branchen genutzt wird. Zur Zeit existiert bereits ein großes Sortiment an WfM Produkten von verschiedenen Herstellern und es werden ständig neue Produkte in den Markt eingeführt. Die Verfügbarkeit einer großen Produktpalette erlaubt es den Anbietern, sich auf spezielle Funktionen ihres Produkts zu konzentrieren. Unternehmen wählen die Produkte, welche am besten auf ihre Anforderungen abgestimmt sind. Der Umstand, dass bisher noch kein Standard für WfM Produkte definiert worden ist, lässt die einzelnen Produkte zu inkompatiblen Funktionalitätsinseln verkommen, zwischen denen die nötige Interoperabilität fehlt [17]. Mit der Workflow Management Coalition (WfMC) hat sich eine Gruppe von WfM Anbietern zusammengefunden, um dem genannten Problem entgegenzuwirken. Mit Hilfe des Referenzmodells werden eine standardisierte Modularisierung der Architektur eines WfM Produktes und die Definition der Interfaces zwischen den Modulen vorgeschlagen. Durch die Standardisierung wird die Interoperabilität zwischen heterogenen Produkten gewährleistet und ihre Integration in weitere IT Anwendungen ermöglicht. In dieser Arbeit wird ein bestehendes WfM Produkt an die Spezifikationen des Referenzmodells angepasst und anschließend bezüglich der eingebrachten Änderungen getestet. Abstract Workflow management (WfM) is a fast growing technology that is increasingly being exploited in various businesses. At the time a wide range of WfM products is available and there is still a continual introduction of new products into the market. The wide range of WfM products allows vendors to focus on particular function capability. Customers can choose those products that fit the requirements of their business. The fact, that there is no standard for WfM products defined, results in functional islands of products [17]. The workflow management coalition is a grouping of companies who have joined together to address the problem. With the aid of a reference model there is a proposal for a standardized modularization for the architecture of the product and a definition of the interfaces between the modules. The standardizati-
on ensures interoperability between heterogeneous products and integration with other it services. By this project an existing WfM product will be adapted to the reference model and afterwards it will be tested concerning the changes that have been made.
ACM Klassifikation C.3 SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMS D.1.5 Object-oriented Programming D.2.5 Testing and Debugging D.2.12 Interoperability E.1 DATA STRUCTURES H.2 DATABASE MANAGEMENT H.3.2 Information Storage H.3.5 Online Information Services J.7 Process control
Inhaltsverzeichnis 1 Einleitung 1 1.1 Motivation............................. 1 1.2 Gliederung der Arbeit...................... 4 2 Referenzmodell der WfMC 5 2.1 Theoretische Grundlagen des Referenzmodells......... 5 2.2 Beschreibung des Referenzmodells................ 9 2.2.1 Workflow-Enactment-Service............... 11 2.2.2 Workflow-Engine..................... 11 2.2.3 Process-Definition-Tools................. 12 2.2.4 Workflow-Client-Applikationen............. 15 2.2.5 Involvierte Anwendungen................. 17 2.2.6 Interoperabilität..................... 20 2.2.7 Administration und Überwachung............ 23 3 Implementation 26 3.1 Aufbau und Funktionsweise des vorhandenen WfM Systems. 26 3.2 Wahl einer konkreten Spezifikation............... 27 3.3 jflow................................ 29 3.4 Adaption von jflow........................ 32 3.5 Standards für Interface 1 und 3................. 41 3.6 CORBA.............................. 42 3.6.1 Das Objektmodell der OMG............... 42 3.6.2 Die Object Management Architecture.......... 43 3.6.3 Der Object Adapter................... 45 3.6.4 Die Interface Definition Language............ 46 3.6.5 Interoperabilität..................... 47 3.6.6 Wahl einer CORBA-Implementation.......... 47 3.6.7 Funktionsweise von Java IDL.............. 49 3.6.8 Java IDL im praktischen Einsatz............ 51 3.7 Erweiterung der bestehenden Softwarearchitektur....... 53 4 Einbindung einer Datenbank 55 4.1 Funktionsweise von exist..................... 56 4.2 Einbringung von exist in das vorhandene WfM System.... 57 I
5 Zusammenfassung und Ausblick 60 6 Glossar 67 7 Abkürzungen 69 A Adaptierte IDL 70 II
Abbildungsverzeichnis 1 Die drei Funktionsgebiete eines WfM Systems......... 6 2 Top-Level Sicht der Workflowarchitektur............ 8 3 Referenzmodell der WfMC.................... 10 4 Austausch von Prozessdefinitionen................ 13 5 Metamodell zur Prozessdefinition................ 14 6 Beziehung zwischen Workflow-Client-Applikationen und Workflow- Enactment-Service........................ 15 7 Funktionsbereiche von Interface 3................ 19 8 Szenario 1 von Interface 4.................... 21 9 Szenario 2 von Interface 4.................... 21 10 Szenario 3 von Interface 4.................... 22 11 Szenario 4 von Interface 4.................... 23 12 Funktionsbereiche von Interface 5................ 24 13 Architektur des vorhandenen WfM Systems.......... 27 14 Metamodell von jflow...................... 32 15 Strukturänderung an einer Prozessdefinition.......... 33 16 Beispiel einer Workflowstruktur................. 34 17 Struktur einer Prozessdefinition in jflow............ 35 18 Mapping einer uniformen Struktur zur jflow-struktur..... 35 19 Zustandsdiagramme der Ausführungsobjekte bzw. Aufgaben. 37 20 Adaptiertes Zustandsdiagramm................. 38 21 Klassendiagramm der Ressourcen................ 39 22 Symbolische Wurzelknoten.................... 41 23 Object Management Architecture................ 44 24 Funktionsschema des ORB.................... 45 25 Internet Inter-ORB Protocol................... 48 26 Trennung der Komponenten der Architektur.......... 53 27 Erweiterung der Architektur um CORBA-Komponenten... 54 28 Erweiterung der Architektur um die exist Datenbank..... 58 29 Multi-Tier Architektur des entstandenen Systems....... 63 Tabellenverzeichnis 1 Kategorisierung von Interface 3................. 18 2 Gleiche Zustände der Modelle.................. 37 III
1 Einleitung Den Kernpunkt dieser Arbeit bildet das so genannte Referenzmodell der Workflow Management Coalition (WfMC). Aufbauend auf der Diplomarbeit Prototypische Implementation eines adaptiven Workflow-Management- Systems von Björn Zieger [1] soll dieses Modell in die Praxis umgesetzt werden. Dies setzt zu Beginn eine ausführliche Auseinandersetzung mit dem Modell und der vorhandenen Implementation voraus. Ausgehend von den erzielten Erkenntnissen, welche Rückschlüsse auf die Differenzen zwischen den Systemen schließen lassen, kann eine Liste der durchzuführenden Implementationsarbeiten erstellt werden, um die Differenzen zu beheben. Im folgendem Gliederungspunkt wird zunächst als Motivation die Notwendigkeit der WfMC und den von ihr erstellten Studien begründet. 1.1 Motivation Die Workflow Management Coalition versucht in ihren Bestrebungen einen Standard für WfM Systeme zu schaffen. Die hohe Bedeutung von Standards und somit die Bedeutung der Arbeit der WfMC und der vorliegenden Diplomarbeit wird hier kurz erläutert. Heutzutage sind alle großen Organisationen im hohen Maße von der Verfügbarkeit ihrer IT-Anwendungen abhängig. Geschäftsprozesse können nur dann reibungslos abgewickelt werden, wenn die notwendigen Daten schnell und richtig bereitgestellt werden. Aufgrund der breit gefächerten Geschäftsanforderungen ist es heutzutage leider üblich, dass in einer Organisation heterogene, inkompatible Anwendungen verwendet werden [16]. Die mangelnde Fähigkeit zur Kooperation der Anwendungen untereinander birgt auf der einen Seite höhere Kosten aufgrund des erhöhten Zeitaufwands der Mitarbeiter im Umgang mit den Anwendungen und auf der anderen Seite Risiken im Falle des Austausches einzelner Komponenten bezüglich ihrer Kompatibilität mit dem vorhandenen Gesamtsystem. Hier liegt die treibende Kraft der internationalen Standardisierungsbestrebungen, diese Kosten und Risiken zu senken. Die bisherigen Versuche einzelner großer Anbieter, Standards auf eigene Faust unter Ausnutzung der eigenen Marktposition durchzusetzen, misslangen größtenteils, da für die meisten Bereiche der IT-Branche Spezialanbieter existieren, die sich diesen Qua- 1
sistandards nicht beugen. Deswegen ist heute ein eindeutiger Trend zu einer produktneutralen Zusammenarbeit in offenen Organisationen, wie auch der WfMC, zu beobachten, die unternehmensübergreifend Standards durchsetzen. Die WfMC ist eine Organisation, die sich auf die Festlegung von Standards für den Bereich der WfM Systeme spezialisiert hat. Sie besteht aus über 300 Organisationen, welche in ihrer Gesamtheit alle Facetten des WfM repräsentieren. Ihre Ziele lauten: die Erhöhung der Investitionen in die Workflowtechnologie seitens der Anwender, der Verminderung des Risikos, Workflowprodukte zu nutzen und die Expandierung des Workflowmarktes [3] durch den Bekanntheitsgrad von Workflowprodukten. All diese Ziele sollen erreicht werden durch das Definieren von Standards. Zentraler Bestandteil dabei ist das Referenzmodell für WfM Architekturen und die Definition eines Glossars. Dazu hat die WfMC durch Analysen erkannt, dass alle Workflowprodukte in etwa gleichen Charakteristika unterliegen. Diese Tatsache birgt das Potential, dass durch die Festlegung von Standards ein gewisser Grad von Interoperabilität für verschiedene Funktionen der heterogenen Produkte geschafft werden kann. Hierzu hat die WfMC die einzelnen Funktionsgebiete genauer ergründet und eine geeignete Spezifikation für deren Interfaces entwickelt. Zur Zeit besteht der Workflowmarkt aus einer großen Menge an spezialisierten Produkten, welche aufgrund uneinheitlicher oder gar fehlender Interfaces nicht in der Lage sind, miteinander zu kommunizieren. Man könnte dieses Problem mit einer Fußballmannschaft vergleichen, in der es exzellente Angreifer, Abwehrspieler und einen hervorragenden Torwart gibt, die aber nie ein Spiel gewinnen kann, weil die einzelnen Spieler nicht wissen, wie sie sich am besten Aufstellen und sich den Ball zu spielen. Sie müssen vorher ausmachen, welche Aufstellung und Taktik sie wählen. Übertragen auf den Workflowmarkt sind dafür die Standards zuständig. Produkte, die diese Standards unterstützen, wären aufgrund der nun möglichen Kommunikation interoperabel. Eine Menge von Einzellösungen würde so einer mächtigen Gesamtlösung fusionieren. Dadurch entsteht eine Reihe von Vorteilen für den Anwender: die Kosten für administrative Prozesse werden gesenkt, die Effektivität einzelner Produkte wird durch die Integration in eine Gesamtlösung bedeutend erhöht, viele Prozesse können automatisiert werden, die Risiken, ein Workflowprodukt zu kaufen, werden gesenkt. 2
In dieser Arbeit wird durch die Umsetzung der von der WfMC vorgeschlagenen Standards deren Praxistauglichkeit und die Interoperabilität mit anderen standardisierten Produkten getestet. Dazu werden die im Referenzmodell der WfMC definierten Interfaces in das in der eingangs genannten Diplomarbeit von Björn Zieger entstandene WfM System übernommen. Das Resultat wird im Anschluss an die Implementationsarbeit getestet. Grundlegende Kenntnisse im Bereich Workflowmanagement werden vorausgesetzt und hier nicht weiter erläutert [1]. Die Heterogenität der WfM Produkte führt neben der Inkompatibilität auch zu einem erheblichen Begriffswirrwarr. Dazu befindet sich am Ende dieser Dokumentation ein Glossar, in dem wichtige Begriffe mit ihren Synonymen erläutert sind. Nicht unerwähnt dürfen an dieser Stelle konkurrierende Organisationen zur WfMC bleiben. So versucht die Object Management Group (OMG) durch so genannte Requests for Proposals (RfP) Firmen und Organisationen dazu zu bewegen, Spezifikationen für Standards im Bereich des WfM vorzuschlagen. Diese Spezifikationen können allerdings auf Standards der WfMC aufsetzen. Desweiteren existiert die Organization for the Advancement of Structured Information Standards (OASIS), die vor allem durch ihre Business Process Execution Language (BPEL) auf sich aufmerksam machte, mit der Geschäftsprozesse in XML beschrieben werden können. Ein anderes Konzept verfolgt die Business Process Management Initiative (BPMI). Sie bedient sich den Standards der OMG, WfMC und OASIS und definiert dort, wo sie es als notwendig erachtet, eigene Standards. Im nächsten Kapitel wird vor der Beschreibung der durchgeführten Implementationsarbeiten das Referenzmodell und die darin enthaltenen Interfaces erläutert. 3
1.2 Gliederung der Arbeit Kapitel 2 erläutert als Ausgangspunkt dieser Arbeit das Referenzmodell der WfMC und die darin enthaltenen Interfaces. Kapitel 3 beschreibt die konzeptionellen Arbeiten, die eingesetzten Technologien bei der Implementation sowie deren Einsatz im vorhanden WfM System. Kapitel 4 geht auf die Erweiterung des bestehenden WfM Systems um eine Datenbank ein. Dieses Kapitel kann separat von den anderen Kapiteln betrachtet werden. Kapitel 5 gibt eine Bewertung des verwendeten Standards und der geleisteten Arbeit ab. Desweiteren werden Vorschläge für Verbesserungen unterbreitet. 4
2 Referenzmodell der WfMC In diesem Kapitel wird das Referenzmodell der WfMC erläutert. Dazu wird im ersten Gliederungspunkt auf dessen theoretische Grundlage eingegangen und anschließend das Modell im Detail beschrieben. Die hier enthalten Informationen stützen sich größtenteils auf die Dokumentation des Referenzmodells der WfMC [17]. 2.1 Theoretische Grundlagen des Referenzmodells Workflow betrifft die Automatisierung von Geschäftsprozessen, in denen Aufgaben, Dokumente oder Informationen zwischen verschiedenen Teilnehmern nach vorher definierten Regeln weitergegeben werden, um ein bestimmtes Geschäftsziel zu erreichen. Ein WfM System bietet Funktionen an, mit deren Hilfe Workflows definiert, verwaltet und ausgeführt werden können. Letzteres geschieht unter der automatisierten Einbeziehung sowohl menschlicher als auch anderer Ressourcen. Vorhandene Systeme unterscheiden sich in einer großen Anzahl von Eigenschaften. So sind sie zum Beispiel auf die Abarbeitung spezieller Geschäftsprozesse spezialisiert, deren Bearbeitungszeit einige Minuten bis hin zu mehreren Monaten betragen kann, abhängig von der Komplexität und der Dauer einzelner enthaltener Aktivitäten. Desweiteren gibt es Unterschiede im Umfang der benötigten Ressourcen in Form von Arbeitsmitteln oder Mitarbeitern. Ein System, welches mehr als einen Mitarbeiter und geteilte Ressourcen zwischen Mitarbeitern unterstützt, ist komplexer als eines, welches nur einen Mitarbeiter mit einer Ressource vorsieht. Dementsprechend gibt es eine große Zahl an Variationen in der Architektur solcher Systeme. So reicht zum Beispiel der Bereich der Kommunikationsstruktur von einer kleinen lokalen Arbeitsgruppe bis hin zu einer unternehmensübergreifenden. Auch gibt es Unterschiede in der Einbeziehung externer Anwendungen. Für die Erstellung des Referenzmodells wurden die verschiedenen Arten von Implementationstechniken betrachtet. Trotz der vorhandenen Variationen wurden gemeinsame Funktionsbereiche entdeckt, welche zum einen die Basis für das Referenzmodell und damit zum anderen die Basis für die Integrations- und Interoperabilitätsfähigkeiten der Produkte schaffen. Auf der höchsten Abstraktionsebene können die von WfM Systemen gebotenen Funktionen in drei Bereiche eingeteilt werden: 5
Build-time-Funktionen, um Workflows und die enthaltenen Aktivitäten zu definieren oder auch zu modellieren Run-time-Kontroll-Funktionen, um Workflows und die enthaltenen Aktivitäten zu verwalten Run-time-Interaktionen mit Mitarbeitern und mit anderen Anwendungen, um die einzelnen Aktivitäten eines Workflows abzuarbeiten Abbildung 1 (entnommen aus [17]) stellt die Funktionsgebiete grafisch dar. Abbildung 1: Die drei Funktionsgebiete eines WfM Systems Die Build-time-Funktionen dienen zur Erstellung einer Prozessdefinition in digitaler Form. Sie ermöglichen die Übersetzung der Definition von der realen Welt in eine vom Computer verständliche und verarbeitbare Form mit Hilfe von Analyse-, Modellierungs- und Definitionswerkzeugen. Eine Prozessdefinition besteht im Allgemeinen aus einzelnen Aktivitäten, wobei jede Aktivität mit Mitarbeitern oder Anwendungen assoziiert ist, welche für die Abarbeitung verantwortlich sind. Desweiteren enthält sie Regeln, die die Reihenfolge der Abarbeitung der einzelnen Aktivitäten vorschreibt. Eine Defini- 6
tion kann textuell, formal oder auch grafisch ausgedrückt werden. Bei einigen WfM Systemen ist es möglich, dass aufbauend auf einer Prozessdefinition zur Laufzeit dynamische Änderungen an ihr vorgenommen werden, um sie äußeren Gegebenheiten anzupassen. Für die Phase der Definitionserstellung werden von der WfMC keine Standards vorgeschlagen, da dieses als ein wichtiger Bereich vorgesehen ist, indem sich die Produkte am Markt unterscheiden und positionieren können. Zur Laufzeit wird die Prozessdefinition durch die Workflowmanagement- Kontroll-Software interpretiert. Diese Softwarekomponente wird als Workflow- Engine bezeichnet. Sie stellt die Run-time-Kontroll-Funktionen zur Verfügung. Anhand der Prozessdefinition legt die Engine einen Ablaufplan für die einzelnen Aktivitäten eines Workflows fest und involviert dementsprechend Workflowteilnehmer und externe Anwendungen. Auf diese Art und Weise wird eine Verbindung zwischen dem Workflow als Modell aus der Prozessdefinition und dem Workflow aus der realen Welt geschaffen, wiedergegeben durch die Interaktionen mit Workflowteilnehmern und Anwendungen. Eine Workflow-Engine kann über mehrere Computer verteilt sein, um mit deren Hilfe Aufgaben bewältigen zu können, die über einen lokalen Bereich hinaus gehen. In Abbildung 1 ist der Workflow-Enactment-Service als Komponente für den Bereich der Run-time-Kontroll-Funktionen dargestellt. Dieser Service kapselt eine oder mehrere Workflow-Engines. Während die Engines für die Ablaufsteuerung eines Workflows zuständig sind, widmet sich der Enactment-Service der Erzeugung, Ausführung und allgemeinen Verwaltung. In der verwendeten Literatur überschneiden sich die Aufgabenbereiche von Engine und Enactment-Service allerdings teilweise oder werden widersprüchlich definiert. Während die Run-time-Kontroll-Funktionen lediglich Auskunft geben, zu welchem Zeitpunkt externe Ressourcen benötigt werden, stellen die Runtime-Interaktionen die eigentliche Verbindung des Workflow-Enactment- Service zur Außenwelt her. Sie dienen zur Kommunikation des Service zum einem mit Workflowteilnehmern (im Sinne der User-Interfaces) und zum anderen mit externen Anwendungen. So geben sie dem Teilnehmer die Möglichkeit, zum Beispiel den Status einzelner Aktivitäten abzufragen und festzulegen, andere Anwendungen einzubeziehen oder Daten einzufügen. Bezüglich externer Anwendungen können zum Beispiel aufgrund von Änderungen an prozessrelevanten Daten Updates oder Anfragen an einer Datenbank durch- 7
geführt werden. Die Verwendung von Standards schafft an dieser Stelle viele Vorteile. Durch sie ist es möglich ein einheitliches Interface für Workflow- Software verschiedener Hersteller durchzusetzen. So können Anwendungen entwickelt werden, welche mit mehreren verschiedenen WfM Systemen kooperieren können. Eine alternative Veranschaulichung auf die Workflowarchitektur gibt die Top-Level-Sicht wieder, in welcher die Verteilung der einzelnen Aktivitäten eines Workflows über mehrere Workflowteilnehmer erkennbar wird. Wie schon in Kapitel 1.1 erwähnt, ist die Ausdehnung des Bereichs, in dem die Verteilung stattfindet, ein wesentliches Unterscheidungsmerkmal vorhandener WfM Systeme. Die Verteilung der Aktivitäten kann je nach Komplexität des Workflows innerhalb einer Arbeitsgruppe, aber auch unternehmsübergreifend geschehen. Abbildung 2 (entnommen aus [17]) gibt die Top-Level Sicht wieder. Abbildung 2: Top-Level Sicht der Workflowarchitektur Im Zentrum dieser Abbildung steht der Workflow, welcher die einzelnen Aktivitäten enthält. Es steht die Möglichkeit zur Verfügung, dass die Aktivitäten durch unterschiedliche Workflow-Engine kontrolliert werden, da man auf die spezialisterten Fähigkeiten der verschiedenen Produkte angewiesen ist. So könnten die Aktivitäten eins, vier und fünf von einem WfM System und Aktivitäten zwei und drei von einem anderem System ausgeführt werden. Alle Engines sind im Workflow-Enactment-Service enthalten, der Interfaces 8
bereitstellt, über die mit den Workflowteilnehmern und externen Anwendungen kommuniziert werden kann. Standards, die den Transfer der Workflowkontrolle zwischen verschiedenen Engines und auch anderen Softwarekomponenten eines WfM Systems wie Monitoring-Tools oder User-Interfaces unterstützen, ermöglichen die Entwicklung von Workflowanwendungen, in der Teile von verschiedenen Workflowprodukten zusammengefasst sind, die aber zusammen wie eine logische Entität arbeiten. Zu diesem Zweck hat die WfMC Standards für die folgenden fünf Interfaces entworfen: Spezifikation für die Prozessdefinition und deren Austausch Interfaces, welche die Interoperabilität zwischen verschiedenen Workflow- Engines ermöglichen Interfaces, um die Interaktion mit einer Reihe von externen Anwendungstypen zu unterstützen Interfaces, um die Interaktion mit dem Workflowteilnehmer zu unterstützen Interfaces für die Systemüberwachung Die genauere Umsetzung dieser Interfaces ist im nächsten Gliederungspunkt in der Beschreibung des Referenzmodells der WfMC enthalten. 2.2 Beschreibung des Referenzmodells Das Referenzmodell beschreibt ein verallgemeinertes Modell [12] für die Konstruktion von WfM Systemen in Form von Komponenten und zeigt auf, wie es in Beziehung zu anderen verschiedenen Implementationsansätzen gestellt werden kann. Es macht hingegen keinerlei Aussagen über den internen Aufbau der einzelnen Komponenten. Da die Form der Realisierung den einzelnen Herstellern selbst überlassen bleiben soll, erübrigt sich auch die Notwendigkeit, die einzelnen Komponenten eines WfM Systems an sich zu beschreiben. Den Ausgangspunkt für die Entwicklung des Referenzmodells bildet eine allgemeine Struktur von WfM Systemen, in der die einzelnen Interfaces zwischen den Komponenten in der Struktur ermittelt und bestimmt 9
wurden. Es wurde erkannt, dass alle Workflowprodukte eine Zahl dieser allgemeinen Komponenten enthalten, welche auf eine proprietäre Art miteinander kommunizieren. Es sei allerdings angemerkt, dass sich die Fähigkeiten und Komplexität der einzelnen Komponenten von Produkt zu Produkt stark unterscheiden. Um Interoperabilität zwischen Workflowprodukten zu gewährleisten, werden Interfaces und Datenaustauschformate zwischen diesen allgemeinen Komponenten benötigt. Dieser Bedarf wird durch die WfMC aufbauend auf dem Referenzmodell gedeckt. Abbildung 3 (entnommen aus [17]) stellt das Modell dar. Abbildung 3: Referenzmodell der WfMC Diese Architektur spiegelt die allgemeinen Komponenten eines WfM Systems wieder. Im Zentrum steht dabei der Workflow-Enactment-Service, welcher eine oder auch mehrere Workflow-Engines kapselt. Über das Workflow- Application-Programming-Interface (WAPI) [18] ist er befähigt, mit der Außenwelt zu kommunizieren. Das Modell enthält neben dem Workflow-Enactment-Service fünf weitere Komponenten, mit denen der Service über die entsprechenden Interfaces kommunizieren kann. Es ist angedacht, dass die einzelnen Interfaces zunächst als ein allgemeines Interface in der WAPI entwickelt und jeweils mit den benötigten Parametern erweitert werden, um die Anforderung der Kommunikation der einzelnen Komponenten zu bewältigen. Durch diese Vorgehensweise erlangt das WAPI eine konsistentere Sicht auf die einzelnen Komponenten, was wiederum in einem vereinfachten Aufbau 10
der WAPI resultiert. In den folgenden Gliederungspunkten wird auf die einzelnen Bestandteile des Referenzmodells inklusive der entsprechenden Interfaces etwas detaillierter eingegangen. 2.2.1 Workflow-Enactment-Service Der Workflow-Enactment-Service stellt Run-time-Funktionen zur Verfügung, mit denen Workflows erstellt, verwaltet und ausgeführt werden können. Dazu verwendet der Service eine oder mehrere Workflow-Engines, deren Aufgabe es ist, die an den Service erteilten Funktionsaufrufe zu interpretieren (auszuführen). Der Zugriff auf die Funktionen des Services erfolgt über die WAPI. Aus Sicht des Referenzmodells dient der Workflow-Enactment-Service der logischen Trennung zwischen der Workflowkontrolllogik, die den Service an sich bildet und den Anwendungswerkzeugen mit denen die Abarbeitung der mit den einzelnen Aktivitäten eines Workflows verbundenen Aufgaben eingeleitet wird. Diese Separation stellt die Grundlage für einen möglichst allgemeinen Standard dar. Im Fall der Verwendung mehrere Workflow-Engines ist es möglich, das der Enactment-Service über mehrere Computer verteilt ist. Desweiteren wird zwischen homogenen und heterogenen Enactment-Services unterschieden. Beim ersteren werden ausschließlich kompatible Engines verwendet. Die Techniken zur Aufteilung der Workflowkontrolle und zur Kommunikation zwischen den Engines sind hier produktspezifisch und unterliegen keinen Standard. In einem heterogenen Enactment-Service hingegen können auch inkompatible Engines enthalten sein. Sie benötigen demzufolge einen Standard um ihre Aufgaben erfüllen zu können. Die WfMC unterbreitet für diesen Standard eine Spezifikation. 2.2.2 Workflow-Engine Die Workflow-Engine ist verantwortlich für die Ausführung der Run-time- Kontroll-Funktionen (siehe Kapitel 2.1) innerhalb des Workflow-Enactment- Service. Laut der WfMC ist diese Komponente für die folgenden Aufgaben zuständig: Interpretation der Prozessdefinition Kontrolle einzelner Workflows, dazu zählt zum Beispiel: Erzeugen, Aktivieren, Stilllegen oder Beenden von Workflows 11
Navigation zwischen Workflowaktivitäten, bei denen unter Umständen parallel laufende Operationen durchzuführen sind, Planung von Deadlines Anmelden und Abmelden von Teilnehmern Anzeigen von Arbeitsmitteln für den Teilnehmer und Bereitstellung eines Interfaces, um die Interaktion mit Teilnehmern zu unterstützen Pflege von Workflow-Kontroll-Daten, prozessrelevanten Daten, Übertragung der prozessrelevanten Daten zum/vom Teilnehmer oder zur/von der externen Anwendung Bereitstellung eines Interfaces, um externe Anwendungen einzubeziehen und Daten mit ihnen auszutauschen Überwachen von Aktionen zu Kontroll-, Verwaltungs- und Monitoringzwecken Eine Workflow-Engine kann diese Aufgaben mit einer beliebigen Menge von Workflowinstanzen durchführen. Im Fall, dass mehrere Engines im Workflow-Enactment-Service enthalten sind, existieren zwei unterschiedliche Varianten der Verteilung der Workflowinstanzen und deren Aufgaben auf die Engines. Je nach Anwendungsszenario kann eine Engine jeweils für einen gewissen Typ von Workflows oder für eine Teilmenge der oben genannten Aufgaben aller Workflowinstanzen zuständig sein. Wie im Referenzmodell steht die Workflow-Engine auch im Zentrum der vorliegenden Arbeit. 2.2.3 Process-Definition-Tools Es existiert eine Menge von verschiedenen Produkten auf dem Markt, mit denen Prozessdefinitionen erstellt werden können. Der Charakter von Prozessdefinitionen wird stark durch die Eigenschaften der jeweiligen Process- Definition-Tools geprägt. In der Praxis wird von den meisten WfM Systemen bereits ein eigenes Process-Definition-Tool zur Verfügung gestellt. Daraus ergeben sich zwei Folgerungen: Zum einen wird eine erstellte Definition oftmals nur systemintern gehalten, der Anwender bekommt also nie eine Datei oder ähnliches zu Gesicht, in der die Definition enthalten ist. Zum anderen wird für die Definition ein proprietäres Format verwendet, welches lediglich von der Workflow-Engine des eigenen Systems interpretiert werden kann. Für den Fall der Verwendung separater Produkte zur Prozessdefinition werden die Definitionen zwischen den Produkten per Datei transferiert oder es wird ein 12
Repository eingesetzt, auf welches die Produkte zugreifen können. Hier muss festgelegt werden, inwiefern Daten zwischen den Komponenten ausgetauscht werden können. Zudem wird ein Standard für ein Format benötigt, welches vom Process-Definition-Tool und der Engine verstanden wird. Im Interface 1 des Referenzmodells wird auf diese beiden Punkte eingegangen. Es dient zum Exportieren und Importieren von Prozessdefinitionen zwischen der Engine und dem Process-Definition-Tool. Dazu beinhaltet es entsprechend den Anforderungen zum einen die Definition für das Austauschformat und zum anderen die API-Funktionen zum eigentlichen Importieren und Exportieren. Mit deren Hilfe können komplette oder teilweise Prozessdefinitionen über verschiedene physische oder logische Medien ausgetauscht werden. Abbildung 4 (entnommen aus [17]) verdeutlicht noch einmal das Austauschschema. Abbildung 4: Austausch von Prozessdefinitionen Zu erkennen sind das Process-Definition-Tool und der Workflow-Enactment-Service, zwischen denen die Process-Definition ausgetauscht werden soll. Das Festlegen von Standards für dieses Interface garantiert zwei wesentliche Vorteile. Zum einen schafft es eine exakte logische Trennung zwischen den Build-time Funktionen und den Run-time-Funktionen, wodurch die Ausgabe eines Process-Definitions-Tool als Eingabe für verschiedene Engines verwendet werden kann. Dies ermöglicht die freie unabhängige Wahl der Definitions- Tools und der Engines. Auf der anderen Seite wird vorrangig auf Basis eines 13
einheitlichen Austauschformates das Potential geschaffen, dass mehrere Engines eine einzige Prozessdefinition als Eingabe verwenden und den Workflow in Kooperation in einem verteilten Workflow-Enactment-Service verwalten. Die Arbeit der WfMC zur Entwicklung von Standards für dieses Interface stützt sich dementsprechend auf zwei Aspekte. Erstens wird ein so genanntes Metamodell entworfen, welches Objekttypen, ihre Beziehungen und Attribute innerhalb einer Prozessdefinition beschreibt und damit den Grundstein für ein Austauschformat legt. Zweitens werden API-Funktionen definiert, um Austauschaktionen in die Wege zu leiten. Dazu werden zum einen API-Funktionen innerhalb des WAPI zum Austausch von Prozessdefinitionen zwischen verschiedenen Workflow-Engines benötigt und zum anderen API-Funktionen zum Austausch zwischen Process-Definition-Tools und einem Enactment-Service. Der Zugriff über solche Funktionen kann lesend, schreibend oder beides zugleich sein. Es ist ebenfalls möglich, dass nicht eine komplette Definition ausgetauscht wird, sondern dass einzelne Objekte innerhalb der Definition gelesen oder verändert werden. Im folgenden Abschnitt wird das Metamodell für die Prozessdefinition etwas näher erläutert. Das Metamodell beschreibt eine Gruppe von Objekttypen mit denen sich relativ einfache Prozessdefinitionen erstellen lassen. Um verschiedenen Szenarios in Unternehmen nachzukommen, lassen sich weitere Objekte hinzufügen, die auf die speziellen Anforderungen mit zusätzlicher Funktionalität ausgerichtet sind. Abbildung 5 (entnommen aus [17]) verbildlicht das Metamodell. Abbildung 5: Metamodell zur Prozessdefinition 14
Zu erkennen sind hierbei die verschiedenen Objekttypen und ihre Beziehungen zueinander. Mit der Workflow-Type-Definition lassen sich Informationen wie Name oder Version zum Workflow an sich angeben. Dem Workflow können Aktivitäten zugeordnet werden, welche wiederum auf benötigte Rollen, Daten, externen Anwendungen und Überführungskonditionen verweist. Für genauere Spezifikationen wird auf [17] verwiesen. 2.2.4 Workflow-Client-Applikationen Die Workflow-Client-Applikationen dienen der Interaktion mit den Workflowteilnehmern. Mit ihnen können die einzelnen Aktivitäten eines Workflows bearbeitet und verwaltet werden. Abbildung 6 (entnommen aus [17]) spiegelt die Beziehung der Workflow-Client-Applikationen zum Workflow-Enactment- Service über das Interface 2 des Referenzmodells wieder. Abbildung 6: Beziehung zwischen Workflow-Client-Applikationen und Workflow-Enactment-Service Eine tragende Rolle in der Interaktion mit dem Workflowteilnehmer spielen die Funktionen des Worklist-Handlers. Der Worklist-Handler ist ein kleines Softwaremodul, welches mit dem Workflowteilnehmer für solche Aktivitäten in Kommunikation tritt, bei denen menschliche Ressourcen benötigt 15
werden. Über die Client-Applikationen kann der Teilnehmer die gebotenen Aktivitäten starten, beenden, löschen, neue Aktivitäten hinzufügen und so weiter. Dementsprechend bedarf es einer Funktionsbreite für das Interface zwischen den Workflow-Client-Applikationen und dem Workflow-Enactment- Service, um die vom Teilnehmer durchgeführten Aktionen weiterzureichen. Desweiteren müssen Funktionen für die Einbeziehung externen Anwendungen vorgesehen werden. Für den Fall, dass exakt getypte Daten von Anwendungen verarbeitet werden sollen, könnte der Worklist-Handlers selbst die nötige Assoziation zwischen Daten und Anwendung herstellen und diese dem Workflow-Enactment-Service mitteilen. Andernfalls muss der Workflowteilnehmer über die Client-Application diese Informationen zur Verfügung stellen. Hierfür werden weitere Funktionen für das Interface benötigt. Die folgende Liste gibt Funktionen an, die das Interface zwischen den Workflow-Client-Applikationen und dem Workflow-Enactment-Service infolge der genannten Anforderungen unterstützen muss: Prozess- und Aktivitätskennzeichnungen Ressourcennamen und -adressen, zum Beispiel von externen Anwendungen Referenzen auf Daten und Datenstrukturen alternative Kommunikationsmethoden Um diesen Funktionsanforderungen nachzukommen, bedarf es eines toleranten und erweiterbaren Interface. Hierfür wurde von der WfMC das Workflow-Application-Programming-Interface (WAPI) entwickelt, welches auf eine konsistente Art und Weise angesprochen werden kann und unabhängig von der dahinterstehenden Produktimplementation ist. Im folgenden werden kurz die Funktionsbereiche der WAPI zur Kommunikation mit den Client-Applikationen genannt. Session-Verbindungen Aufbau und Abbau von Sessions zwischen teilnehmenden Systemen Prozessdefinitions-Funktionen Funktionen zum Auffinden und Abfragen von Objekten und Attributen in Prozessdefinitionen 16
Prozess-Kontroll-Funktionen Erstellen, Starten und Beenden von einzelnen Workflows Stilllegen, Wiederaufnehmen von Workflows Status von Workflows oder Aktivitäten ändern Zuweisung eines Attributes zu Workflows oder Aktivitäten Prozess-Status-Funktionen Öffnen, Schließen einer Anfrage an Workflows oder Aktivitäten, Setzen von Filtern Abrufen von (gefilterten) Details von Workflows oder Aktivitäten Worklist/Workitem-Handling-Funktionen Öffnen, Schließen einer Anfrage zur Worklist, Setzen von Filtern Abrufen von (gefilterten) Aktivitäten aus der Worklist Benachrichtigung über die Annahme, Übertragung, Vervollständigung von Aktivitäten Abfragen von Attributen der Workitems Prozess-Überwachungs-Funktionen (diese Funktionen sind Workflowteilnehmern mit besonderen Privilegien vorbehalten) Betriebsbereitschaft von Prozessdefinitionen und deren Instanzen (Workflows) ändern Status von allen Workflows und Aktivitäten eines bestimmten Typs ändern Zuordnen von Attributen zu allen Workflows und Aktivitäten eines bestimmten Typs Alle Workflows beenden Data-Handling-Funktionen Abfragen und Setzen von workflowrelevanten Daten 2.2.5 Involvierte Anwendungen Neben den Workflowteilnehmern sind involvierte externe Anwendungen ebenfalls in der Lage, Aktivitäten zu bearbeiten, prozessrelevante Daten zu manipulieren und externe Ereignisse auszulösen. Im allgemeinen ist es nicht erforderlich, dass ein WfM Produkt die nötige Logik besitzt, um mit allen vorhandenen Anwendungen in einem heterogenen System kommunizieren zu 17
können. Es würde bedeuten, dass ein Produkt befähigt sein müsste, mit allen potentiellen Anwendungen plattformübergreifend über ein Netzwerk und einem bestimmten Austauschformat arbeiten zu können. So ist es heutzutage Stand der Dinge, dass WfM Produkte nur mit einer gewissen Anzahl externer Anwendungen kommunizieren können. Im Fall genau getypter Prozessdaten kann der Enactment-Service eine eindeutige Assoziation zu externen Anwendungen herstellen. Ansonsten ist es möglich, einen so genannten Application-Agent zu verwenden, welcher anhand einer Kombination aus zu verarbeitenden Daten und internen Zuständen die richtige Anwendung aufruft. Er ist auch zuständig, je nach Anwendung die entsprechenden Kommunikationsmethoden zu wählen. Eine wesentliche Erleichterung stellt die Verwendung Workflow-befähigter Anwendungen dar. Sie besitzen bereits ein Interface, auf das der Workflow-Enactment-Service direkt, ohne Verwendung des Application-Agents, zugreifen kann. Auch hier ist die Einführung eines standardisierten Interfaces die Grundlage für eine einheitliche Kooperation. Die WfMC hat hierfür das Interface 3 aus dem Referenzmodell entworfen und in verschiedene Kategorien unterteilt um in weiterer Arbeit für jede Kategorie konkrete Spezifikationen zu entwickeln. Tabelle 1 (entnommen aus [17]) listet die einzelnen Kategorien auf: Interface-Type Zugriff auf Daten Standard sinnvoll Lokaler Programmaufruf Lokale Datei nein Shell Script Lokale Datei nein ORB Aufruf Referenz ja Remote Call Referenz ja Message Passing (X.400) Referenz oder in Nachricht ja Transaktion (OSI-TP) Referenz oder in Nachricht ja Tabelle 1: Kategorisierung von Interface 3 Derzeit ist die WfMC noch damit beschäftigt, den vollen Funktionsumfang dieses Interfaces abzuschätzen und dementsprechend Interface Typen mit entsprechenden APIs festzulegen. Abbildung 7 stellt noch einmal den Funktionsbereich von Interface 3 grafisch dar. Wie man erkennen kann, ist dieses Interface für die Verwendung eines Application-Agent oder auch für die direkte Kommunikation mit externen Anwendungen vorgesehen. 18
Abbildung 7: Funktionsbereiche von Interface 3 Im einfachsten Fall wird die direkte Kommunikation des Workflow-Enactment-Service mit den Anwendungen genutzt. Dabei wird anhand der Prozessdefinition erkannt, welcher Typ von Aktivität bearbeitet werden soll und welche Anwendungen dazu nötig sind. Die Anwendung kann auf dem selben Computer oder irgendwo anders im Netzwerk lokalisiert sein. Die Informationen zur genauen Adressierung leitet die Workflow-Engine direkt von der eingesetzten Anwendung ab. In dem hier genannten Fall sind diese Informationen lokal bei der Engine gespeichert. Die detaillierte Semantik und Syntax für Interface 3 befindet sich zur Zeit ebenfalls noch in Bearbeitung. Die folgende Liste zeigt eine Reihe von bereits konzeptionierten Befehlen. Session-Verbindungen Aufbau und Abbau von Sessions zwischen teilnehmenden Systemen Aktivitäts-Management-Funktionen (von der Engine zur Anwendung) Aktivität starten Aktivität stilllegen, wiederaufnehmen, abbrechen (von der Anwendung zur Engine) 19
Benachrichtigung über Beendigung einer Aktivität Senden von Signalen (z.b. zur Synchronisation) Senden von Warteschlangeninformationen Daten-Management-Funktionen Austausch von Prozessdaten (unbearbeitet zur Anwendung, bearbeitet zur Engine) Austausch von Anwendungsdaten Komplexere Szenarien, in denen mehrere Engines eines Workflows Aktivitäten kontrollieren und ebenfalls externe Anwendungen einbeziehen, benötigen unter Umständen weitere Mechanismen, um Anwendungsinformationen unter den Engines auszustauschen. 2.2.6 Interoperabilität Auf das Thema der Interoperabilität legt die WfMC einen besonders Schwerpunkt. Hier sollen Standards den Einsatz von heterogenen Workflow-Enactment-Services (siehe 2.2.1) ermöglichen. In dieser Art Enactment-Service kommen Engines verschiedener Hersteller zum Einsatz, die gemeinsam eine Reihe von Workflows kontrollieren. Mit der Entwicklung des Interface 4 hat es sich die WfMC zur Aufgabe gemacht, die Interoperabilität der Engines untereinander zu gewährleisten. Dabei ist die WfMC bestrebt die Hersteller von WfM Produkten nicht dazu drängen, Ansprüche der Anwender zu vernachlässigen, nur um Interoperabilität mit anderen Produkten zu unterstützen. Dazu konzentriert sich die WfMC auf eine Anzahl von Interoperabiliäts-Szenarios, welche jeweils auf unterschiedlichen Levels der Zusammenarbeit, angefangen vom Austausch einzelner Aktivitäten bis hin zum Austausch von ganzen Prozessdefinitionen, von Prozessdaten und sogar von Look and Feel Präferenzen, stattfinden. Insgesamt wurden 4 Szenarios mit unterschiedlicher Befähigung zur Interoperabilität definiert. Sie werden im folgendem kurz beschrieben. Szenario 1: Verkettete Prozesse Dieses Szenario definiert einen Verbindungspunkt in einem Prozess A, um sich mit einem Prozess B zu verbinden. Über diesen Verbindungspunkt können sich die einzelnen Prozesse der Engines innerhalb des Enactment-Service aneinander ketten um nach außen hin als ein Prozess zu wirken. Dabei muss 20
sich der Verbindungspunkt nicht wie in Abbildung 8 jeweils am Anfang bzw. Ende der Prozesse befinden, sondern kann überall dort platziert werden, wo es sinnvoll erscheint. Abbildung 8: Szenario 1 von Interface 4 Die dahinter liegende Technik unterstützt den Transfer einer Aktivität von Prozess A zu Prozess B, wo die transferierte Aktivität dann unabhängig und ohne Synchronisation weiter ausgeführt werden kann. Als Kommunikationsmechanismus genügt hier eine allgemeine API, die von den jeweiligen Engines unterstützt wird. Szenario 2: Verschachtelte Prozesse Hierbei wird ein Prozess B gekapselt als eine einzelne Aktivität in Prozess A ausgeführt. Dadurch kann eine hierarchische Beziehung zwischen Prozessen mit beliebiger Verschachtelungstiefe aufgebaut werden. Abbildung 9: Szenario 2 von Interface 4 In Abbildung 9 wird die Aktivität A3 von Prozess A als Prozess B ausgeführt. Wurde Prozess B fertig gestellt, gilt auch Aktivität A3 als beendet. Wie auch in Szenario 1 könnte dieses Level der Interoperabilität durch Gebrauch einer allgemeinen API gewährleistet werden. 21
Szenario 3: Zusammengesetzte Prozesse In diesen Szenario ist die Komposition von Prozessen aus Aktivitäten anderer Prozesse möglich. Die Abarbeitung solcher Prozesse von einer Aktivität zur nächsten geschieht völlig transparent, ohne das es besondere administrativer Anstrengung bedarf. Abbildung 10: Szenario 3 von Interface 4 Abbildung 10 zeigt einen Prozess C welcher durch Prozesse von Engine A und Engine B zusammengesetzt wurde. So sind Aktivitäten C1, C2 und C5 von Engine A, während Aktivitäten C3, C4 und C6 von Engine B stammen. Im Gegensatz zu den vorherigen Szenarios wird neben einer allgemeinen API noch ein Mechanismus benötigt, der es erlaubt, dass eine Prozessdefinition von beiden Engines gleich interpretiert werden kann. Entweder wird die Definition vor Ausführung des Prozesses von den Engines importiert oder sie wird zur Laufzeit des Prozesses ausgetauscht. Szenario 4: Parallele synchronisierte Prozesse Diese Szenario ist für Prozesse bestimmt, welche absolut unabhängig ausgeführt werden, sich aber zu bestimmten Zeitpunkten mit Hilfe von Synchronisationspunkten synchronisieren müssen. Die Synchronisation wird umgesetzt, indem ein Prozess beim Erreichen solch eines vordefinierten Punktes in seiner Abarbeitung ein bestimmtes Signal aussendet, bzw. auf ein bestimmtes 22
Signal wartet. In Abbildung 11 ist ein Synchronisationsbeispiel aufgeführt. Abbildung 11: Szenario 4 von Interface 4 In diesem Beispiel synchronisieren sich die Prozesse, wenn Prozess A bei Aktivität A3 und Prozess B bei Aktivität B4 angelangt ist. Als Schlussfolgerung aus den genannten 4 Szenarios werden 2 große Funktionsbereiche für das Interface 4 benötigt. Zum einen Funktionen, welche eine einheitliche Interpretation und den Austausch von Prozessdefinitionen ermöglichen und zum anderen Funktionen, um zur Laufzeit Kontrollinformationen und prozessrelevante Daten auszutauschen. Die folgende Liste führt die Funktionen etwas detaillierter auf: Funktionen für Session-Verbindungen Operationen zum Verarbeitung von Prozessdefinitionen und deren Objekten Prozesskontroll- und Statusfunktionen Funktionen zur Verwaltung von Aktivitäten Funktionen zur Verarbeitung von Prozessdaten Hierbei fallen Ähnlichkeiten zu den Anforderungen der zuvor behandelten Interfaces auf. Bei der in Kapitel 3 erläuterten Umsetzung der Interfaces des Referenzmodells in konkrete Implementationen werden diese Ähnlichkeiten zur Entwicklung einer einheitlichen API ausgenutzt. 2.2.7 Administration und Überwachung Der letzte große Arbeitsbereich der WfMC widmet sich der Thematik der Administration und Überwachung in WfM Systemen. Das hierfür entwickel- 23
te Interface 5 soll die Möglichkeit bieten, dass sich mit einer Verwaltungsanwendung eine Anzahl verschiedener Engines administrieren und überwachen lassen. Abbildung 12 zeigt solch eine unabhängige Verwaltungsanwendung, welche über das Interface 5 mit verschiedenen Engines agiert. Abbildung 12: Funktionsbereiche von Interface 5 Es wäre natürlich auch denkbar, dass eine Verwaltungsanwendung fester Bestandteil eines Enactment-Services ist, aber trotzdem die Fähigkeit besitzt, weitere Engines zu verwalten. Die folgende Liste gibt einen Überblick über die im Interface 5 gebotenen Funktionen: Nutzer-Verwaltung Einrichten, Löschen, Sperren, Rechteverwaltung von Workflowteilnehmern Rollen-Verwaltung Einrichten, Löschen von Rollen Zuweisen von Workflowteilnehmern zu Rollen Festlegen von Rollenattributen Log-Verwaltung Log anlegen, ausgeben, löschen Austausch von Anwendungsdaten Ressourcen-Verwaltung Ausführungsfolge von Prozessen und Aktivitäten festlegen 24
Abfragen von Kontroll-Daten Process-Verwaltung Status aller Instanzen einer Prozessdefinition ändern Aktivieren oder Deaktivieren der Instantiierung von bestimmten Versionen einer Prozessdefinition 25
3 Implementation In diesem Kapitel werden die Implementationsarbeiten zur Anpassung des vorhandenen WfM Systems an das Referenzmodell der WfMC aufgeführt. Die Anpassung sollte so vollzogen werden, dass die vom Modell geforderte Funktionalität dem vorhandenen WfM Systems zugefügt wird, auf der anderen Seite aber bestehende Funktionen des Systems nicht verloren gehen. Den Anfang der Implementationsarbeiten bildete aufbauend auf dem bestehenden WfM System von Björn Zieger die Wahl einer geeigneten konkreten Spezifikation der im Referenzmodell enthaltenen Interfaces. Die dabei erlangten Resultate werden nach einer kurzen Beschreibung des vorhandenen WfM Systems erläutert. 3.1 Aufbau und Funktionsweise des vorhandenen WfM Systems Das vorhandene WfM System entstand im Rahmen eines Projektes, wobei es prototypisch durch ein fünfköpfiges Team in Java entworfen wurde. Da dieses Team nach eigener Aussage [1] keine theoretischen Kenntnisse über WfM Systeme besaß, wurden auf bestehende Techniken und Architekturen in diesem Bereich verzichtet. Aufbauend auf den erzielten Ergebnissen wurde die Diplomarbeit von Björn Zieger durchgeführt, in der schon zum Teil versucht wurde, einige Standards zur Terminologie der verwendeten Begriffe und zur Architektur einzubringen. Für diese Arbeit stand somit Software zur Verfügung, dessen Quelltext man als historisch gewachsen bezeichnen könnte, denn ein dahinterstehenden Konzept sowie eine einheitliche Architektur waren nicht mehr zu erkennen. Abbildung 13 spiegelt in etwa die entstandene Architektur wieder. Wie in der Abbildung zu erkennen, enthält die Architektur bereits drei Komponenten des Referenzmodells: die Workflow-Engine, die User-Application und ein Process-Definition-Tool. Die User-Application ist hierbei als Servlet mit JSP s implementiert und stellt neben dem Verwalten der Worklist auch Funktionen einer Verwaltungsanwendung (siehe Kapitel 2.2.7) zur Verfügung. Dazu gehört das Verwalten der Workflowteilnehmer, der Rollen, der laufenden Workflows, der Prozessdefinitionen und der Arbeitsmittel. Desweiteren enthält sie eine einfache Funktion zum Anzeigen der Auslastung 26
Abbildung 13: Architektur des vorhandenen WfM Systems von Arbeitsmitteln. In der Workflow-Engine ist bereits ein großer Teil der im Referenzmodell geforderten Funktionen (siehe Kapitel 2.2.2) enthalten. Es fehlen lediglich Möglichkeiten zum Verwalten prozessrelevanter Daten, zum Einbeziehen externer Anwendungen und zur Kommunikation mit anderen Engines. Zur persistenten Datenhaltung werden XML-Dateien verwendet, welche im Dateisystem der Engine abgelegt sind. Die zu Grunde liegenden XML-Schemata sind in [1] aufgeführt. Beide Komponenten, Engine und User- Application, sind physisch als eine Java-Anwendung implementiert und auf einem Tomcat-Server untergebracht. Bei der Analyse des Quelltextes stellte sich heraus, dass Engine und User-Application aufgrund des Zugriffs auf gegenseitige Objekte nicht sauber voneinander getrennt sind. Das in der Diplomarbeit hinzugefügte Process-Definition-Tool ist eine eigenständige Java-Anwendung. Es bietet Funktionen zum grafischen Modellieren von Prozessdefinitionen, welche anschließend von der Workflow-Engine interpretiert werden können. Der Austausch einer Definition erfolgt ebenfalls über eine im lokalen System angelegte XML-Datei. 3.2 Wahl einer konkreten Spezifikation Im allgemeinen kann für die Realisierung der Zusammenarbeit von Anwendungen ein Application Programming Interface (API) zur Verfügung gestellt werden. Über diese API bietet eine Anwendung nach dem Client-Server- Prinzip ihre Dienstleistungen an, während eine andere Anwendung auf sie zugreift. Voraussetzung hierfür ist, dass die Anwendungen Kenntnis von der konkreten zu verwendenden API-Spezifikation besitzen. Genau solch eine konkrete API-Spezifikation bildet den Grundstein der in dieser Arbeit durch- 27