Interaktion von Workflowmanagementsystemen intraorganisational

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1. Einführung
1.1. Motivation
1.2. Aufbau der Arbeit

2. Grundlagen einer Interaktion
2.1. Anforderungen einer Interaktion zwischen WfMS
2.2. Notwendigkeit einer Standardisierung?
2.3. Die Workflow Management Coalition
2.4. Zwischenergbnisse

3. Technische Aspekte einer Interaktion
3.1. Einführung
3.2. Architektur von WfMS
3.3. Kommunikation zwischen Systemen
3.4. Datenaustauschstandards

4. Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Workflow-Referenzmodell der WfMC (WfMC 1995, 20)

Abbildung 2: Funktionsweise der Client-Server Architektur in CORBA (Maurer 1997, 7)

Abbildung 3: Die Referenzarchitektur der OMA (Drawehn 1998, 58)

Abbildung 4: OSI Referenzmodell (Networkworld: OSI Referenzmodell)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einführung

1.1. Motivation

Workflow-Management Systeme (WfMS) steuern, überwachen und koordinieren die automatisierte, rechnerunterstützte Ausführung von Arbeitsabläufen in einer verteilten Systemumgebung (vgl. Bauer/Reichert/Dadam 2001, 1). Erhöhte Produktivität, Nachweisbarkeit sowie Auskunftsbereitschaft über die Prozesse und Qualitätssicherung im Unternehmen sind einige der Versprechen, die mit dem Einsatz von WfMS einhergehen (vgl. Böhm/Schulze 1995, 2).

Durch die zunehmende Globalisierung und damit verbundene Dezentralisierung von Organisationen stellt die Unterstützung komplexer, unternehmensweiter Workflows eine besondere Herausforderung dar (vgl. Reichert/Bauer/Dadam 2000, 1). Häufig sind in die Ausführung eines Workflows mehrere verschiedene WfMS involviert oder während der Ausführung werden neue Workflows auf anderen Systemen angestoßen. Zur effizienten Unterstützung solcher Szenarien ist eine Interaktion zwischen den Workflows, oder allgemeiner, zwischen verschiedenen WfMS notwendig.

1.2. Aufbau der Arbeit

Diese Arbeit wird wichtige technische Grundlagen zur Realisierung einer Interaktion von Workflows zwischen heterogenen WfMS^[1] einer Organisation analysieren.

Zu Beginn der Arbeit wird, ausgehend von den Anforderungen an eine Interaktion zwischen WfMS und der Frage nach dem Bedarf einer Standardisierung, die Workflow Management Coalition (WfMC) und deren Bemühungen um Interoperabilität zwischen WfMS dargestellt.

Der Hauptteil der Arbeit betrachtet die bei einer Interaktion heterogener WfMS auftretenden technischen Herausforderungen. Ausgehend von verschiedenen Architekturkonstellationen werden Standards der Kommunikation sowie des Datenaustausches näher beleuchtet.

Ein Fazit beschließt die Arbeit.

2. Grundlagen einer Interaktion

2.1. Anforderungen einer Interaktion zwischen WfMS

Um die Ausführung eines Workflows durch mehrere WfMS zu ermöglichen, sind bestimmte Voraussetzungen unumgänglich. Häufig laufen die involvierten WfMS auf heterogenen Plattformen oder sind räumlich verteilt (vgl. Leymann/Roller 2000, 25). Trotz allem müssen sie gewissen Anforderungen genügen.

Eine systemübergreifende Workflow-Ausführung erfordert zum einen, dass den WfMS die Prozessdefinitionen vorliegen bzw. zugänglich sind, zum anderen, dass die zur Ausführung benötigten Daten zwischen den Systemen ausgetauscht werden können.

Eine Kommunikation zwischen den Systemen sowie die eindeutige Interpretation der Kommunikationsinhalte bilden also die Basis einer Interaktion zwischen WfMS. Die große Anzahl verschiedener WfMS zwischen denen eine solche Interaktion auftreten kann, wirft die Frage auf, inwieweit es einer Standardisierung der betroffenen Schnittstellen bedarf.

2.2. Notwendigkeit einer Standardisierung?

Durch die Einführung einheitlicher, akzeptierter Normen könnte eine systemübergreifende Interaktion heterogener WfMS ermöglicht werden (vgl. Buxmann 2001, Slide 19). Die Nutzung von Standards kann die Kommunikation und den Datenaustausch zwischen den Systemen vereinfachen sowie die damit verbundenen Kosten verringern (vgl. Buxmann 2001, Slide 103). Probleme einer Standardisierung bestehen jedoch vor allem in der langwierigen Ausarbeitung, sowie in Akzeptanz und Umsetzung der Standards, da zahlreiche Interessen berücksichtigt werden müssen. Durch diese verschiedenen Interessengruppen gelingt zudem häufig nur eine Einigung auf den kleinsten gemeinsamen Nenner.

Ein einheitlicher Standard kann die Interaktion zwischen WfMS trotz allem enorm vereinfachen. Die Normierungsbemühungen im Bereich Workflow-Management (WfM) werden fast ausschließlich von der WfMC vorangetrieben. Dabei arbeitet die WfMC zum Teil mit anderen Standardisierungsgremien, z.B. der Object Management Group (OMG)^[2], zusammen.

