next up previous contents index
Next: Architektur Up: Aufgabenstellung Previous: Die Anforderungen an das

Workflow-Anwendungen

Am Beginn des FoPras stand die Suche nach Anwendungen, die in die Entwicklung des Workflow-Systems mit einbezogen werden können. Dabei sollten natürlich möglichst keine Kosten verursacht werden und die Anwendung muss den oben genannten Kriterien genügen. Insbesondere wäre ein graphisches Tool schön, mit dessen Hilfe man Workflow-Definitionen erzeugen und anpassen kann.

Eine gute Link-Sammlung zu verschiedenen Workflow-Produkten findet man unter http://www.do.isst.fhg.de/workflow/produkte/index.html. Da die meisten der dort aufgeführten Produkte inzwischen ein Web-Interface mit zumindest eingeschränktem Zugang zum Workflow-System bieten, werden im Folgenden die Produkte nach der Art der Datenhaltung bzw. dem zugrunde liegenden DBMS unterschieden.

Die meisten großen Software-Konzerne bieten Workflow-Produkte. Zum Teil basieren diese auf einer proprietären Produktumgebung, wie z. B. Exchange von Microsoft oder Domino von Lotus. Zusätzlich gibt es Drittanbieter, die für diese proprietären Umgebungen entsprechende Produkte entwickelt haben. Beispiele sind Pavone mit dem Workflow-System Espresso, welches auf Domino von Lotus basiert, und GFI Communications mit einem Produkt für Microsofts Exchange. Bei diesen Produkten hat man in der Regel die Möglichkeit über ein Web-Interface Zugang zum Workflow-System zu erhalten. Den Standardzugang stellen allerdings die entsprechenden Clients dar, wie Notes bzw. Outlook. Die Haltung der Daten ist absolut proprietär und deshalb für unsere Zwecke nicht geeignet. Außerdem sind sie teuer.

Eine große Gruppe bilden die Produkte, die auf einem eigenständigen DBMS beruhen. So bietet z. B. IBM das Produkt MQSeries Workflow, welches auf der eignen Datenbank DB2 beruht. Von Metastorm gibt es E-Work, das auf Oracle, MS-SQL oder Access aufsetzen kann. Leider finden sich hier keine Produkte, die auf nicht-kommerziellen DBMS aufsetzen. Nur Wave-Front behauptet, dass ihr Produkt FLOWer prinzipiell auf allen SQL-fähigen DBMS läuft. (Leider bietet es kein Web-Interface.) Alle dies Produkte bringen in der Regel ein graphisches Modellierungs-Tool mit, mit dessen Hilfe man nach dem Baukasten-Prinzip ein Workflow zusammenstellen kann. Dabei stecken z. B. bei EasyFlow von InformationsTechnologien GmbH Petri-Netze hinter der graphischen Modellierung. Auch diese Produkte sind mit gewissen Kosten verbunden.

Aus der Open-Source-Welt stammt OpenFlow, das leider erst am Anfang seiner Entwicklung steht. Es soll einmal folgende Features bieten:

OpenFlow basiert auf dem Application Server Zope, der ebenfalls Opensource ist. Zope ist im wesentlichen in Python geschrieben und kann durch Python-Objekte auch erweitert werden. Zope arbeitet mit jedem gängigen Webserver zusammen, bringt aber auch einen eigenen Webserver mit. Als Betriebssysteme sind Unix und Windows-NT geeignet, Datenbanken können über SQL und ODBC angebunden werden. Neben OpenFlow gibt es vor allem ``Slashdot''-ähnliche Projekte oder Community-Portalen, die mit Hilfe von Zope realisiert wurden. Zope als Basis für unser Workflow-System zu verwenden, schien uns zu aufwändig.

Da die kommerziellen Produkte auf Grund der Kosten und OpenFlow wegen der noch nicht sehr fortgeschrittenen Entwicklung als Unterstützung für das Workflow-System nicht in Frage kommen, musste die Anwendung komplett selbst entwickelt werden. Da auch kein graphisches Tool für das Erzeugen von Workflows gefunden wurde, haben wir uns dafür entschieden, für die Workflow-Definition XML-Files zu verwenden. Diese müssen von einem Perlskript abgearbeitet werden, das den Workflow in der Datenbank anlegt.

Für die Pflege und Wartung der in Betracht gezogenen, nicht kommerziellen DBMS gibt es folgende freie Projekte:


next up previous contents index
Next: Architektur Up: Aufgabenstellung Previous: Die Anforderungen an das
Copyright Munich Network Management Team