1 Einführung
Motivation
Zielsetzung
Inhalte
2 Workflow-Management
Geschichte
Workflow-Management
Workflow-Management-Systeme
3 JavaSpaces
Einführung
JavaSpaces-Technologie
Anwendungsentwicklung mit JavaSpaces
Vorteile der JavaSpaces-Technologie
4 Space-DrivenBean Container
JavaSpaces und J2EE
Space Driven Beans
Laufzeitumgebung für Space-Driven Beans
Aufbau des SDB-Containers
Implementierung der Use-Cases
Beispiel einer Space-Driven Bean: SpaceLoggerSDB
Alternative Implementierung des SDBContainers
5 Activity//Spaces WfMS
Einführung
Use-Cases
Aufbau
Implementierung
Regelbasierte Workflows
Als vor einem Jahr, gegen Ende meines Masterstudienganges, die Wahl des Themas für eine Masterarbeit aktuell wurde, war ich als Software-Entwickler bei einer Firma tätig, die eine seit mehr als 15 Jahren existierende Branchensoftware für Druckereien und Printmedien durch eine auf Java basierende Neuentwicklung ablösen wollte.
Kernbestandteil der neu zu entwickelnden ERP-Lösung sollte ein Workflow-Management-System (WfMS) bilden, welches die Arbeitsabläufe und das Zusammenspiel der einzelnen Teilkomponenten koordinieren sollte. Nach einer Evaluation verfügbarer kommerzieller und freier Systeme wurde beschlossen, ein eigenes Workflow-Management-System zu entwickeln. Bei dieser Entwicklung war ich vor allem in den Bereichen Anbindung bestehender und neuer Komponenten an das WfMS sowie in der Integration von bestehenden Standards, welche in diesem Bereich existieren, eingebunden.
Zusätzlich dazu besuchte ich während des Semesters eine Vorlesung, deren Thema die Modellierung von Geschäftsprozessen und deren Abbildung innerhalb von ERP-Systemen war. In der Vorlesung kam SAP R/3 in Verbindung mit dem ARIS-Toolset der Firma IDS Scheer zum Einsatz.
Bedingt durch meine Kenntnisse sowohl in der Modellierung von Geschäftsprozessen und deren Umsetzung als Workflows als auch der technischen Realisierung eines WfMS war mein Interesse für dieses Themengebiet geweckt und ich beschloss, tiefer in dieses einzusteigen. Diese Masterarbeit bot mir die ideale Möglichkeit hierfür.
Während meiner Tätigkeit als Entwickler konnte ich die komplexen Anforderungen an ein WfMS erfahren und ebenso die Probleme, die eine Umsetzung dieser bereiten. Bei den Recherchen zu dieser Masterarbeit mußte ich außerdem feststellen, daß die verfügbaren Systeme bereits ein hohes Maß an Funktionalität und Stabilität erreicht haben, so daß es aus meiner Sicht kaum noch einen Sinn macht, eine Eigenentwicklung in diesem Gebiet anzustreben. Vor allem Branchenriesen wie SAP, Oracle oder IBM haben inzwischen Systeme entwickelt, die kaum noch Ansatzpunkte für Verbesserungen oder Neuerungen bieten; aber auch im Open Source-Umfeld existieren Lösungen, die ausgereift genug sind, um innerhalb einer Produktiv-Umgebung eingesetzt werden zu können.
Dieser Umstand, aber auch mit Kommilitonen und Kollegen geführte Dialoge der Art: „Was machst du in deiner Masterarbeit?“ - „Ich entwickle ein Workflow-Management-System“ - „Ach, noch eines...“, überzeugten mich davon, daß die reine Neuentwicklung eines WfMS kaum zu interessanten und innovativen Erfahrungen führen würde, wie ich sie eigentlich im Rahmen der Masterarbeit erlangen möchte.
Daraus resultierte die Idee, einen völlig neuen Blickwinkel auf einerseits die technische Umsetzung eines Workflow-Management-Systems, andererseits auf dessen Arbeitsweise zu finden. Das Ergebnis daraus präsentiert nun diese Masterarbeit. In dieser Arbeit verwirklichte ich Ideen, die, obwohl in anderen Gebieten schon seit langer Zeit verfügbar und angewandt, im Bereich der WfMS gerade erst ansatzweise erprobt werden. Konkret sind dies die Implementierung eines WfMS als eine verteilte Anwendung und der Aufbruch der relativ starren Strukturen von Workflows durch den Einsatz regelbasierter Verarbeitung.
Diese Masterarbeit geht nicht auf Themen wie den im Moment allgemein verbreiteten Begriff Business Process Modelling (BPM) oder die Umsetzung von Geschäftsprozessen mittels Workflows ein. Auch werden die Anforderungen an ein WfMS nur soweit beschrieben, wie sie dem Verständnis dieser Arbeit dienen. Vielmehr geht es um die Idee der Realisierung eines WfMS als verteilte Anwendung und die Ersetzung fest definierter Workflows durch einen regelbasierten Ansatz.
Umgesetzt werden diese beiden Ziele durch zwei Technologien, die zwar oft ein Schattendasein führen, jedoch gerade in letzter Zeit immer wieder im Blickwinkel der Entwicklergemeinde auftauchen.
Der Aspekt des verteilten WfMS wird durch den Einsatz der schon 1999 von Sun Microsystems im Rahmen der Java Intelligent Network Architecture (Jini)[1] vorgestellten JavaSpaces API verwirklicht.
Die regelbasierte Definition von Workflows basiert auf den ebenfalls schon seit Jahren benutzten Konzepten von RuleEngines, die bisher vor allem im Finanzbereich eingesetzt wurden. Gerade in letzter Zeit gibt es hier aber sehr ausgereifte Implementierungen für die Anwendung in Java und immer stärkere Bestrebungen für eine Standardisierung, was der Java Specification Request 94 (JSR94)[2] beweist. Ein aktuelles Beispiel für diese Entwicklung ist die Integration der Rule-Engine Drools [3] in den wohl bekanntesten J2EE Application Server JBoss [4] (siehe auch [Tss05a-ol]).
Das zweiten Kapitel beschreibt kurz Workflow-Management und damit zusammenhängende Begriffe, sowie mögliche Architekturen für die Implementierung von Workflow-Management-System.
Das dritte Kapitel erläutert anschließend die Entstehung und das Konzept der JavaSpaces API, welches als Grundlage des entwickelten WfMS fungieren.
Das vierte Kapitel beschreibt die Idee und die Umsetzung einer Kombination der JavaSpaces API mit der Java 2 Enterprise Edition (J2EE)[5], die heute so ausgereift ist, das sie meist die erste Wahl für die Umsetzung von Unternehmensanwendungen ist und deshalb auch für die Plattform für die Entwicklung des WfMS bildet.
Das Ergebnis dieser Kombination ist eine auf Enterprise JavaBeans basierende Laufzeitumgebung, die sich an herkömmlichen EJB-Containern orientiert, die Idee von Message-DrivenBeans aufgreift und mittels JavaSpaces neu umsetzt.
Das letzen Kapitel schließlich erläutert die Umsetzung eines WfMS mit Hilfe des vorher genannten Containers. Hier erlaubt der Einsatz von JavaSpaces in Kombination mit einer J2EE-Architektur die Umsetzung einiger ungewöhnlicher Konzepte, die in dieser Form in der Entwicklung von Workflow-Management-Systemen noch kaum Anklang findet.
Neben der neuen Form der Implementierung einer Workflow-Engine wird auch eine alternative Möglichkeit der Definition und Bearbeitung der Workflows selbst beschrieben, welche es erlaubt, die bisher starren Abläufe von Workflows durch einen regelbasierten Ansatz aufzubrechen. Hierfür kommt die bereits genannte JSR 94 RuleEngine API in Verbindung mit der Open Source Rule-Engine Drools zum Einsatz.
Im Abstand von einigen Jahren tauchen im Bereich der Softwareentwicklung immer wieder neue Technologien auf, die die gesamte IT-Branche in Euphorie versetzen. Damit einher geht in der Regel eine wahre Flut von Innovationen und noch viel mehr von neuen Begriffen und Akronymen, sogenannten Buzzwords[6]. Eines der besten Beispiele dieses Phänomens stellen die um das Jahr 2002 populär gewordenen Web-Services[7] dar.
Heute, fast drei Jahre später, zeigen sich die ersten Anzeichen, daß Web-Services einen Stand erreicht haben, der einen produktiven Einsatz erlaubt. Dies zeigt sich vor allem auch daran, daß neue Technologien und Architekturen auf dem Markt erscheinen, die vollständig auf Web-Services basieren und nun eine neue Welle von Buzzwords und TLAs [8] lostreten.
Obenauf auf dieser Welle treiben im Moment vor allem Begriffe wie Service-Oriented-Architecture (SOA) oder Enterprise-Service-Bus (ESB). Im Umfeld dieser Themen tauchen auch wieder Begriffe wie Geschäftsprozessmodellierung, Business-Process-Reengineering oder Business-Process-/Workflow-Management auf, die jedoch in diesem Fall keine wirkliche Innovationen, sondern eher alter Wein in neuen Schläuchen sind.
Gerade das Workflow-Management ist keine Erfindung der letzten Zeit, sondern hatte bereits Anfang 1990 eine Hochphase hinter sich. Die Wurzeln des Workflow-Managements datieren sogar zurück auf die 70er Jahre des letzten Jahrhunderts. Der erste Versuch in Richtung einer Automatisierung von Geschäftsprozessen war Teil der office automation Prototypen, an denen bei Xerox PARC geforscht wurde. [Mue04-ol]
Ziel dieser Forschung war:
„to reduce the complexity of the user's interface to the [office information] system, control the flow of information, and enhance the overall efficiency of the
office.“ [EN80]
Das Design dieser Anwendungen begann Mitte der 70er Jahre, die Ideen der Prozessautomatisierung mit Hilfe der Informationstechnologie können jedoch bis ins Jahr 1968 zurückverfolgt werden, als Fritz Nordsieck schrieb:
„Think about [a] modern data processing [system]. [It] represents a perceptible process, that is [...] connected with the business process and accompanies - or even controls - this process during various segments." [Nor72]
Abbildung 1 und Abbildung 2 zeigen eine zeitliche Übersicht über Forschungsprojekte und kommerzielle Systeme im Bereich Workflow-Management.
Abbildung in dieser Leseprobe nicht enthalten
Workflow-Management ist ein Teilbereich der sogenannten Computer Supported Coooperative Work (CSCW), einem interdisziplinären Forschungsgebiet aus verschiedenen Wissenschaften wie zum Beispiel der Informatik, der Soziologie und den Organisationswissenschaften. CSCW beschäftigt sich mit der Zusammenarbeit von Arbeitsgruppen und den diese unterstützenden Informations- und Kommunikationstechnologien [Wiki05b-ol].
Workflow-Management stellt die technische Umsetzung des Geschäftsprozessmanagements dar (siehe Infobox „Business-Process-Management“).
Business-Process-Management Jakob Freud beschreibt in einem Artikel für BPM-Guide.de Business-Process-Management folgendermaßen:
„Das Geschäftprozessmanagement [Business-Process-Management] rückt den Kunden in den Mittelpunkt aller Betrachtungen. Dabei kann es sich um externe Kunden wie z.B. Konsumenten handeln, aber auch um interne wie z.B. die Produktion, die, auf ihre Einsatzstoffe wartend, ein Kunde der Beschaffung ist. Dementsprechend führt ein Geschäftsprozess immer zu der Erbingung einer Leistung, die für einen bestimmten Kunden gedacht ist. Damit diese Leistung erbracht werden kann, muss natürlich einiges getan werden. Dieses Vorgehen wird in Prozessschritten (und Aufgaben, Aktivitäten oder Funktionen) dargestellt. Ein Geschäftsprozess kann von mehreren Beteiligten (Personen, Abteilungen, Teams) durchgeführt werden, die nacheinander oder gleichzeitig die notwendigen Prozessschritte ausführen.
Mit Hilfe verschiedener Detaillierungsebenen (abhängig von der Methode bzw. dem Tool) kann man nun den dargestellten Geschäftsprozess verfeinern. Der höchstmögliche Detaillierungsgrad ist erreicht, wenn die benannten (elementaren) Prozessschritte bzw. Aktivitäten/Aufgaben/Funktionen von einem Mitarbeiter an einem Arbeitsplatz ausgeführt werden können.
Die sog. Kerngeschäftsprozesse sind zentral und wettbewerbskritisch (Produktion, Distribution etc.), während die sog. Unterstützungsprozesse (Kostenrechnung, Personalwirtschaft etc.) keinen direkten Beitrag zur Wertschöpfung leisten.“ [Fre05-ol]
Ziele des Workflow-Managements
Heute übernehmen Workflow-Management-Systeme zunehmend eine aktive Rolle in Planung, Steuerung und Analyse von Geschäftsprozessen. Die Ziele des Workflow-Managements lassen sich somit aus dem Hauptziel des Geschäftsprozessmanagements ableiten: Verbesserung der Kundenzufriedenheit, Qualität und Prozesstransparenz, Verkürzung der Durchlaufzeiten und Kostenreduktion, rasche Anpassung an organisatorische Veränderungen und einheitliche Benutzeroberflächen (vgl. [Gad05-ol]).
(Die folgenden Punkte stammen aus [Gad05-ol]).
Verbesserung der Kundenzufriedenheit
Dieses Ziel wird für eine höhere Auskunftsfähigkeit gegenüber dem Kunden angestrebt. Workflow-Management-Systeme unterstützen dies, indem sie jederzeit den Status von laufenden Vorgängen liefern können.
Verbesserung von Qualität und Transparenz der Geschäftsprozesse
Die Automatisierung der Geschäftsprozesse soll Bearbeitungsfehlern vermindern. Der laufende Abgleich von Sollprozessen mit den tatsächlichen Ergebnissen, initiierte Anpassungsprozesse und schafft dadurch die Grundlage für eine erhöhte Prozessqualität.
Verkürzung von Durchlaufzeiten und Reduktion von Prozesskosten
Die Werkzeuge und Instrumente des Workflow-Managements erlauben die Parallelisierung einzelner Aktivitäten und vollständiger Prozesschritte unter Ausnutzung freier Personal- oder Computer-Ressourcen, die dynamisch den auszuführenden Geschäftsprozessen zugeordnet werden.
Schnellere Anpassung der Geschäftsprozesse an organisatorische Änderungen
Da Geschäftsprozesse im Rahmen des Workflow-Managements auf der Basis anpassbarer Workflow-Modelle unterstützt werden, lassen sich diese an Veränderungen im organisatorischen Umfeld anpassen (z. B. Veränderung der Abteilungsstruktur, Schaffung neuer Stellen).
Schaffung von einheitlichen Benutzeroberflächen
Workflow-Management-Systeme stellen dem Anwender eine für den gesamten Geschäftsprozess einheitliche Benutzeroberfläche zur Verfügung und rufen die im Rahmen der Aufgabenausführung jeweils erforderlichen Programme auf. Hierdurch entsteht für den Anwender der Eindruck einer ganzheitlichen Computerlösung.
Workflows
1993 wurde die Workflow Management Coalition (WfMC)[9] gegründet, eine internationale Organisation, in der sowohl Anwender und Hersteller von Workflow-Produkten, als auch in diesem Bereich tätige Universitäten und Forschungsgruppen zusammengeschlossen sind, um die Nutzung von Workflows durch die Etablierung von Standards zu fördern.
Seit 1996 publiziert die WfMC ein Glossar für Begriffe aus dem Workflow-Umfeld. Darin findet sich auch die aktuelle Definition des Begriffs Workflow:
„[Workflows are] The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.“ [All01, S. 15ff]
Workflows sind die Verfeinerung von Geschäftsprozessen auf der DV-technischen Ebene (vgl. [Gad05-ol]). Sie beschreiben, wie und mit welchen Mitteln Geschäftsprozesse auszuführen sind. Ein Geschäftsprozess legt dagegen ausschließlich die auszuführenden Aufgaben fest (siehe auch Infobox „Geschäftsprozesse vs. Workflows“).
Workflows werden in der Regel im Anschluß an die Analyse der Geschäftsprozesse eines Unternehmens entwickelt. Abbildung 3 zeigt die schrittweise Entwicklung eines Workflows aus einem Geschäftsprozess. Die Ablaufschritte eines Geschäftsprozesses werden durch standardisierte, oft graphische Notationen - zusammen mit den zu ihrer Ausführung benötigten Ressourcen - beschrieben. Neben den Ressourcen enthalten Workflow-Definitionen auch die ausführenden Einheiten von Aktivitäten, welche sowohl Menschen, Maschinen oder Programme sein können., d. h. es findet eine Unterscheidung zwischen manuellen und automatisierten Aktivitäten statt.
Abbildung in dieser Leseprobe nicht enthalten
Während Prozessmodellierung und das Business Process Reengineering dazu benutzt wurden, Arbeitsabläufe zu strukturieren und optimieren, dienen Workflows der Automatisierung dieser Arbeitsabläufe. Die einzelnen Arbeitsschritte können dabei durch Einbindung von Maschinen oder Programmen ebenfalls automatisiert oder manuell von Mitarbeitern ausgeführt werden.
Der hohe Detaillierungsgrad von Workflow-Definitionen erlaubt es, diese automatisiert durch Workflow-Management-Systeme auszuführen, welche die Steuerung (Zuweisung der Aktivitäten) und Überwachung des Ablaufs übernehmen.
Geschäftsprozess vs. Workflow
Unter Geschäftsprozess wird die zeitlich logische Abfolge betriebswirtschaftlicher Aufgaben verstanden, die in der Regel arbeitsteilig von mehreren Personen ausgeführt werden. Geschäftsprozesse haben eine betriebswirtschaftlich-strategische Gesamtsicht auf den Prozess, sie beschreiben, „was“ zu tun ist. Geschäftsprozesse werden im Rahmen des Business Reengineering modelliert und lassen sich mehrfach in Geschäftsprozesschritte untergliedern. Beispiele für Geschäftsprozesse sind die Auftragsabwicklung, die in mehrere Schritte zerfällt, wie z. B. in Auftragsprüfung und Rechnungsstellung.
Erhält ein Mitarbeiter ein Geschäftsprozessdiagramm, das seine Aufgaben darstellt, ist er in der Regel etwa schlauer: Er weiß nun, was er zu tun hat, von wem er seine Inputs (Informationen, vorhergehende Arbeitsergebnisse) erhält und an wen er seine Outputs weiterzugeben hat. Unter Umständen hat er aber keine Ahnung davon, wie er die ihm zugewiesene Aufgabe erledigen soll, denn ein Geschäftsprozess ist keine Arbeitsanweisung. Ein modellierter Workflow hingegen beschreibt möglichst genau die auszuführenden Arbeitsschritte. Das Ziel ist hierbei weniger eine Dokumentation für die Mitarbeiter als vielmehr die (Teil-)Automatisierbarkeit der Ausführung (vgl. [Gad05-ol] und [Fre05-ol]).
Workflow-Notation
Für die Definition von Workflows hat sich eine Reihe von Notationen entwickelt, die oft gemeinsame Wurzeln besitzen und somit auf den selben grundlegenden Konzepten fußen. Durch diese Verwandtschaft läßt sich eine Reihe von Konstrukten ableiten, welche allen Notationen gemein ist:
Split / Xor
Mit einem Split lassen sich Verzweigungen realisieren. Abhängig von einer Bedingung wird jeweils nur ein möglicher Ausführungsstrang durchlaufen. Oft gibt es auch die Möglichkeit, eine Standard-Alternative zu definieren (If – Then – Else).
Fork / And
Ein Fork ermöglicht die Ausführung paralleler Arbeitsschritte. Dabei werden alle möglichen Ausführungsstränge gleichzeitig gestartet.
Join
Joins dienen dazu, mehrere Ausführungsstränge nach einem Split oder Fork wieder zusammenzuführen. Je nach Notation werden hierfür jeweils unterschiedliche Symbole verwendet.
Schleifen
Schleifen werden für eine wiederholte Ausführung eines oder mehrerer Arbeitsschritte verwendet. Es lassen sich zwei Fälle unterscheiden: eine definierte Anzahl von Wiederholungen oder eine Wiederholung, bis eine bestimmte Bedingung erfüllt ist. Beide Fälle werden in der Regel mit einem Split umgesetzt.
Sub-Workflow
Sub-Workflows können Workflows strukturieren und modularisieren. Sie fassen Gruppen von Arbeitsschritten mit ihren Ausführungssträngen zu einem eigenen Workflow zusammen, der innerhalb eines anderen Workflows aufgerufen wird. Die Nutzung von Sub-Workflows ermöglicht auch die Wiederverwendung von Workflows.
Exception
Exceptions definieren Ausführungsstränge für einen Fehlerfall. Mit ihnen ist es möglich, Fehlerbehandlungen zu realisieren.
Start / Ende
Meist dienen Start und Ende nur als eine optische Markierung von Anfang und Ende eines Workflow. Manche Notationen erlauben hier aber auch Vorgaben für das Verhalten des Workflows, z. B. ob die Ausführung eines Workflows nach seinem Start automatisch ablaufen soll oder ob auf ein (manuelles) Ereignis gewartet wird.
Aktivitäten
Aktivitäten sind die kleinsten Ausführungseinheiten innerhalb eines Workflows. Sie enthalten die Anweisungen für die auszuführende Aufgabe sowie die Beschreibung der benötigten Ressourcen (Person, Applikation, Maschine) und benutzten Betriebsmittel. Oft enthalten Aktivitäten zusätzliche zeitliche Informationen, die unterstützende Funktionen des Workflow-Management-Systems erlauben (z. B. Timeouts [10] ) oder eine Simulation des Ablaufs.
Für die Modellierung von Workflows hat sich eine graphische Notation durchgesetzt,
die stark den in der UML enthaltenen Aktivitätsdiagrammen ähnelt. Tatsächlich können Aktivitätsdiagramme auch für die Modellierung von Workflows bzw. Geschäftsprozessen verwendet werden, was den Vorteil bietet, einen etablierten Standard einzusetzen. Eine Einführung zur Geschäftsprozessmodellierung mit der UML findet sich in [Oes04].
Abbildung 4 auf der folgenden Seite zeigt eine modifizierte Version des im Q&A Dokument „Process Definition Interchange“ der WfMC beschriebenen „Sales Order Processing“ [WfMC-TC-1016-X99].
Für die Erstellung wurde das Open-Source-Werkzeug Enhydra JaWE (Java Workflow Editor) verwendet[11]. JaWE ist Teil des Enhydra- Projekts unter dem Dach von ObjectWeb [12], einem Konsortium, das die Förderung der Entwicklung einer verteilten Open-Source-Middleware zum Ziel hat.
JaWE ist ein graphischer Editor für Workflow-Definitionen, der in vielen Workflow-Management-Systemen eingesetzt wird. Er basiert auf der Workflow-Beschreibungssprache XML Process Definition Language (XPDL), einem Standard der WfMC.
Eine detailierte Einführung in Modellierung von Workflows mittels JaWE findet sich in der Online-Hilfe zu JaWE und im mit ausgelieferten Tutorial[13].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Workflow "Sales Order Processing", erstellt mit Enhydra JaWE.
Der „Sales Order Process“ beschreibt den Prozess der Auftragsannahme, Produktion und Auslieferung der fiktiven Firma „FBN Sports Equiqment Company“, die als Beispielfirma für das Q&A-Dokument zu der Process Definition Interchange Spezifikation ([WfMC-TC-1016-P99]) der WfMC dient.
Nach Eingabe einer Bestellung wird die Kreditwürdigkeit des Kunden geprüft. Fällt diese negativ aus, endet der Workflow an dieser Stelle. Ist sie positiv, wird eine Anfrage an das Lager gestellt, ob der Bestand groß ist, um die Bestellung auszuführen. Falls ja, wird die Bestellung ausgeführt. Ist das Lager leer, wird die Planung der vollständigen Produktion begonnen. Ist das Lager nicht leer, der Bestand aber zu klein, um die Bestellung zu decken, werden parallel zwei Handlungswege gestartet: Zum einen wird ein Plan für die Teilproduktion erstellt, zum anderen erfolgt eine Nachfrage beim Kunden, ob eine Teillieferung möglich ist. Ist die Antwort des Kunden bezüglich einer Teillieferung negativ, muß stattdessen die Planung für eine vollständige Produktion beginnen. In beiden Fällen erfolgt nach der Planung die Produktion und nach deren Abschluß die Benachrichtigung und Auslieferung an den Kunden.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle : Enhydra JaWE Notation
Das Beispiel zeigt ein interessantes Merkmal in der von JaWE genutzten Notation: Es existiert kein eigenes Symbol für die Modellierung von Verzweigungen. Stattdessen bestimmen sogenannte post-conditions im Anschluß an die Ausführung einer Aktivität die Folgeaktivitäten. Ebenso wird für die Zusammenführung verschiedener Alternativen einer Bedingung kein eigenes Symbol benutzt. Dies geschieht mit pre-conditions einer Aktivität.
Es existieren auch Notationen, die hierfür eigene Symbole verwenden. Eines der bekanntesten Beispiele einer solchen Notation sind die ereignisgesteuerten Prozessketten (EPK), die im ARIS Toolset Anwendung finden. Ein Ausgangspunkt für weitere Informationen über EPKs findet sich in [Wiki05c-ol].
Workflow-Sprachen
Neben einer graphischen Notation für die Modellierung eines Workflows ist es noch wichtiger, Workflows mit einer formalen Sprache beschreiben zu können, nicht zuletzt deshalb, um die Ausführung der Workflows innerhalb eines Workflow-Management-Systems zu ermöglichen.
Neben einer Vielzahl verschiedener vorhandener Workflow-Management-Systeme oder der verfügbaren graphischen Notationen für die Modellierung von Workflows, existiert auch eine große Auswahl an formalen Sprachen für die Definition von Workflows. Abbildung 5 zeigt die bekanntesten dieser Sprachen. Gerade in den letzten Jahren ist ein fast inflationärer Anstieg der Vorschläge für Workflow-Sprachen durch verschiedene Standardisierunggremien wie z. B. WfMC oder OASIS[14], aber auch durch kommerzielle Organisationen wie IBM und Microsoft erfolgt. Wie bereits am Anfang dieses Kapitels erwähnt, haben diese Entwicklung vor allem neue Technologien wie z. B. Web-Services in Verbindung mit der Business-Process-Modellierung vorangetrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Standards im Umfeld von Workflow-Management (aus: )
Folge dieser Entwicklung war eine enge Bindung an den Hersteller, die einen einfachen Austausch eines Workflow-Management-Systems kaum mehr möglich machte. Die Folgen dieses sogenannten vendor lock-in, das als eigenes Anti-Pattern [15] gilt, werden in [BMMM99, S. 167ff] beschrieben. Auch die Interoperabilität verschiedener WfMS, wie es z. B. ein konzernübergreifendes Prozessmanagement, das die Prozesse verschiedener Firmen verbindet, erforderlich macht, ließ sich kaum realisieren.
Mit Vorstellung der Spezifikation der Workflow Process Definition Language (WPDL) versuchte die WfMC bereits 1999 einen Standard für den Austausch von Workflows zu schaffen. WPDL basiert auf dem vom WfMC definierten Referenzmodell für Workflow-Management-Systeme, welches später noch vorgestellt wird. WPDL wurde als Metasprache[16] für den Austausch von Workflow-Definitionen geschaffen. Dazu definiert sie ein Minimum an elementaren Komponenten, die Workflow-Management-Systeme für eine gemeinsame Kommunikation unterstützen müssen. Dieses minimale Set kann durch herstellerspezifische Erweiterungen angepaßt werden. Eine Beschreibung des Meta-Modells findet sich im folgenden Abschnitt dieses Kapitels, welches sich mit XPDL als Weiterentwicklung der WPDL befaßt.
WPDL ist eine strukturierte textuelle Beschreibung von Workflows. Sie bietet keine Unterstützung einer graphischen Notation. Die formale Definition der WPDL findet sich in [WfMC-TC-1016-P99], der Beschreibung der Schnittstelle für den Austausch von Workflow-Definitionen des WfMC. Obwohl viele Hersteller von Workflow-Management-Systemen ihren Produkten die Konformität zu WPDL bescheinigten, gab es nur wenige, die diese auch vollständig umsetzten.
Der Trend heute geht allerdings zu Sprachen wie BPML[17] oder BPEL[18] / BPEL4WS[19], welche vor allem die Integration von Web-Services forcieren. Ein Vergleich dieser Sprachen mit XPDL bietet [Sha02].
XML Process Definition Language
XPDL ist die von der WfMC vorgeschlagene Sprache, um den Austausch von Workflow-Definitionen zwischen verschiedenen Workflow-Management-Systemen zu erlauben. Damit tritt XPDL die Nachfolge der kaum anerkannten WPDL an. XPDL soll den Im- und Export von Workflow-Definitionen zwischen der ganzen Bandbreite der an Workflows beteiligten Werkzeuge, angefangen von Modellierungstools über Simulationswerkzeugen bis hin zu den Workflow-Management-Systemen selbst, ermöglichen. Um dieses Ziel zu erreichen, definiert die Spezifikation der XPDL, welche im Oktober 2002 als Final Draft veröffentlicht wurde, ein minimales Set von Sprachkonstrukten, das fast allen Workflow-Produkten gemein ist. Seit Oktober 2005 liegt die Spezifikation in der Version 2.0 vor ([WfMC-TC-1025-05]).
XPDL ist eine XML-basierte Sprache, die durch ein XML-Schema spezifiziert wird.
Für die Definition von Workflows bietet XPDL die im folgenden beschriebenen XML-Elemente:
Package
Dieses Element dient als Behälter für alle anderen Elemente. Innerhalb von Package können verschiedene Prozesse sowie prozessübergreifende Datentypen, Daten, Ressourcen und Applikationen definiert werden.
Application
Dieses Element beschreibt Anwendungen, welche von Aktivitäten zur Ausführung ihrer Aufgaben benutzt werden.
WorkflowProcess
Definiert Workflow-Prozesse bzw. Sub-Workflows. Innerhalb dieses Elements können prozesseigene Datentypen, Daten und Ressourcen festgelegt werden.
Activity
Spezifiziert die Aktivitäten eines Workflows. Für verschiedene Aufgaben existieren unterschiedliche Ausprägungen von Aktivitäten.
Transition
Transitionen legen die Handlungsstränge der Workflows fest, d. h. sie bestimmen die Ausführungsreihenfolge der Aktivitäten.
Participant
Ressourcen eines Workflows (Personen oder Maschinen) werden als Teilnehmer eines Workflows beschrieben. In der Regel werden Personen nicht direkt addressiert, sondern Rollenbezeichnungen verwendet.
DataType
Mittels DataType können neben den implizit vorhandenen einfachen Datentypen auch komplexe Datentypen, wie z. B. Aufzählungstypen, definiert werden.
DataField
Deklariert Workflow-eigene Variablen und benutzte Parameter eines Workflows. Aktivitäten des Workflows können auf diese Variablen zugreifen und somit Daten untereinander austauschen. Ebenso können diese Variablen als Parameter an Sub-Workflows weitergegeben werden bzw. deren Ergebnisse wieder aufnehmen.
Neben den hier beschriebenen Elementen existieren noch weitere, die jedoch vorrangig für eine nähere Beschreibung der Hauptelemente genutzt werden. Um eine Anpassung an herstellerspezifische Anforderungen verschiedener Workflow-Produkte zu erlauben, besteht zusätzlich noch die Möglichkeit, das Modell um eigene Informationen zu erweitern. Dies geschieht mittels den sogenannten ExtendedAttributes, die aus Schlüssel-Werte-Paaren bestehen.
In Abbildung 6 auf der folgenden Seite werden die einzelnen Elemente und ihre Beziehungen zueinander noch einmal in UML Notation abgebildet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : XPDL Meta-Modell (aus: )
In [Aal03] wird eine Evaluierung der Anwendbarkeit von XPDL für die Definition von Workflows anhand bekannter Patterns durchgeführt, die sich aus realen Problemstellungen bei der Workflow-Modellierung ergeben. Anhand der Ergebnisse läßt sich bewerten, ob der Einsatz von XPDL als Sprache für die Definition von Workflows unter bestimmten Anforderungen Sinn macht.
Einen detaillierteren Einstieg in XPDL bietet die Homepage des von der Deutschen Forschungsgemeinschaft (DFG)[20] geförderten Forschungsprojekts ECOMOD ([Eco05-ol]). Die Ergebnisse dieses Projekts fließen auch in [Jun04] ein, indem die konkrete Umsetzung von Geschäftsprozessen in Workflows mittels XPDL anhand von Fallbeispielen beschrieben wird.
Eine Beschreibung des von der WfMC definierten Meta-Modells mit Hilfe der UML findet sich in [RC03, S. 560-570].
Das WfMS, das in dieser Masterarbeit entwickelt wird, verwendet als Beschreibungssprache XPDL.
Workflow-Management-Systeme dienen der Ausführung der aus der Geschäftsprozessmodellierung entstandenen Workflows und führen damit die Steuerung sogenannter arbeitsteiliger Prozesse aus.
Da Workflow-Management-Systeme in der Praxis eine zentrale und äußerst kritische Komponente in der Steuerung der Abläufe eines Unternehmens darstellen und somit durchaus den Unternehmenserfolg beeinflussen können, werden an diese neben der reinen Ausführung von Workflows noch weitere funktionale sowie nicht-funktionale Anforderungen gestellt. Gerade diese sind zu berücksichtigen, wenn innerhalb eines Unternehmens ein WfMS eingeführt werden soll und die Entscheidung über eine Eigenentwicklung oder den Einsatz eines verfügbaren WfMS ansteht.
Die Erfüllung dieser Anforderungen entscheidet in der Regel maßgeblich darüber, ob aus einem WfMS ein flexibles, erweiterbares System für den unternehmensweiten Einsatz, ein Nischenprodukt, zugeschnitten auf ein schmales Spektrum von Anforderungen, oder schlimmstenfalls eine „Totgeburt“ wird.
Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen vorgestellt sowie Konzepte und Architekturen für deren Umsetzung. Die Anforderungen resultieren aus der inzwischen mehr als zwanzigjährigen Erfahrung im Bereich Workflow-Management.
Aufgaben eines Workflow-Management-Systems
Die Geschäftsprozessoptimierung ist ein fortwährender Vorgang, der erst nach Abschluß der Geschäftsprozessanalyse und der Umsetzung der Prozesse als Workflows beginnt. Die auf Seite 14 beschriebenen Ziele des Workflow-Managements lassen sich mit Hilfe eines WfMS in der Regel nur erreichen, wenn dieses geeignete Funktionen für Simulation, Monitoring und Auswertung von Workflows bietet, um so eine Optimierung dieser zu erlauben. Nur auf diese Weise lassen sich Problemstellen und Engpässe im Ablauf identifizieren und beseitigen. In [Gad05-ol] wird der sogenannte Workflow-Life-Cycle, der in Abbildung 7 dargestellt ist, ausführlich beschrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Kreislauf der Geschäftsprozessoptimierung (aus: )
Anforderungen an Workflow-Management-Systeme
Wie bereits erwähnt, existieren eine Reihe von Anforderungen für ein Workflow-Management-System, welche sich in der Regel in zwei Kategorien einteilen lassen: funktionale und nicht-funktionale.
Funktionale Anforderungen beschreiben eine gewünschte bzw. geforderte Funktionalität einer Anwendung, hier eines WfMS.
Nicht-funktionale Anforderungen sind in der Regel schwieriger zu fassen; sie beschreiben Rahmenbedingungen, welche die Implementierung einer Anwendung in verschiedener Form beeinflussen.
In [Pfle01, S. 141f] wird die Unterscheidung funktionaler und nicht-funktionaler Anforderungen wie folgt beschrieben:
„A functional requirement describes an interaction between the system and its environment. [...] A nonfunctional requirement or constraint describes a restriction on the system that limits [...] choices for constructing a solution to the problem.“
Abbildung 8 zeigt eine Auswahl der funktionalen Anforderungen, die an ein Workflow-Management-System gestellt werden. Die beschriebenen Anforderungen sind auch Voraussetzungen für die auf der vorangegangen Seite genannten „erweiterten“ Aufgaben eines WfMS für die Unterstützung der Geschäftsprozessoptimierung.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Funktionale Anforderungen an ein WfMS (aus: )
Wie bereits beschrieben, sind nicht-funktionale Anforderungen an eine Anwendung schwieriger zu definieren, da die Stakeholder[21], im Gegensatz zu funktionalen Anforderungen, implizit von ihrer Existenz ausgehen und sie während der Anforderungsanalyse nicht ausdrücklich erwähnen.
Trotzdem stellt die Erfüllung nicht-funktionaler Anforderungen einen wichtigen Aspekt für die spätere Akzeptanz eines Systems oder Produktes durch die Anwender dar. Ein Extrembeispiel für eine nicht berücksichtigte nicht-funktionale Anforderung ist ein Workflow-Management-System, dessen schlechte Performanz die Prozesse innerhalb eines Unternehmens eher behindert, anstatt sie zu unterstützen. Das würde den Einsatz dieses WfMS auf jeden Fall verhindern.
Neben der adäquaten Performanz eines Systems gibt es noch viele weitere nicht-funktionale Anforderungen, die aber oft verschiedensten Anwendungen gemein sind.
Die folgende Liste erläutert einige nicht-funktionale Anforderungen im Hinblick auf Workflow-Management-Systeme, wie sie bereits 1997 in [Meln97] beschrieben wurden. Die ursprüngliche Liste wurde für heutige Systeme überarbeitet und erweitert. Trotzdem ist erkennbar, daß sich gerade nicht-funktionale Anforderungen auch über einen langen Zeitraum[22] kaum verändern.
Dezentrale Architektur
Workflow-Management-Systeme dürfen nicht von einigen wenigen zentralen Ressourcen (z. B. Datenbanken, Applikationsservern) oder Anwendungsteilen (Monitor, Task-Manager) abhängen. Neben der Gefahr des Ausfalls einer solchen Komponente (single point of failure), könnten diese auch als „Flaschenhälse“ zu Performanzproblemen führen.
Unterstützung der Heterogenität
Unternehmen besitzen heute in der Regel eine heterogene Systemlandschaft aus verschiedensten Hardware-Plattformen und Betriebssystemumgebungen. Ebenso wie andere Enterprise-Anwendungen, sollten auch Workflow-Management-Systeme in der Lage sein, mit diesen Anforderungen umzugehen, d. h. bestenfalls in jeder Umgebung ablauffähig sein.
Interoperabilität
Der Einsatz eines WfMS dient in der Regel der Optimierung bestehender Prozesse durch deren Automatisierung. Das bedingt eine hohe Anforderung an die Integrationsfähigkeit des WfMS für bestehende Anwendungen und eventuell anderer Workflow-Systeme. Dies läßt sich nur mit Unterstützung von offenen, herstellerunabhängigen Standards erreichen.
Skalierbarkeit
Von Unternehmensanwendungen wird heute eine hohe Skalierbarkeit erwartet. Das heißt, Performanzprobleme müssen durch Zufügen zusätzlicher Ressourcen (mehr Speicher, zusätzliche Rechenkapazität) ohne Konfigurationsänderungen, möglichst sogar im laufenden Betrieb, ausgleichen lassen.
Die Auslastung eines WfMS läßt sich durch eine Reihe von Kennzahlen überwachen: Häufigkeit der Instantiierung eines Workflows, Anzahl der aktiven Aktivitäten / Workflow-Instanzen zu einem Zeitpunkt, mittlere Verweildauer eines definierten Workflows im System. Ein WfMS sollte bei steigender Auslastung des Systems keine signifikante Verschlechterung der Performanz zeigen bzw. muß diese gegebenenfalls durch Hinzufügen von Ressourcen ausgleichen lassen.
Adaptierbarkeit und Erweiterbarkeit
Das Auftreten unvorhergesehener interner oder äußerer Ereignisse (z. B. Umstrukturierungen in Unternehmen) erfordert eine entsprechende Anpassung des WfMS. Insbesondere sollen Workflow-Definitionen änderbar und eventuell sogar Workflow-Instanzen zur Laufzeit modifizierbar sein.
Sicherheit
Sicherheitslücken in Unternehmensanwendungen können einen existenzbedrohenden Schaden verursachen. Auch hier muß ein WfMS entsprechende Mechanismen bieten und sich in existierende Sicherheitsarchitekturen einbinden lassen.
Transaktionsunterstützung
Transaktionen gewährleisten einen vollständigen Datenverarbeitungsvorgang bei mehrstufigen Prozessen. Wurden alle Einzelprozesse erfolgreich abgeschlossen, wird die Transaktion gültig; schlägt die Ausführung eines Einzelprozess fehl, erfolgt ein sogenannter rollback, d. h. es werden alle Änderungen, die seit Beginn der Transaktion ausgeführt wurden, zurückgenommen. Transaktionen sind heute wichtige Bestandteile aller Ebenen der Datenverarbeitung. Für ein zentrales, Prozesse steuerndes WfMS, ist es deshalb unabdingbar, eine eigene Transaktionssteuerung zu besitzen oder sich in bestehende Systeme einbinden zu lassen.
Fehlertoleranz / Recovery
Dieser Punkt hängt unmittelbar mit der zuvor genannten Transaktionssunterstützung zusammen. Die Rücknahme durchgeführter Änderungen bei einem Fehlerfall innerhalb einer Transaktion ist nur ein erster Schritt der Reaktion. Zusätzlich sollte ein WfMS eine umfassende Fehlerbehandlung und auch Recovery -Mechanismen unterstützen.
Hochverfügarkeit
Unternehmensanwendungen erfordern heute eine Verfügbarkeit von möglichst 24x7[23]. In Verträgen werden oft Verfügbarkeitsanforderungen von bis zu 99,99 % oder höher vereinbart (siehe [Wiki05o-ol]). Diesen Anforderungen muß natürlich auch ein Workflow-Management-System genügen. Um dies zu gewährleisten, werden hier oft durch sogenanntes clustering[24] redudante Strukturen geschaffen, in denen bei Ausfall einer Komponente eine andere nahtlos deren Arbeit übernimmt
Die letzten drei Punkte stellen für die Implementierung eines Workflow-Management-Systems eine schwierige Herausforderung dar. Ziel ist es, die Ausführung eines Workflows zu jeder Zeit zu garantieren und nach einem Fehlerfall die Fortführung des Workflows an jedem Punkt zu erlauben.
Die beiden Themen Hochverfügbarkeit und Fehlerbehandlung in Workflow-Management-Systemen werden in den Forschungberichten [KAGM95] und [KAGM+94] im Rahmen des von IBM entwickelten WfMS FlowMark behandelt.
WfMC Referenzmodell
Wie im vorhergehenden Teil dieses Kapitels beschrieben, gehört Interoperabilät zu den wichtigsten nicht-funktionalen Anforderungen an ein WfMS. In der Anfangszeit des Workflow-Managements wurde das nur selten berücksichtigt. Viele Hersteller entwickelten ihre eigenen proprietären Lösungen als Ergänzung zu ihren bestehenden Produkten.
In letzter Zeit hat hier jedoch ein Paradigmenwechsel stattgefunden und vor allem große Softwarefirmen wie Microsoft, IBM und Oracle versuchen, gemeinsame Standards, wie z. B. BPEL, zu schaffen. Diese Entwicklung wurde stark beeinflußt von den Konzepten der Web-Services, die einen transparenten Zugriff auf verteilte, heterogene Dienste ermöglichen sollen. Das ist auch der Grund, warum heutige Standards im Bereich des Workflow-Managements einen starken Fokus auf Web-Services besitzen. Am stärksten drückt sich das bei der Weiterentwicklung von BPEL zu BPEL4WS aus, das eine Definition von Business-Prozessen auf Basis von Web-Services als ausführende Komponenten erlaubt. Allerdings steht hier die Standardisierung der Workflow- / Business-Prozessdefinitionen im Vordergrund. Eine Integration verschiedener Workflow-Management-Systeme ist auch weiterhin nur schwer zu verwirklichen.
Die WfMC hat die Notwendigkeit einer Interoperabilität, sowohl durch Kompatibilität der Workflow-Definition, als auch durch Integration bestehender Anwendungen und anderer WfMS, erkannt und bereits 1994 ein Referenzmodell für die Implementierung von Workflow-Management-Systemen veröffentlicht ([WfMC-TC00-1003-94]).
Das Workflow-Referenzmodell gibt dabei keine Vorgaben für die Umsetzung des Workflow-Management-Systems selbst, sondern definiert fünf Schnittstellen, deren Implementierung die Interoperabilität zu anderen Systemen garantiert, falls diese die Schnittstellen ebenfalls verwenden.
Abbildung 9 auf der folgenden Seite zeigt eine schematische Übersicht der Schnittstellen und ihrer Aufgaben.
Den Kern eines WfMS bildet der sogenannte workflow enactment service[25], der aus einer oder mehreren Workflow-Engines bestehen kann. Er stellt die Ablaufumgebung für die Ausführung von Workflows bereit, die das Erzeugen, Verwalten und Ausführen von Workflows erlaubt. Zusätzlich dazu ist der workflow enactment service für die Interaktion mit Ressourcen, wie Anwendungen oder Personen, zuständig.
Der Zugriff auf den workflow enactment service geschieht je nach Aufgabenbereich über eine der im Folgenden beschriebenen Schnittstellen (vgl. [WfMC-TC00-1003-94]).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : WfMC Referenzmodell (vgl. )
Schnittstelle 1
Spezifiziert den Austausch von Workflow-Definitionen zwischen Modellierungswerkzeugen und dem Workflow-Management-System. Diese Werkzeuge können graphische oder textbasierte Editoren für Workflow-Definitionen sein. Die Spezifikation der bereits beschriebenen XML Processing Language ist Teil dieser Schnittstelle.
Schnittstelle 2
Beschreibt den Datenaustausch zwischen einem WfMS und einer Workflow-Client-Anwendung. Workflow-Client-Anwendungen sind Programme, die eng mit dem WfMS in Beziehung stehen. Üblicherweise bieten sie grundlegende Funktionalitäten wie Nachrichtendienste und Datentransfer und werden als sogenannte Worklist[26] in Anwendungen integriert. Die Anbindung der Client-Anwendungen erfolgt über das ebenfalls in dieser Schnittstelle spezifizierte Workflow Application Programming Interface (WAPI), für das Bindungen für verschiedene Sprachen wie C/C++ und CORBA/IDL existieren.
Schnittstelle 3
Definiert die Vorgehensweise für eine Integration externer Anwendungen, die entweder von dem WfMS selbst oder innerhalb eines Workflows benutzt werden. Beispiel für Ersteres ist die Anbindung einer vorhandenen Benutzerverwaltung
wie z. B. einem LDAP-Verzeichnisdienst[27], für Zweiteres die Anbindung betrieblicher Standardsoftware.
Schnittstelle 4
Integration anderer Workflow-Management-Systeme. Die Spezifikation sieht den Aufruf entfernter Workflows vor und beschreibt den damit verbundenen Datentransfer sowie Möglichkeiten der Synchronisation zwischen verschiedenen Workflow-Engines.
Schnittstelle 5
Beschreibt die Kommunikation zwischen dem Workflow-Management-System und externen Kontroll-, Monitoring- oder Verwaltungswerkzeugen.
Architektur von Workflow-Management-Systemen
Workflow-Management-Systeme verschiedener Hersteller unterscheiden sich in ihrer Implementierung in der Regel sehr stark. Bedingt wird das durch unterschiedliche Konzepte und den Einsatz verschiedener Architekturen. Trotz dieser Unterschiede basiert die Mehrzahl der Workflow-Management-Systeme auf einer Mehrschichtarchitektur, die in Abbildung 10 schematisch dargestellt ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Schichtenmodell eines WfMS
Mehrschichtarchitekturen basieren auf einer starken Trennung der Zuständigkeiten (vgl. [Gad05-ol]):
Die Präsentationsschicht beinhaltet die Bedieneroberfläche und dient der Interaktion mit den Benutzern. Zentrales Element der Bedieneroberfläche ist in der Regel die Worklist, welche die dem Benutzer zugewiesenen Aufgaben enthält. Diese können aus der Worklist gestartet werden und über Dialogprogramme des Applikations-Client, der, im Fall einer zum WfMC-Referenzmodell kompatiblen Implementierung, über die Schnittstelle 2 auf das WfMS zugreift. Die Verarbeitungsschicht enthält die Logik für die Verarbeitung der Workflows und greift im Bedarfsfall auf Komponenten angebundener Anwendungen über Schnittstelle 3 zu. Die Datenzugriffsschicht bietet einen Persistenzmechanismus für Applikationsdaten sowie für Workflow- und WfMS-relevante Daten. Die Anbindung dieser Schicht ist nicht Teil des WfMC-Referenzmodells. In der Regel erfolgt die Speicherung dieser Daten über ein Datenbankmanagementsystem.
Neben der generellen Verwendung des Mehrschichtenmodells in Workflow-Management-Systemen spielt vor allem auch die Architektur des Workflow Enactment Service, der zentralen Komponente eines WfMS, eine bedeutende Rolle.
Für die Implementierung dieser Komponente existieren verschiedene Architekturen, die in [MSKW96, S. 8ff] und [Meln97] beschrieben werden. Im Folgenden wird als Zusammenfassung der beiden genannten Publikationen ein kurzer Überblick über die möglichen Architekturen gegeben.
Komponenten des Enactment Service
Die Laufzeitumgebung eines WfMSs besteht, wie in [Meln97] beschrieben, aus drei Hauptkomponenten:
Task
Tasks sind die Laufzeitinstanzen der in einem Workflow beschriebenen Aktivitäten. Sie dienen entweder der Einbeziehung von Benutzern, indem sie als Client-Applikation innerhalb der Worklist auftauchen und aufgerufen werden können, oder sie realisieren die Integration von (Unternehmens)-Anwendungen, die an einem Workflow beteiligt sind.
Task-Manager
Der Task-Manager ist für den sogenannten Life-Cycle einer Task verantwortlich. Außerdem überwacht er die Ausführung der Task und meldet deren Status an den Workflow-Scheduler zurück.
Workflow-Scheduler
Der Workflow-Scheduler ist für die Koordination der Abläufe unter Berücksichtigung der Abhängigkeiten zwischen den Tasks verantwortlich. Er verwaltet dazu Warteschlangen, in denen Tasks, die vor der Ausführung stehen, „geparkt“ werden. Wann welcher Task gestartet wird, hängt von verschiedenen Faktoren, wie z. B. der Priorität eines Workflows, ab. Der sogenannte Dispatcher, der Teil des Scheduler ist, übernimmt diese Aufgabe.
Die Realisierung bzw. Verteilung dieser Komponenten bestimmt die Architektur eines WfMS und damit auch dessen Eigenschaften.
Hochzentralisierte Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Hochzentralisiserte Architektur
In dieser Architektur sind die Task-Manager als Teil des Scheduler realisiert, d. h. sie laufen innerhalb des selben Prozesses, wobei Scheduler, Dispatcher und die einzelnen Task-Manager jeweils als eigene Threads realisiert sind. Die Tasks laufen in getrennten Prozessen und können auf verschiedene Rechner verteilt sein.
Synchrone zentralisierte Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Synchrone zentralisierte Architektur
Der Hauptunterschied zur vorhergehenden Architektur ist, daß die einzelnen Task-Manager nicht mehr als Threads innerhalb des Scheduler- Prozesses, sondern eigene Prozesse sind und somit auf verschiedene Rechner verteilt werden können. Der Scheduler- Prozess besitzt jedoch trotzdem einen sogenannten Task-Agent je Task-Manager. Dieser ist für die Kommunikation mit den Task- Managern zuständig, die via synchroner Remote Procedure Calls[28] (RPC) erfolgt.
Durch die Trennung der Task-Manager vom Scheduler und der damit möglichen Verteilung dieser auf verschiedene Rechner, können die Task-Manager ihre Aufgaben parallel ausführen.
Asynchrone zentralisierte Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Asynchrone zentralisiserte Architektur
Ähnlich wie in der synchronen zentralisierten Architektur sind die Task-Manager nicht Teil des Scheduler -Prozesses. Die Kommunikation zwischen Scheduler und Task-Manager erfolgt hier jedoch nicht synchron, sondern wird durch einen asynchronen Messaging [29] -Mechanismus ersetzt. Das hat zur Folge, daß die vorher vorhandenen Task-Agents entfallen und stattdessen ein sogenannter Message Collection Service eingesetzt wird. Dieser sammelt die von den Task-Managern gesendeten Nachrichten und leitet sie an den Scheduler weiter. Die Kommunikation zwischen Task-Managern und Tasks erfolgt weiterhin synchron, könnte aber bei Bedarf ebenfalls durch einen asynchronen Mechanismus ersetzt werden
Semi-verteilte Architektur
In der semi-verteilten Architektur können die einzelnen Task-Manager auch untereinander mittels asynchroner Nachrichten kommunizieren. Das dient dazu, die Arbeitslast des Scheduler zu reduzieren. Daten, die von den Tasks für ihre Ausführung benötigt werden, können nun direkt von anderen Tasks bezogen werden, ohne einen Umweg über den Scheduler nehmen zu müssen. Der Scheduler erhält ausschließlich
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Semi-verteilte Architektur
Kontrollsignale der Task-Manager, um über den Zustand der Tasks informiert zu werden. Eine Erweiterung dieser Architektur ist ein selbstständiger Monitoring Service, der Statusinformationen direkt von den Task-Managern erhält.
Vollständig verteilte Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung : Vollständig verteilte Architektur
Die vollständig verteilte Architektur enthält schließlich keinen zentralen Scheduler mehr. Stattdessen besitzt jeder Task-Manager eine eigene Scheduler -Komponente, die bestimmt, wann die Ausführung des Tasks starten soll. In Workflows besitzen Aktivitäten in der Regel eine oder mehrere Vorgängeraktivitäten. Diese Information wird nun dem Task-Manager zur Verfügung gestellt. Stellt er fest, daß alle Vorgängeraktivitäten beendet wurden, startet er den Task der ihm zugeordneten Aktivität. Die Kommunikation unter den Task-Managern und zwischen Task-Manager und Monitoring Service erfolgt auch in diesem Fall wieder asynchron.
Die vollständig verteilte Architektur eines Workflow-Management-Systems spiegelt die Eigenschaften der Struktur von Workflows wider, was deren einfache Abbildung dieser auf das WfMS erlaubt. Zusätzlich dazu eliminiert diese Architektur auch den Flaschenhals eines zentralen Scheduler und verringert durch ihre verteilte Struktur auch die Fehleranfälligkeit des gesamten Systems. Der Ausfall einer Komponente beeinträchtigt im besten Fall nur einen Teil des ausgeführten Workflows. Die Verwendung asynchronen Nachrichten, die vom Messaging-System zwischengespeichert werden, erlaubt auch, einfache, effektive Recovery -Mechanismen zu erstellen.
Die Flexibilität und Skalierbarkeit der vollständig verteilten Architektur wird natürlich mit einem gesteigerten Overhead der Kommunikation zwischen den einzelnen Komponenten erkauft.
Der im Rahmen dieser Masterarbeit entwickelte Prototyp Activity//Spaces WfMS basiert auf der vollständig verteilten Architektur. Für die Realisierung findet eine Technologie Verwendung, die die Entwicklung verteilter Anwendungen ermöglicht. Das folgende Kapitel beschreibt diese Technologie ausführlich.
[...]
[1] http://www.sun.com/software/jini
[2] http://www.jcp.org/en/jsr/detail?id=94
[3] http://drools.org
[4] http://www.jboss.org
[5] http://java.sun.com/j2ee
[6] Eine deutsche Umschreibung für den Begriff Buzzword lautet: Schlagwort, mit dem um besondere Aufmerksamkeit gebuhlt wird [Wiki05a-ol].
[7] Software-Anwendung, die mittels eines Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML-Artefakte definiert, beschrieben und gefunden werden kann [Wiki05e-ol].
[8] TLA: Three Letter Acronym, Abkürzungen mit drei Buchstaben
[9] http://www.wfmc.org
[10] Besitzen Aktivitäten eine maximale Bearbeitungsdauer, können sie bei Überschreitung dieser (Timeout) abgebrochen und evtl. ein Eskalationsmechanismus gestartet werden.
[11] http://jawe.objectweb.org
[12] http://www.objectweb.org
[13] Auch online verfügbar unter: http://jawe.objectweb.org/doc/1.4/Tutorial
[14] Organization for the Advancement of Structured Information Standards. http://www.oasis-open.org
[15] Ein Anti Pattern beschreibt eine typische Lösung aus der Praxis, die jedoch mehr Probleme schafft, als sie löst. Dazu wird noch eine überarbeitete Lösung beschrieben, welche die Probleme der ersten verhindert.
[16] Metasprache: Sprache, die eine andere Sprache definiert.
[17] Business Process Modelling Language: XML-basierte Metasprache zur Beschreibung von Geschäftsprozessen. http://www.bpmi.org/bpml-spec.htm
[18] Business Process Execution Language: XML-basierte Sprache zur Beschreibung von Geschäftsprozessen.
[19] Business Process Execution Language for Web-Services: XML-basierte Sprache zur Beschreibung von Geschäftsprozessen. Beschreibt die Zusammenarbeit von als Web-Services realisierten Aktivitäten. http://www-128.ibm.com/developerworks/library/specification/ws-bpel/l
[20] http://www.dfg.de
[21] Stakeholder sind Informationslieferanten für Ziele, Anforderungen und Randbedingungen an ein zu entwickelndes System oder Produkt ([Wiki05d-ol]).
[22] Acht Jahre mögen nicht unbedingt als langer Zeitraum erscheinen, vergleicht man jedoch die 1997 verwendeten Technologien in der Softwareentwicklung mit den heutigen, kann man diesen Zeitraum in diesem Kontext durchaus als lang bezeichnen.
[23] 24 Stunden an 7 Tagen
[24] engl. cluster = Traube, Bündel, Schwarm
[25] Laufzeitumgebung für Workflows
[26] Zentrale Sammelstelle sämtlicher Aufgaben, welche die Benutzer eines Workflow-Systems für einzelne Prozesse zu bearbeiten haben (aus: [DOCM05-ol]).
[27] Lightweight Directory Access Protocol: Protokoll für die Abfrage von Verzeichnisdiensten, welche Informationen in Baumstrukturen geordnet speichern.
[28] Netzwerkprotokoll für entfernte Funktionsaufrufe [Wiki05f-ol].
[29] Asynchrone Kommunikation, die auf der Übertragung von Nachrichten (Messages ) basiert [Wiki05g-ol].