2.3. Die Workflow Management Coalition

2.3.1. Das Workflow-Referenzmodell

Die WfMC ist ein Zusammenschluss aus WfM-Anbietern und -Interessengruppen, mit dem Ziel „standards for software terminilogy, interoperationality and connectivity between workflow products“ (WfMC, 2002) in einem heterogenen Umfeld zu etablieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Workflow-Referenzmodell der WfMC (WfMC 1995, 20)

Im Rahmen dieser Arbeit entwickelte die WfMC ein Referenzmodell (vgl. Abbildung 1), das die Konzepte, Terminologie und allgemeinen Strukturen sowie Komponenten eines WfMS beschreibt (vgl. WfMC 1995, 3).

Dieses Meta-Modell definiert einen zentralen Workflow Enactment Service mit einer oder mehreren Workflow Engines sowie fünf Schnittstellen. Die Gesamtheit wird auch als Workflow Application Programming Interface (WAPI) bezeichnet (vgl. Wewers 1997, 24).

Schnittstelle eins verbindet den Enactment Service mit einem Process Definition Tool, Schnittstelle zwei mit den Client Applications. Die dritte Schnittstelle steuert den Aufruf sowie die Datenversorgung von Anwendungssystemen. Schnittstelle vier regelt die Interoperabilität mit externen Workflow Enactment Services, und Schnittstelle fünf beschreibt die Verbindung zu Administration und Monitoring Tools (vgl. WfMC 1995, 27-45; Wewers 1997, 24).

2.3.2. Interoperabilität von WfMS

Ein Schwerpunkt der Arbeit der WfMC liegt in der Etablierung von Standards, die Interoperabilität zwischen WfMS herstellen sollen. Die WfMC definiert Interoperabilität als „the ability of two or more workflow engines to communicate and interoperate in order to coordinate and execute workflow process instances across those engines” (WfMC 1999a, 58).

Interoperabilität wird dabei kategorisiert in (vgl. WfMC 1999b, 2-3):

- direkte Interaktion zwischen Workflow Engines
- Interaktion zwischen Workflow Engines eines Enactment Services
- Interaktion zwischen Workflow Engines verschiedener Enactment Services.

Die WfMC unterscheidet zusätzlich Interoperabilität zwischen homogenen und heterogenen Systemen. Interaktion zwischen homogenen Produkten spielt jedoch eine untergeordnete Rolle, da die Ausführungs- und Austauschmechanismen in diesem Fall auf herstellerspezifischen, privaten Vereinbarungen beruhen können und somit keiner weiteren Standardisierung bedürfen (vgl. WfMC 1995, 22).

Die von der WfMC entwickelten Standards versuchen vor allem die Interoperabilität zwischen heterogenen Workflow Engines zu ermöglichen, also auch eine Interaktion von Workflows über die Grenzen eines einzelnen WfMS hinweg. Eine entscheidende Rolle spielen dabei insbesondere die Schnittstellen eins und vier des Referenzmodells.

2.3.3. Interface 1 – Process Definition Interchange & Process Definition Tools

2.3.3.1. Prozessdefinitionen

Eine Prozessdefinition ist die Repräsentation eines Geschäftsprozesses in einer Form, in der automatische Manipulation, wie Modellierung oder Ausführung, durch ein WfMS ermöglicht wird (vgl. WfMC 1999a, 11). Bestandteile einer Prozessdefinition sind Aktivitäten eines Workflows und deren Beziehung zueinander. Zusätzlich sind Kriterien über Start und Terminierung von Prozessen sowie konkrete Informationen über die einzelnen Aktivitäten enthalten, beispielsweise beteiligte Personen und Applikationen oder Worklfow-relevante Daten (vgl. WfMC 1999a, 11).

Weiterhin sind in einer Prozessdefinition Zugriffspfade und Datentypen von Applikationen sowie Übergangsbedingungen und Flussregeln spezifiziert, eine Prozessdefinition übernimmt dadurch auch Routing-Funktionen.

Prozessdefinition können zusätzlich Referenzen auf einen separat definierten Sub-Prozess oder zu externen Organisationsmodellen^[3] enthalten. Externe Organisationsmodelle sind insbesondere dann hilfreich, wenn Personen im Rahmen der Workflow-Ausführung von mehreren Systemen angesprochen werden, da alle WfMS für die Staff Resolution auf dieses eine Modell zurückgreifen können.

Um einen Geschäftsprozess der realen Welt in eine, durch WfMS interpretierbare Prozessdefinition umzuwandeln, bedient man sich eines Process Definiton Tools. Die Repräsentation des Geschäftsprozesses kann sowohl grafisch (z.B. Petri-Netze), als auch durch eine Definitionssprache (z.B. WPDL) erfolgen. Dieses Process Definition Tool kann Teil des WfMS oder eine stand-alone Applikation sein (vgl. WfMC 1998, 7-8). Falls es nicht Teil des WfMS ist, muss ein kompatibles, Austauschformat zum Workflow Enactment Service existieren.

Interface eins ermöglicht den Import bzw. Export von Prozessdefinitionen zwischen dem Process Definition Tool und dem Workflow Enactment Service. Dadurch wird eine Unhabhängigkeit zwischen Modellierung und Ausführung von Prozessen erreicht, auch über die Grenzen eines WfMS hinweg (vgl. Kaya 2001, 25).

2.3.3.2. Standardisierung von Interface 1

Die Standardisierung von Interface eins durch die WfMC ist bereits sehr ausgereift. Neben einem Meta-Modell, das die Kernobjekte der Prozessdefinition, deren Attribute und Beziehungen beschreibt, sind auch die dazugehörige Grammatik, in Form der Workflow Process Definition Language (WPDL), sowie API’s zur Manipulation der Prozessdefinitionsdaten definiert (siehe WfMC 1998, vgl. Kaya 2001, 25). Zusätzlich existiert bereits ein Entwurf zum Austausch von Prozessdefinitionen auf Basis von eXtensible Markup Language – XPDL.

Die Nutzung einer standardisierten Schnittstelle eins kann den erforderlichen Austausch von Prozessdefinitionen zwischen interagierenden WfMS vereinfachen bzw. überhaupt erst ermöglichen. Denkbar sind sowohl der Transport von Prozessdefinitionen zwischen den Systemen oder Speicherung in allgemein zugänglichen Repositories als auch die der Zugriff über allgemeingültige API’s (vgl. Kaya 2001, 25).

Der WfMC Standard für Interface eins liefert jedoch lediglich einen Minimalansatz zum Austausch von Prozessdefinitionen. Das vorgeschlagene Meta-Modell sollte dynamisch weiterentwickelt und in Bezug auf die bereitgestellte Funktionalität vergrößert werden.

Eine entscheidende Rolle in der künftigen Entwicklung könnte der XPDL-Entwurf spielen, da sich XML bereits heute weitestgehend etablieren konnte und insbesondere für einen standortübergreifenden Austausch geeignet scheint.

Problematisch ist jedoch, dass Aspekte der Aufbau- und Ablauforganisation bisher ungenügend berücksichtigt werden^[4] (vgl. Böhm/Schulze 1995, 16). Hier sind weitere Standardisierungsbemühungen erforderlich.

2.3.4. Interface 4 - Interoperability

2.3.4.1. Einführung

Interface vier des Referenzmodells beschreibt explizit die Interoperabilität zwischen WfMS in Form interagierender Workflow Enactment Services.

Eine Standardisierung dieser Schnittstelle ermöglicht den Unternehmen zum einen den Einsatz von WfMS unterschiedlicher Hersteller innerhalb der Organisation, zum anderen die Ausführung standortübergreifender Workflows durch mehrere, heterogene WfMS.

Durch eine Standardisierung wird das Ziel verfolgt, Sub-Workflows anderer WfMS starten, überwachen bzw. beenden zu können (vgl. Vossen 2001, Slide 569).

Die Bemühungen der WfMC haben bisher unter anderem eine abstrakte Spezifikation dieser Schnittstelle, eine MIME-Bindung bei der Nutzung von Internet e-Mail sowie eine XML-Spezifikation zur Umsetzung gewisser Interaktionsmodelle (vgl. 2.3.4.2) hervorgebracht.

In der abstrakten Spezifikation klassifiziert die WfMC Interoperabilität zwischen Software Systemen folgendermaßen (vgl. WfMC 1999b, 3-4):

- „direct interaction“ durch eine Menge standardisierter API’s
- „message passing“ unter Nutzung von Nachrichten und Containern
- „bridging“, als Einsatz eines Übersetzungsmechanismus zwischen den Formaten
- „use of a shared data store”, z.B. über allgemein zugängliche Repositories.

Zusätzlich werden verschiedene Modelle der Interaktion sowie acht Stufen von Interoperabilität zwischen WfMS definiert.

[...]

^[1] In dieser Arbeit wird nicht explizit auf die Interaktion homogener WfMS eingegangen, da dies lediglich einen Spezialfall darstellen würde.

^[2] Die OMG bemüht sich unter anderem um die Einbettung von Workflow-Funktionalität in die objektorientierte Architektur CORBA (vgl. 3.2.5.3.).

^[3] Organisationsmodelle enthalten die Entities einer Organisation und deren Beziehungen zueinander. Zusätzlich sind häufig noch Informationen über Rollen, Fähigkeiten, etc. enthalten. Organisationsmodelle werden häufig in externen Datenbanken oder Verzeichnissen realisiert, auf die WfMS für die Staff Resolution zugreifen (vgl. WfMC 1999a, 54-55).

^[4] Insbesondere die Integration von häufig vorhandenen externen Organisationsdatenbanken und das damit verbundene Problem der Staff-Resolution sollten genauer spezifiziert werden. Eine Möglichkeit könnte hier der Zugriff über einen normierter Directory Dienst, z.B. eine Erweiterung von X.500, sein (vgl. Böhm/Schulze 1995, 16).