DE19955004A1 - Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows - Google Patents

Abstract

Die vorliegende Erfindung betrifft ein Verfahren für das Workload-Management in einem Workflow-Management-System (WFMS). DOLLAR A Die Erfindung schlägt ein erstes Verfahren vor, das automatisch mindestens einen Einklave-Graphen in einem Prozeßmodell eines Workflow-Management-Systems (WFMS) bestimmt. DOLLAR A Die Erfindung schlägt ein zweites Verfahren zur Ausführung der Enklave-Graphen vor. Das Verfahren enthält einen Enklave-Erstellungsschritt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten, die Bestandteile des Enklave-Graphen sind, erzeugt. Entsprechend enthält das Verfahren auch einen Enklave-Verbindungs-Schritt, indem das WFMS eine Aktivität des Enklave-Graphen im Namen der Aktivität mit der Workload-Management-Enklave im WLM verbindet. Außerdem enthält das Verfahren einen Enklave-Lösch-Schritt, in dem die Workload-Management-Enklave im Namen der Aktivitäten gelöscht wird.

Description

1 Hintergrund der Erfindung 1.1 Gegenstand der Erfindung

Die vorliegende Erfindung betrifft das Gebiet des Workload- /Leistungs-Management. Speziell geht es um ein Verfahren für das Workflow-Management in einem Workflow-Management-System (WFMS).

1.2 Beschreibung und Nachteile des Stands der Technik

Ein neuer Technologiebereich, der zunehmend an Bedeutung gewinnt, ist das Gebiet der Workflow-Management-Systeme (WFMS). WFMS unterstützen die Modellierung und Ausführung von Geschäftsprozessen. Geschäftsprozesse steuern, welche Arbeitseinheit aus einem Netzwerk von Arbeitsaufträgen von wem ausgeführt werden, und welche Ressourcen für diese Arbeit genutzt werden; d. h. ein Geschäftsablauf beschreibt, wie ein Unternehmen seine Unternehmensziele erreichen will. Die einzelnen Arbeitsaufträge können auf viele verschiedene Computersysteme verteilt sein, die durch ein Netzwerk miteinander verbunden sind.

Der Prozeß der Planung, Entwicklung und Herstellung eines neuen Produktes und der Prozeß der Änderung oder Anpassung eines vorhandenen Produktes konfrontiert Produktmanager und -ingenieure mit vielen Herausforderungen, um das Produkt zu den geringsten Kosten und innerhalb des Zeitplans auf den Markt zu bringen, und dabei gleichzeitig die Produktqualität beizubehalten oder sogar zu verbessern. Viele Unternehmen erkennen inzwischen, daß der traditionelle Produktplanungsprozeß diesen Bedürfnissen nicht gerecht wird. Sie fordern eine frühzeitige Beteiligung der Produktionsplanungs-, Kostenplanungs-, Logistikplanungs-, Einkaufs-, Produktions-, Service- und Support-Abteilung an der Planung. Außerdem ist eine Planung und Kontrolle von Produktdaten während der Planungs-, Markteinführungs- und Produktionsphase erforderlich.

Die korrekte und effiziente Durchführung von Geschäftsprozessen wie z. B. Entwicklungs- oder Produktionsprozessen in einem Unternehmen ist von größter Wichtigkeit für ein Unternehmen und hat einen wesentlichen Einfluß auf den Gesamterfolg des Unternehmens auf dem Markt. Diese Prozesse müssen deshalb in ähnlicher Weise wie Technologieprozesse betrachtet werden, und müssen getestet, optimiert und überwacht werden. Die Verwaltung solcher Prozesse wird in der Regel von einem computergestützten Prozeß oder einem Workflow-Management-System ausgeführt und unterstützt.

In D. J. Spoon: "Project Management Environment", IBM Technical Disclosure Bulletin, Bd. 32, Nr. 9A, Februar 1990, S. 250-254, wird eine Prozeßmanagement-Umgebung beschrieben, die aus einer Betriebsumgebung, Datenelementen sowie Anwendungsfunktionen und -prozessen besteht.

In R. T. Marshak: "IBMs FlowMark, Object-Oriented Workflow for Mission-Critical Applications", Workgroup Computing Report (USA), Bd. 17, Nr. S. 1994, S. 3-13, wird der Objektcharakter von IBM FlowMark als Client/Server-Produkt auf der Basis eines echten Objektmodells für eine missionskritische Produktionsprozeßanwendungs-Entwicklung und -Weiterentwicklung beschrieben.

In H. A. Inniss and J. H. Sheridan: "Workflow Management Based on an Object-Oriented Paradigm", IHM Technical Disclosure Bulletin, Bd. 37, Nr. 3, März 1994, S. 185, werden andere Aspekte der objektorientierten Modellierung von kundenspezifischer Anpassung und Änderungen beschrieben. In F. Leymann and D. Roller: "Business Process Management with FlowMark", Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, S. 230-234, wird der Stand der Technik auf dem Gebiet des Prozeßmanagement-Computerprogramms IBM FlowMark beschrieben. Das Metamodell von IBM FlowMark wird ebenso vorgestellt wie die Implementierung von IBM FlowMark. Hier werden die Möglichkeiten, die IBM FlowMark für die Modellierung von Geschäftsprozessen bietet, und ihre Ausführung erläutert. Das Software-Produkt IBM FlowMark steht für verschiedene Computerplattformen zur Verfügung, und Dokumentation zu IBM FlowMark ist in jeder IBM-Zweigstelle erhältlich.

In F. Leymann: "A meta model to support the modeling and execution of processes", Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Wien, Österreich, 21.-24. April 1992, World Scientific 1992, S. 287-294, wird ein Metamodell zur Steuerung von Geschäftsprozessen vorgestellt und ausführlich erläutert.

"IBM FIowMark for OS/2", Dokument Nummer GH 19-8215-01, IBM Corporation, 1994, das in jeder IBM Verkaufsstelle erhältlich ist, ist ein typisches modernes, ausgereiftes und leistungs­ fähiges Prozeßmanagementsystem. Es unterstützt die Modellierung von Geschäftsprozessen als Netzwerk von Aktivitäten; siehe beispielsweise " "Modeling Workflow", Dokument Nummer SH 19-8241, IBM Corporation, 1996. Als weitere Information zu Prozeßmanagementsystemen, die in IBM Verkaufs­ stellen erworben werden können seien folgende genannt: IBM MQSeries Concepts and Architecture, Dokument Nummer GH 12-6285; IBM MQSeries Getting Started with Buildtime, Dokument Nummer SH 12-6286; IBM MQSeries Getting Started with Runtime, Dokument Nummer SH 12-6287. Dieses Netzwerk von Aktivitäten, das Prozeßmodell, wird, als gerichteter, azyklischer, gewichteter, farbiger Graph erstellt. Die Knotenpunkte des Graphen stellen die ausgeführten Aktivitäten oder Arbeitseinheiten dar. Die Kanten des Graphen, die Steuerverbindungen, beschreiben die mögliche Ausführungsreihenfolge der Aktivitäten. Die Definition des Prozeßgraphen erfolgt in der IBM FlowMark Definition Language (FDL) oder mit dem integrierten Grafikeditor. Die Laufzeitkomponente des Prozeßmanagers interpretiert den Prozeßgraphen und verteilt die Ausführung von Aktivitäten auf die richtigen Personen an der richtigen Stelle, z. B. indem Aufgaben einer Arbeitsliste für die betreffende Person zugeordnet werden, wobei die Arbeitsliste in Form digitaler Daten innerhalb des Workflow-Management-Computersystems gespeichert wird.

In F. Leymann and W. Altenhuber: "Managing business processes as an information resource", IBM Systems Journal, Bd. 32(2), 1994, wird die mathematische Theorie, die dem Produkt IBM FlowMark zugrunde liegt, beschrieben.

In D. Roller: "Verifikation von Workflows in IBM FlowMark", in J. Becker und G. Vossen (Hrsg.):
"Geschäftsprozeßmodellierung und Workflows", International Thompson Publishing, 1995, wird die Notwendigkeit und Möglichkeit der Verifikation von Workflows beschrieben. Außerdem wird die grafische Animationsfunktion für die Verifikation der Prozeßlogik so wie sie in IBM FlowMark implementiert ist beschrieben.

Für die Implementierung eines computerbasierten Workflow- Management-Systems müssen zuerst die Geschäftsprozesse analysiert werden, und als Resultat dieser Analyse muß ein Prozeßmodell als Netzwerk von Aktivitäten erstellt werden, das dem Geschäftsprozeß entspricht. In IBM FlowMark werden die Prozeßmodelle nicht in eine ausführbare Form umgewandelt. Bei der Ausführung wird aus dem Prozeßmodell eine einzelne Ausprägung des Prozesses erstellt, eine sogenannte Prozeßausprägung. Diese Prozeßausprägung wird dann von IBM FlowMark dynamisch interpretiert.

Ein Benutzer interagiert mit einem Prozeßmanagementsystem typischerweise über eine grafische Benutzerschnittstelle, die die vom Benutzer auszuführenden Aufgaben als Piktogramme darstellt. Die Arbeit für eine bestimmte Aufgabe wird vom Benutzer durch einen Doppelklick auf das entsprechende Piktogramm gestartet, das seinerseits das Programm startet, das die Aktivität implementiert.

Ein anderer Technologiebereich ist das Leistungs- oder Work­ load-Management. Das Workload-Management versucht, die Verwendung der Prozessorressourcen von einem globalen Gesichtspunkt aus zu optimieren: Viele verschiedene Services (d. h. Programminstanzen) in einem System (entweder einem Einprozessorsystem oder einem Mehrprozessorsystem wie z. B. einem Sysplex) konkurrieren um Prozessorressourcen. Das Workload-Management ermöglicht die Angabe von Leistungszielen für jede Service-Klasse (einer Abstraktion von Services der gleichen Art) und für Gruppen von Serviceklassen (sog. Enklaven). Es können Prioritäten von Serviceklassen und Enklaven angegeben werden, um ihre relative Wichtigkeit aus der Sicht des Unternehmens zu definieren. Der Workload-Manager macht Verarbeitungsressourcen verfügbar, damit Services und Enklaven ihre Ziele erreichen können. Außerdem entzieht oder reduziert der Workload-Manager den Services und Enklaven Ressourcen, wenn klar wird, daß ein Service oder eine Enklave das vorgesehene Ziel nicht erreicht, daß aber ein anderer Service oder eine andere Enklave das vorgesehene Ziel erreichen kann, wenn ihr mehr Ressourcen zur Verfügung stehen, oder wenn ein Service oder eine Enklave mit höherer Priorität Gefahr läuft, wegen mangelnder Ressourcen das Ziel nicht zu erreichen. Deshalb verwaltet in jedem System das Workload- Management die Systemressourcen. Das Workload-Management koordiniert und verteilt die Leistungsinformation im System. Wie gut es ein System verwaltet hängt davon ab, wie gut die anderen Systeme ihre Ziele erreichen. Wenn es eine Konkurrenz um die Ressourcen gibt, schließt das Workload-Management die geeigneten Kompromisse anhand der Wichtigkeit der Arbeit und dem Abschneiden in bezug auf das Erreichen der Ziele.

Eine Enklave kann als eine Gruppe von Services betrachtet werden, die aus Unternehmenssicht zusammengehören, d. h. sie ist eine Arbeitseinheit, deren Bestandteile gemeinsam ein Leistungsziel erreichen müssen. Ein Beispiel hierfür wäre eine Gruppe von Anwendungsschritten, die ein Mitarbeiter ausführen muß, während ein Kunde auf eine Antwort wartet.

Nach dem Stand der Technik verfügen missionskritische Umgebungen über Workload-Manager (WLM). So besitzt beispielsweise MVS über einen eingebauten Workload-Manager mit dem Namen WLM/MVS. Weitere Informationen über diesen prominenten Vertreter eines Workload-Managers sind zum Beispiel der Veröffentlichung "03/390 MVS Planning: Workload Management, Dokument Nummer GC28-1761-02" zu entnehmen, die in den IBM Zweigstellen erhältlich ist.

Derzeit ist der Prozeß, der einem Programm die Teilnahme an einer Workload-Management-Umgebung ermöglicht, mühsam. Für einen WLM muß das Verwaltungspersonal beides angeben, Enklaven ebenso wie Leistungsziele für Services und Enklaven.

Anwendungsprogrammierer müssen WLM APIs verwenden, um bei der Ausführung ihrer Anwendungen dem WLM alle nötigen Informationen zur Verfügung zu stellen, damit er die Prozessorressourcen richtig verwalten kann.

Die Ableitung von Enklaven ist in nichttrivialen Fällen schwierig und mühsam, weil Informationen über die Beziehung zwischen Anwendungsfunktionen fehlen: Diese Informationen sind meist in speziellen Anwendungsprogrammen verborgen, oder die Beziehung ändert sich aufgrund neuer Anforderungen, weil Anwendungen zum Zweck der Interoperabilität auf neue Weise integriert werden. Je mehr verschiedene Anwendungen am Workload-Management teilhaben, desto komplexer wird die Situation. Noch schlimmer sieht es bei der Integration verschiedener Anwendungen aus, insbesondere wenn die Anwendungen ursprünglich nicht für eine Zusammenarbeit entwickelt wurden.

Jede einzelne Anwendung muß mit zusätzlichen Instruktionen ausgestattet werden, die mit dem WLM interagiert, sonst kann sie nicht am Workload-Management-Prozeß teilnehmen. Zum Beispiel müssen Anwendungsprogrammierer ihren Code über die API mit Instruktionen zum Erstellen, Verbinden und Beenden von Enklaven versehen. Dabei muß für jede der verschiedenen Anwendungsfunktionen überlegt werden, ob sie sich einer bestehende Enklave anschließen muß, und ggf. welcher Enklave, usw.

1.3 Aufgabe der Erfindung

Die vorliegende Erfindung basiert auf dem Ziel, Anwendungen besser am Workload-Management teilhaben zu lassen.

2. Kurzbeschreibung und Vorteile der Erfindung

Die Aufgaben der Erfindung werden durch Anspruch 1 erfüllt. Die Erfindung betrifft ein auf mindestens einem Computersystem ausgeführten Verfahren zur Bereitstellung eines Workload- Managements in einem Workflow-Management-System (WFMS) durch ein Workload-Management-System (WLM). Das WFMS enthält ein Prozeßmodell, das eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave-Graphen bilden, und in dem gerichtete Kanten des Enklave-Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren. In dem Verfahren müssen die Aktivitäten des Enklave-Graphen als Workload-Management-Enklave ausgeführt werden. Das Verfahren umfaßt einen Enklave-Erstellungsschritt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten erzeugt.

Mit der Erfindung ist die Festlegung und Ableitung von Enklaven wesentlich einfacher als nach dem Stand der Technik. Die Komplexität beim Schreiben von Anwendungsfunktionen, die vom WLM verwaltet und in Workload-Management-Einheiten (d. h. Enklaven) höherer Ebenen aufgenommen werden, wird drastisch reduziert. Zudem wird das WFMS um eine Workload-Management- Funktionalität erweitert.

Nach dem Stand der Technik nehmen WLM an, daß die verwaltete Anwendung eine selbstinstrumentierte Komponente ist. Dies bedeutet normalerweise, daß die Anwendung selber die WLM API verwenden muß, um Informationen mit der WLM-Umgebung auszutauschen. Dazu wären also invasive Änderungen vorhandener Anwendungen oder eine explizite Einfügung von Code in neu geschriebene Anwendungen erforderlich. Wegen diesem zusätzlichen Aufwand wäre der Einsatzbereich von WLM eingeschränkt. Schlimmer noch, die Instrumentierung ist nicht immer möglich; der Quellcode gehört vielleicht einer anderen Organisation oder ist nicht mehr vorhanden usw. Die vorliegende Erfindung macht es möglich, daß Anwendungen an WLM-Umgebungen teilhaben können, ohne daß sie speziell dafür instrumentiert werden müssen. Mit der vorliegenden Erfindung kann eine Anwendung in WLM-Umgebungen aufgenommen werden, ohne daß sie speziell dafür instrumentiert werden muß.

Die Grundidee der vorliegenden Erfindung besteht darin, die Anwendungsaktivitäten, die durch die Aktivitäten des Prozeßmodells repräsentiert werden, nicht zu instrumentieren. Die vorliegenden Erfindungen schlagen vor, die Workload- Manager-Enklave für die Aktivität im WLM vom WFMS erstellen zu lassen. Diese Lösung ermöglicht ein Workload-Management ohne jegliche Änderung der verwalteten Aktivität oder Anwendung. Deshalb muß kein zusätzlicher Code in neue oder bestehende Anwendungen aufgenommen werden, damit sie für ein Workload- Management geeignet sind. Das WFMS selber erteilt die geeigneten WLM-Aufrufe, um das Workload-Management für die Anwendung durchzuführen.

Auf dem Markt sind verschiedene, nicht miteinander kompatible WLM-Produkte erhältlich. Ohne die vorliegende Erfindung muß der Hersteller der Anwendung entscheiden, an welche der Systemverwaltungsumgebungen er sich halten soll; im schlimmsten Fall kann dies bedeuten, daß er alle berücksichtigen muß. Bei der vorliegenden Erfindung kann diese Entscheidung auf der Anwendungsintegrationsebene getroffen werden, d. h. auf der Ebene des Prozeßmodells. Da das WFMS darüber informiert ist, welche Anwendung es starten muß, ist die vorliegende Erfindung außerdem flexibel genug, die Entscheidung darüber, welches WLM-Produkt verwendet werden soll, auf der Basis jeder einzelnen Anwendung zu treffen. Nach der Lehre der Erfindung ist eine Anwendung also (bis zu einem gewissem Grad) vom speziellen WLM-Produkt losgelöst.

Aber nicht nur Anwendungen innerhalb eines Prozeßmodells profitieren von der vorliegenden Erfindung. Da es so viel einfacher wird, Aktivitäten für ein Workload-Management bereit zu machen, kann der Durchsatz in einem Computersystem allgemein erhöht werden; davon profitieren dann alle auf diesem Computersystem ausgeführten Programme.

Die richtige Verwaltung von Verarbeitungsressourcen reduziert die Gesamtkosten, die für Datenverarbeitungsumgebungen aufgewendet werden müssen. Anwendungssysteme, die für ein Workload-Management geeignet sind, werden in Umgebungen mit Workload-Management zu bevorzugten Systemen.

In einer anderen Ausführungsform der Erfindung enthält das Verfahren einen Enklave-Verbindungs-Schritt, in dem, wenn der Kontrollfluß in eine Aktivität eintritt, die ein Knoten in dem Enklave-Graphen ist und wenn für den Enklave-Graphen bereits eine Workload-Management-Enklave erstellt worden ist, das WFMS die Aktivität der Workload-Management-Enklave im WLM hinzufügt.

Die oben genannten Vorteile gelten auch für diese andere Ausführungsform. Außerdem nimmt die Erfindung den Aktivitäten/Anwendungen nicht nur die Erstellung von Workload- Management-Enklaven ab, sondern auch die Verbindung mit bereits vorhandenen Enklaven.

In einer weiteren Ausführungsform der Erfindung enthält das Verfahren einen Enklave-Lösch-Schritt, in dem, wenn der Kontrollfluß den Enklave-Graphen verlassen hat, der WLM die Workload-Management-Enklave für die Aktivitäten löscht.

Die oben genannten Vorteile gelten auch für diese andere Ausführungsform. Außerdem nimmt die Erfindung den Aktivitäten/Anwendungen nicht nur die Erstellung von Workload- Management-Enklaven ab, sondern auch das Löschen bereits vorhandener Enklaven. Somit sind alle Interaktionen einer Anwendung mit dem WLM, die nach dem Stand der Technik erforderlich sind, jetzt nicht mehr notwendig und werden vom WFMS übernommen.

In einer weiteren Ausführungsform der Erfindung wird den Aktivitäten eine Enklave-Identifikation der Workload- Management-Enklave verfügbar gemacht. Unabhängig davon wird, wenn eine Aktivität innerhalb einer Ausführungsumgebung auszuführen ist, der Ausführungsumgebung eine Enklave- Identifikation verfügbar gemacht.

Dadurch liegt es bei der Aktivität/Anwendung, ob das Workload- Management für sie "transparent" ist oder sie über die bereitgestellte Enklave-Identifikation beeinflussen kann. Der Ausführungsumgebung die Enklave-Identifikation der Workload- Management-Enklave zur Verfügung zu stellen ist besonders vorteilhaft, da bestimmte Ausführungsumgebungen als Subsysteme mit separaten Workload-Managern implementiert sind. Diese separaten Workload-Manager können mit dem globalen WLM zusammenarbeiten, benötigen dafür aber die Enklave- Identifikation einer Enklave im globalen WLM.

In einer weiteren Ausführungsform der Erfindung steht die Enklave-Identifikation der Workload-Management-Enklave als Element in einem Eingabe-Behälter (Input-Container) zur Verfügung.

Dies ist die eleganteste und wirtschaftlichste Art, die Enklave-Identifikation den Aktivitäten zur Verfügung zu stellen. Weitere Änderungen sind weder im WFMS noch in der Anwendung, in der die Aktivität implementiert ist, erforderlich, da dies der übliche Weg ist, der Aktivität Informationen aus dem WFMS zur Verfügung zu stellen.

In einer weiteren Ausführungsform der Erfindung wird das Verfahren von einer WFMS Engine ausgeführt, die durch das Prozessormodell navigiert, oder das Verfahren wird von einem WFMS-Agenten ausgeführt, der für das Starten einer Aktivität zuständig ist.

Die Ausführung des Verfahrens durch die WFMS Engine ist vorteilhaft, da alle Informationen über das Prozeßmodell (einschließlich aller Laufzeitparameter für eine aktuelle Prozeßmodellausprägung) - einschließlich der Struktur des Enklave-Graphen - der WFMS-Engine zur Verfügung stehen. Andererseits erlaubt die Ausführung des Verfahrens durch einen WFMS-Agenten die Auslagerung bestimmter Arbeiten aus der WFMS- Maschine, wodurch eine stärkere Parallelität innerhalb der WFMS-Umgebung erreicht wird.

Die Aufgaben der Erfindung werden durch Anspruch 7 erfüllt. Die Erfindung schlägt ein Verfahren vor, das automatisch mindestens einen Enklave-Graphen in einem Prozeßmodell eines Workflow-Management-Systems (WFMS) bestimmt. Das Prozeßmodell, enthält eine oder mehrere Aktivitäten, die die Knotenpunkte eines beliebigen Graphen sind, und in dem gerichtete Kanten des Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren. Der Enklave-Graph ist ein Subgraph des Graphen, der Aktivitäten enthält, die vom Workload- Management-System (WLM) als Workload-Management-Enklave zu behandeln sind. Das Verfahren bestimmt den Enklave-Graphen, indem es eine Aktivität in den Enklave-Graphen aufnimmt, falls das Prozeßmodell die Aktivität als ohne Benutzereingriff ausführbar definiert.

Die oben genannten Vorteile gelten auch für diese andere Ausführungsform. Weitere Vorteile ergeben sich dadurch, daß Anwendungsprogrammierer oder Administratoren jetzt auf ein automatisches Verfahren zur Bestimmung und Definition von Enklave-Strukturen zurückgreifen können. Was noch wichtiger ist: während nach dem Stand der Technik die Enklave-Struktur nicht explizit ist - jede Anwendung müßte analysiert werden, um die von den Anwendungen erstellten, gelöschten oder verbundenen Enklaven zu bestimmen -, macht die vorliegende Erfindung die Enklave- Struktur auf der globalen Ebene des Prozeßmodells explizit. Auf diese Weise sind die Enklave-Strukturen nicht länger in den einzelnen Anwendungen "begraben". Aufgrund der vorliegenden Erfindung können Enklave-Strukturen jetzt schnell erstellt oder geändert werden.

In einer weiteren Ausführungsform der Erfindung bestimmt das vorgeschlagene Verfahren den Enklave-Graphen, indem eine Aktivität in den Enklave-Graphen aufgenommen wird, wenn sie und alle anderen Aktivitäten des Enklave-Graphen Elemente der gleichen atomaren Sphäre sind, wobei die atomare Sphäre Aktivitäten enthält, die in einer Transaktion auszuführen sind.

Da globale Transaktionen Aktivitäten sind, die zu einer atomaren Sphäre gehören, unterliegen sie der ACID-Anforderung (Atomicity, Consistency, Isolation, Durability). Indem die Informationen im Prozeßmodell in bezug auf atomare Sphären zur Definition von Enklaven verwendet wird, kann der WLM bei der Ausführung die atomare Sphäre im Hinblick auf die ACID- Anforderung effizient ausführen.

3. Kurzbeschreibung der Zeichnungen

Fig. 1 ist ein Beispiel für die automatische Ableitung von Enklaven für ein Workload-Management-System (WLM) aus Prozeßmodellen eines Workflow-Management-Systems (WFMS).

Fig. 2 zeigt die neue Modellkonstruktion in der Definitionssprache FlowMark Definition Language (FDL) am Beispiel einer Enklave-Graphen-Definition.

Fig. 3 visualisiert bestimmte Szenarien innerhalb von Prozeßmodellen, die entweder Kandidaten oder keine Kandidaten für Enklave-Graphen sind.

4. Beschreibung der bevorzugten Ausführungsform

Die aktuelle Erfindung wird anhand des Workflow-Management- Systems FlowMark von IBM beschrieben. Selbstverständlich können auch andere WFMS verwendet werden. Außerdem gilt die Lehre der Erfindung auch für andere Arten von Systemen, die eine WFMS-Funktionalität nicht in Form eines separaten WFMS, sondern innerhalb eines anderen Systemtyps bieten.

Die gleiche Aussage gilt auch für das spezielle Workload- Management-System. Die vorliegende Spezifikation bezieht sich auf das Workload-Management-System von IBM unter OS/390 MVS; dies ist aber nur als Beispiel zu verstehen, nicht als Beschränkung des Umfangs der Erfindung.

4.1 Einführung in Workflow-Management-Systeme (WFMS)

Im folgenden werden die Grundbegriffe eines Workflow-Management- Systems anhand des WFMS IBM FlowMark skizziert.

Aus der Sicht eines Unternehmens wird die Verwaltung von Geschäftsprozessen immer wichtiger. Geschäftsprozesse oder kurz Prozesse steuern, welche Arbeitsaufgabe von wem ausgeführt wird, und welche Ressourcen dafür verwendet werden, d. h. ein Geschäftsprozeß beschreibt, wie ein Unternehmen seine Unternehmensziele erreichen will. Ein WFMS kann sowohl die Modellierung der Geschäftsprozesse als auch deren Ausführung unterstützen.

Die Modellierung eines Geschäftsprozesses als syntaktische Einheit auf eine Art und Weise, die direkt von einem Softwaresystem unterstützt wird, ist höchst erstrebenswert. Darüber hinaus kann das Softwaresytem auch als Interpreter arbeiten, der im wesentliche ein solches Modell als Eingabe erhält: Das Modell, als Prozeßmodell oder Workflow-Modell bezeichnet, kann dann als konkrete Ausprägung erzeugt werden, und die individuelle Reihenfolge der Arbeitsschritte kann in Abhängigkeit vom Kontext des speziellen Modellfalls bestimmt werden. Ein solches Modell eines Geschäftsprozesses kann als Schablone für eine Klasse ähnlicher Prozesse in einem Unternehmen aufgefaßt werden; es ist ein Schema, das alle möglichen Ausführungsvarianten einer bestimmten Art von Geschäftsprozessen beschreibt. Eine solche Modellausprägung und ihre Interpretation stellt einen individuellen Prozeß dar, d. h. eine konkrete, kontextabhängige Ausführung einer vom Modell beschriebenen Variante. Ein WFMS erleichtert die Verwaltung von Geschäftsprozessen. Es bietet ein Mittel, um Modelle von Geschäftsprozessen zu beschreiben (bei der Erstellung), und es steuert Geschäftsprozesse auf der Basis eines zugehörigen Modells (bei der Ausführung). Im folgenden wird das Metamodell von IBMs WFMS FlowMark, d. h. die Syntaxelemente zur Beschreibung des Geschäftsprozeßmodells und die Bedeutung und Interpretation dieser Syntaxelemente, beschrieben.

Ein Prozeßmodell ist eine vollständige Darstellung eines Prozesses, bestehend aus einem Prozeßdiagramm und den Einstellungen, die die Logik hinter den Komponenten des Diagramms definiert. Mit Hilfe verschiedener Services von FlowMark werden diese bei der Erstellung vorgenommenen Definitionen der Prozeßmodelle dann in Prozeßschablonen umgewandelt, auf die FlowMark bei der Ausführung zurückgreifen kann. Wichtige Komponenten eines FlowMark-Prozeßmodells sind:

• - Prozesse
• - Aktivitäten
• - Blöcke
• - Steuerflüsse
• - Verbindungen
• - Datenbehälter
• - Datenstrukturen
• - Bedingungen
• - Programme
• - Mitarbeiter

Nicht alle von diesen Elementen werden im folgenden beschrieben.

Vor diesem Hintergrund ist ein durch ein Prozeßmodell in FlowMark modellierter Prozeß eine Folge von Aktivitäten, die abgeschlossen werden müssen, um eine Aufgabe zu erfüllen. Der Prozeß ist das oberste Element eines FlowMark-Workflow- Modells. In einem FlowMark-Prozeß kann folgendes definiert werden:

• - Wie die Arbeit von einer Aktivität zur nächsten weitergehen soll.
• - Welche Personen die Aktivitäten ausführen sollen, und welche Programme sie dazu benutzen sollen.
• - Ob andere Prozesse, sogenannte Subprozesse, in den Prozeß verschachtelt sind.

Selbstverständlich können mehrere Prozeßfälle eines FlowMark- Prozesses parallel ausgeführt werden.

Aktivitäten sind die Grundelemente des Metamodells. Eine Aktivität stellt eine Geschäftsaktion dar, die aus einer bestimmten Perspektive eine eigene semantische Einheit bildet. Mit dem Modell des Geschäftsprozesses könnte sie eine Feinstruktur haben, die dann ihrerseits durch ein Modell repräsentiert wird, oder deren Details aus der Sicht der Geschäftsprozeßmodellierung überhaupt nicht relevant sind. Die Verfeinerung von Aktivitäten mit Hilfe von Prozeßmodellen ermöglichen eine Modellierung von Geschäftsprozessen von unten nach oben oder von oben nach unten. Aktivitäten, die einen Schritt innerhalb eines Prozesses darstellen, bilden eine Arbeitseinheit, die die zugeordnete Person ausführen kann, indem sie ein Programm oder einen anderen Prozeß startet. In einem Prozeßmodell sind jeder Aktivität folgende Informationen zugeordnet:

• - Welche Bedingungen erfüllt sein müssen, bevor die Aktivität beginnen kann.
• - Ob die Aktivität manuell von einem Benutzer gestartet werden muß, oder ob sie automatisch starten kann.
• - Welche Bedingung anzeigt, daß die Aktivität abgeschlossen ist.
• - Ob die Steuerung die Aktivität automatisch verlassen kann, oder ob die Aktivität zuerst von einem Benutzer als abgeschlossen bestätigt werden muß.
• - Wieviel Zeit für die Ausführung der Aktivität zur Verfügung steht.
• - Wer für die Ausführung der Aktivität zuständig ist.
• - Welches Programm oder welcher Prozeß zum Ausführen der Aktivität verwendet werden soll.
• - Welche Daten als Eingabedaten und als Ausgabedaten für die Aktivität benötigt werden.

Ein FlowMark-Prozeßmodell besteht aus folgenden Aktivitätstypen:
Programmaktivität: Ihr ist ein Programm zur Ausführung zugeordnet. Das Programm wird beim Starten der Aktivität aufgerufen. In einem vollautomatisierten Workflow führt das Programm die Aktivität ohne menschliches Zutun aus. Sonst muß der Benutzer die Aktivität starten, indem er sie aus einer Ausführungszeit-Arbeitsliste auswählt. Die Ausgabe des Programms kann in der Beendigungsbedingung für die Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden. Prozeßaktivität: Ihr ist ein (Sub-)Prozeß zur Ausführung zugeordnet. Der Prozeß wird beim Starten der Aktivität aufgerufen. Eine Prozeßaktivität ist eine Möglichkeit, eine Gruppe von Aktivitäten, die zu verschiedenen Prozessen gemeinsam gehört, wiederzuverwenden. Die Ausgabe des Prozesses kann in der Beendigungsbedingung für die Prozeßaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden.

Der Fluß von Steuerinformationen, d. h. Kontrollfluß, durch einen laufenden Prozeß bestimmt die Reihenfolge, in der Aktivitäten ausgeführt werden. Der FlowMark Workflow-Manager folgt einem Pfad durch den Prozeß, der durch die Bewertung, ob Startbedingungen, Endebedingungen und Übergangsbedingungen erfüllt sind, bestimmt wird.

Die Ergebnisse, die in der Regeln von der durch eine Aktivität repräsentierte Arbeit erzielt werden, werden in einen Ausgabebehälter (Output Container), der jeder Aktivität zugeordnet ist, geschrieben. Da eine Aktivität in der Regel auf Ausgabebehälter anderer Aktivitäten zugreifen können müssen, ist jeder Aktivität außerdem auch ein Eingabebehälter (Input Container) zugeordnet. Bei der Ausführung bilden die aktuellen Werte für die formalen Parameter, die den Eingabebehälter einer Aktivität aufbauen, den aktuellen Kontext einer Ausprägung der Aktivität. Jeder Datenbehälter wird durch eine Datenstruktur definiert. Eine Datenstruktur ist eine sortierte Liste von Variablen, den sog. Members, die mit einem Namen und einem Datentyp gekennzeichnet sind. Datenverbindungen repräsentieren den Transfer von Daten von Ausgabebehältern in Eingabebehälter. Wenn eine Datenverbindung einen Ausgabebehälter mit einem Eingabebehälter verbindet und die Datenstrukturen der beiden Behälter exakt übereinstimmen, bildet der Workflow-Manager von FlowMark die Daten automatisch ab.

Verbindungen (Connectors) verknüpfen Aktivitäten in einem Prozeßmodell miteinander. Mit Hilfe von Verbindungen kann man die Reihenfolge der Aktivitäten und die Datenübertragung zwischen den Aktivitäten definieren. Da Aktivitäten nicht beliebig ausgeführt werden können, sind sie durch Steuerverbindungen (Control Connectors) miteinander verbunden. Eine Steuerverbindung kann als direkte Linie zwischen zwei Aktivitäten betrachtet werden; die Aktivität am Endpunkt der Verbindung kann erst gestartet werden, wenn die Aktivität am Startpunkt der Verbindung (erfolgreich) abgeschlossen ist. Steuerverbindungen modellieren also den potentiellen Kontrollfluß innerhalb eines Geschäftsprozeßmodells. Standardverbindungen geben an, welchen Weg die Steuerung einschlagen soll, wenn die Übergangsbedingung keiner anderen Steuerverbindung, die eine Aktivität verläßt, erfüllt ist. Mit Hilfe von Standardverbindungen kann das Workflow-Modell außergewöhnliche Ereignisse verarbeiten. Datenverbindungen geben den Datenfluß in einem Workflow-Modell an. Eine Datenverbindung geht von einer Aktivität oder einem Block aus und hat eine Aktivität oder einen Block als Ziel. Man kann festlegen, daß Ausgabedaten zu einem Ziel oder zu mehreren Zielen geleitet werden können. Ein Ziel kann mehr als nur eine eingehende Datenverbindung haben.

Bedingungen sind das Mittel, mit dem der Kontrollfluß in einem Prozeß festgelegt werden kann. In FlowMark-Prozeßmodellen können logische Ausdrücke definiert werden, die bei der Ausführung von FlowMark bewertet werden, um festzustellen, wann eine Aktivität starten, enden und die Kontrolle an die nächste Aktivität weitergeben kann. Startbedingungen sind Bedingungen, die bestimmen, wann eine Aktivität mit eingehenden Steuerverbindungen starten kann. Die Startbedingung kann festlegen, daß alle eingehenden Steuerverbindungen erfüllt sein müssen, oder daß mindestens eine von ihnen erfüllt sein muß. Wie auch immer die Startbedingung lautet, müssen alle eingehenden Verbindungen bewertet werden, bevor die Aktivität starten kann. Wenn eine Aktivität keine eingehenden Steuerverbindungen besitzt, wird sie bereit, wenn der Prozeß oder Block, in dem sie enthalten ist, beginnt. Außerdem ist jeder Steuerverbindung ein Boolescher Ausdruck zugeordnet, der als Übergangsbedingung bezeichnet wird. Parameter aus Ausgabebehältern von Aktivitäten, die bereits ihre Ergebnisse hervorgebracht haben, werden als in Übergangsbedindungen genannte Parameter befolgt. Wenn bei der Ausführung eine Aktivität erfolgreich beendet wird, werden alle von ihr abgehenden Steuerverbindungen ermittelt, und der Wahrheitswert der betreffenden Übergangsbedingungen wird anhand der aktuellen Werte ihrer Parameter berechnet. Nur die Endpunkte von Steuerverbindungen, deren Übergangsbedingungen mit WAHR bewertet werden, werden als Aktivitäten betrachtet, die im aktuellen Kontext des Geschäftsprozesses ausgeführt werden können. Übergangsbedingungen modellieren also den kontextabhängigen tatsächlichen Kontrollfluß innerhalb eines Geschäftsprozesses (d. h. einer Ausprägung des Modells). Geschäftsprozesse beinhalten im allgemeinen lang dauernde Aktivitäten; bei solchen Aktivitäten muß eine Unterbrechung möglich sein. Die Beendigung einer Aktivität bedeutet deshalb nicht notwendigerweise, daß die zugehörige Aufgabe erfolgreich abgeschlossen worden ist. Um zu messen, ob die von einer Aktivität ausgeführte Arbeit erfolgreich war, ist jeder Aktivität ein Boolescher Ausdruck zugeordnet, der als Endebedingung bezeichnet wird. Genau diejenigen Aktivitäten, deren Endebedingungen im aktuellen Kontext als wahr bewertet werden, werden als erfolgreich beendete Aktivitäten behandelt. Zur Bestimmung des tatsächlichen Kontrollflusses werden genau die erfolgreich abgeschlossenen Aktivitäten herangezogen. Der logische Ausdruck einer Endebedingung, sofern ein solcher angegeben wurde, muß also mit wahr bewertet werden, daß die Kontrolle von einer Aktivität oder einem Block weitergegeben wird.

Ein Geschäftsprozeßmodell beschreibt nicht nur den potentiellen Steuerungs- und Datenfluß zwischen Aktivitäten eines Geschäftsprozeßmodells, sondern umfaßt auch eine Beschreibung der Abfolge der Aktivitäten selber zwischen "Ressourcen", die die von jeder Aktivität repräsentierten Arbeitsschritte tatsächlich ausführen. Eine Ressource kann als ein bestimmtes Programm, eine Person, eine Rolle oder eine organisatorische Einheit definiert werden. Bei der Ausführung werden Aufgaben aufgelöst in an bestimmte Personen gerichtete Aufforderungen, bestimmte Aktivitäten auszuführen, die Arbeitsschritte für diese Person zur Folge haben. Personenzuweisungen sind das Mittel, mit dem Aktivitäten in der vom Kontrollflußaspekt eines Geschäftsprozeßmodells vorgeschriebenen Reihenfolge auf die richtigen Personen verteilt werden. Jede Aktivität in einem Prozeß wird einer oder mehreren in der FlowMark-Datenbank definierten Personen zugeordnet. Unabhängig davon, ob eine Aktivität manuell vom Benutzer oder automatisch vom FlowMark-Workflow-Manager gestartet werden kann, und ob zum Beenden eine Interaktion mit dem Benutzer erforderlich ist oder die Aktivität automatisch beendet wird, muß ihr eine Person zugeordnet werden. Eine FlowMark-Personendefinition beinhaltet mehr als nur die Identifikation der in dem Unternehmen tätigen Personen in der FlowMark-Datenbank. Für jede definierte Person können eine Ebene, eine Organisation und mehrere Rollen angegeben werden. Diese Attribute können bei der Ausführung dazu benutzt werden, Aktivitäten dynamisch Personen mit geeigneten Attributen zuzuordnen.

Die Prozeßdefinition beinhaltet die Modellierung von Aktivitäten, Steuerverbindungen zwischen den Aktivitäten, Ein- /Ausgabebehältern und Datenverbindungen. Ein Prozeß wird als mit Richtungspfeil versehener, azyklischer Graph dargestellt, in dem die Aktivitäten die Knotenpunkte und die Steuer- /Datenverbindungen die Kanten bilden. Der Graph wird mit einem eingebauten, ereignisgesteuerten, CUA-konformen Grafikeditor bearbeitet. Die Datenbehälter werden als mit Namen gekennzeichnete Datenstrukturen angegeben. Diese Datenstrukturen selber werden mit der Datenstrukturdefinitions-Funktion festgelegt. FlowMark unterscheidet drei Haupttypen von Aktivitäten: Programmaktivitäten, Prozeßaktivitäten und Blöcke. Programmaktivitäten sind durch Programme implementiert. Die Programme werden mit der Programmdefinitions-Funktion registriert. Blöcke enthalten die gleichen Konstruktionen wie Prozesse, nämlich Aktivitäten, Steuerverbindungen usw. Sie haben aber keine Namen, und sie haben ihre eigenen Endebedingungen. Wenn die Endebedingung nicht erfüllt ist, wird der Block neu gestartet. Der Block implementiert also eine "Do Until"-Konstruktion (Ausführung, bis die Bedingung erfüllt ist). Prozeßaktivitäten sind als Prozesse implementiert. Diese Subprozesse werden separat als reguläre, mit Namen gekennzeichnete Prozesse mit allen üblichen Eigenschaften definiert. Prozeßaktivitäten bieten eine größere Flexibilität bei der Prozeßdefinition. Sie ermöglichen nicht nur die Konstruktion eines Prozesses durch permanente Verfeinerung von Aktivitäten in Programm- und Prozeßaktivitäten (von oben nach unten), sondern bauen einen Prozeß auch aus einer Gruppe vorhandener Prozesse auf (von unten nach oben). Insbesondere helfen Prozeßaktivitäten dabei, die Modellierung zu organisieren, wenn mehrere Prozeßmodellierer zusammenarbeiten. Sie ermöglichen den Team- Mitgliedern, unabhängig voneinander an verschiedenen Aktivitäten zu arbeiten. Programm- und Prozeßaktivitäten kann ein Zeitlimit zugeordnet werden. Das Zeitlimit gibt an, wie lange die Aktivität dauern darf. Wenn das Zeitlimit überschritten ist, wird eine bestimmte Person informiert. Wenn diese Person ihrerseits nicht innerhalb eines anderen Zeitlimits reagiert, wird der Prozeßadministrator benachrichtigt. Da alle Benachrichtigungen in einem Protokoll aufgezeichnet werden, hilft dies nicht nur, kritische Situationen zu erkennen, sondern auch, Unzulänglichkeiten des Prozesses zu bemerken.

Alle Datenstrukturen, die als Schablonen für die Behälter von Aktivitäten und Prozessen verwendet werden, werden mit der Datenstrukturdefinitions-Funktion definiert. Datenstrukturen sind Namen und werden in Form elementarer Datentypen definiert, z. B. als Gleitkommazahlen, ganze Zahlen, oder Zeichenfolgen und Verweise auf vorhandene Datenstrukturen. Daß Datenstrukturen als separate Einheiten verwaltet werden hat den Vorteil, daß alle Schnittstellen von Aktivitäten und ihre Implementationen konsistent an einer einzigen Stelle verwaltet werden (ähnlich wie Kopfdateien in Programmiersprachen).

Alle Programme, die Programmaktivitäten implementieren, werden mit der Programmregistrierungs-Funktion definiert. Registriert wird für jedes Programm der Programmname, der Ort, an dem es sich befindet, und die Zeichenfolge zum Aufrufen. Die Zeichenfolge zum Aufrufen des Programms besteht aus dem Programmnamen und der an das Programm übergebenen Befehlsfolge.

Bevor Prozeßausprägungen erstellt werden können, muß das Prozeßmodell umgewandelt werden, um seine Richtigkeit und Vollständigkeit sicherzustellen. Die umgewandelte Version des Modells wird als Schablone bei der Erstellung eines Prozeßexemplars verwendet. Auf diese Weise können Änderungen am Prozeßmodell vorgenommen werden, ohne daß gerade ausgeführte Prozeßausprägungen davon betroffen werden. Eine Prozeßausprägung wird entweder über die grafische Schnittstelle oder über die aufrufbare Prozeß-API (Anwendungsprogrammschnittstelle) gestartet. Wenn ein Prozeß gestartet wird, werden die Startaktivitäten gesucht, die richtigen Personen ermittelt und die Aktivitäten als Arbeitsaufträge auf die Arbeitsliste der ausgewählten Personen gesetzt. Wenn ein Benutzer den Arbeitsauftrag, d. h. die Aktivität, auswählt, wird diese ausgeführt und aus der Arbeitsliste anderer Benutzer, denen sie ebenfalls vorgelegt wurde, gelöscht. Wenn eine Aktivität ausgeführt worden ist, wird ihre Endebedingung bewertet. Ist diese Bedingung nicht erfüllt, wird die Aktivität erneut für die Ausführung eingeplant, andernfalls werden alle abgehenden Steuerverbindungen und die zugehörigen Übergangsbedingungen bewertet. Eine Steuerverbindung wird ausgewählt, wenn die Bedingung mit WAHR bewertet wird. Dann werden die Zielaktivitäten der ausgewählten Steuerverbindungen bewertet. Wenn ihre Startbedingungen erfüllt sind, werden sie auf die Arbeitsliste ausgewählter Personen gesetzt. Ein Prozeß wird als beendet betrachtet, wenn alle Endaktivitäten abgeschlossen sind. Um sicherzustellen, daß alle Endaktivitäten zum Abschluß kommen, wird eine Eliminierung toter Pfade vorgenommen. Dadurch werden alle Kanten im Prozeßgraphen, die wegen nicht erfüllter Übergangsbedingungen niemals erreicht werden können, gelöscht. Alle Informationen über den aktuellen Status eines Prozesses werden in der auf dem Server verwalteten Datenbank gespeichert. Dadurch ist im Fall eines Absturzes eine Vorwärts-Fehlerbehebung möglich.

4.2 Einführung in Workload-Management-Systeme (WLM)

Jede Computersystem-Installation will ihre Ressourcen möglichst gut nutzen und den höchstmöglichen Durchsatz erzielen, damit das System bestmöglich reagiert. Mit dem Workload-Management werden Leistungsziele definiert und jedem Leistungsziel eine Wichtigkeit für das Unternehmen zugeordnet. Man definiert die Ziele für die Arbeit aus Geschäftssicht, und das System entscheidet wieviele Ressourcen, wie z. B. CPU-Zeit und Speicherplatz, der Arbeit zugeteilt werden sollen, damit sie ihr Ziel erreicht. Eine Installation muß wissen, was in Form von Leistungszielen erreicht werden soll, und wie wichtig das Erreichen der einzelnen Leistungsziele für das Unternehmen ist. Mit dem Workload-Management werden Leistungsziele für Arbeiten definiert, und um diese Ziele zu erreichen paßt das System die Ressourcen an die Arbeit an, indem es die Verarbeitung ständig überwacht und neu anpaßt. Berichte zeigen, wie gut das System seine Ziele erreicht.

Im folgenden werden Begriffe und Verfahren anhand des OS/390 MVS Workload Management System von IBM erläutert.

Die Leistungsverwaltung (Performance Administration) ist der Prozeß der Definition und Anpassung von Leistungszielen und Ressourcengruppen auf der Basis von Geschäftszielen der Installation. Das Workload-Management führt die Rolle des Service-Level-Administrators ein. Der Service-Level- Administrator ist für die Definition der Leistungsziele der Installation auf der Basis von Bedürfnissen des Unternehmens und aktuellen Leistungsdaten zuständig. Diese explizite Definition von Workloads und Leistungszielen wird als Service- Definition bezeichnet. Die Service-Definition gilt für alle Arten von Arbeiten, z. B. für CICS, IBS, TSO/E, OpenEdition MVS, JES, APPC/MVS, LSFM, DDF, DB2, SOM, Internet- Verbindungsserver und andere. Man kann für alle von MVS verwalteten Arbeiten Ziele angeben, unabhängig davon, ob es sich um Online-Arbeiten, Transaktionen oder Stapeljobs handelt. Die in der Service-Definition definierten Ziele gelten für alle Arbeiten im System oder Sysplex. Wenn sich die Service-Level-Anforderungen ändern, kann der Service-Level- Administrator die betreffenden Workload-Management-Begriffe ändern. Das Workload-Management bietet eine online ausgeführte, anzeigebasierte Anwendung zum Definieren und Anpassen der Service-Definition. Die Service-Definition wird durch diese ISPF-Verwaltungsanwendung festgelegt. Das Workload-Management bietet die Möglichkeit, Leistungs- und Verzögerungsdaten im Kontext der Service-Definition zu sammeln. Die Leistungs- und Verzögerungsdaten sind für Berichte und Überwachungsprodukte verfügbar, so daß sie die gleiche Terminologie verwenden können.

Das Leistungs-Management (Performance Management) ist der Prozeß, mit dem das Workload-Management entscheidet, wie Ressourcen in Abhängigkeit von Leistungszielen und Verarbeitungskapazität verteilt werden. Workload-Management- Algorithmen benutzen die Informationen aus der Service- Definition und interne Überwachungsdaten, um festzustellen, wie gut die Ziele erreicht werden. Die Algorithmen passen die Ressourcenzuteilung in regelmäßigen Abständen an, wenn sich die Workload ändert. In jedem System verwaltet das Workload- Management die Systemressourcen. Das Workload-Management koordiniert und verteilt die Leistungsinformation im System oder Sysplex. Wie gut es ein System verwaltet hängt davon ab, wie gut die anderen Systeme ihre Ziele erreichen. Wenn es eine Konkurrenz um die Ressourcen gibt, schließt das Workload- Management die geeigneten Kompromisse anhand der Wichtigkeit der Arbeit und dem Abschneiden in bezug auf das Erreichen der Ziele. Das Workload-Management kann auch dynamisch Server­ adreßbereiche starten und stoppen, um Arbeiten von Anwendungsumgebungen zu verarbeiten. Das Workload-Management startet und stoppt Serveradreßbereiche in einem Einzelsystem oder im Sysplex, um die Ziele der Arbeits zu erfüllen. Zusätzlich zur internen Feedback-Überwachung verfolgt das Workload-Management das Geschehen im Sysplex in Form einer Echtzeiterfassung von Leistungsdaten und einer Überwachung von Verzögerungen. Alle diese Informationen stehen für die Leistungsüberwachung und Berichterstattung zur Aufnahme in detaillierte Berichte zur Verfügung.

Um das Workload-Management möglichst gut zu nutzen, muß die Arbeit richtig verteilt werden, so daß das MVS die Ressourcen verwalten kann. Es ist wichtig, daß die Subsysteme (mit separaten Ausführungsumgebungen), die die Arbeit verteilen, für die Workload-Verteilung in einem System oder Sysplex richtig konfiguriert sind. Dies ist besonders wichtig, wenn die Subsysteme separate Komponenten für die automatische und dynamische Verteilung der Arbeit besitzen, wie z. B. JES, CICS, IMS, DB2 usw. Dies wird mit den in den einzelnen Subsystemen vorhandenen Steuerungsmöglichkeiten erreicht. In einer JES- Umgebung beispielsweise werden Initiator-Adreßbereiche im System verteilt.

Die Service-Definition enthält alle Informationen über die Installation, die für die Verarbeitung durch das Workload- Management benötigt werden. Für jedes System oder Sysplex gibt es nur eine einzige Service-Definition. Der Service-Level- Administrator legt die Service-Definition mit Hilfe der WLM- Verwaltungsanwendung fest. Er erstellt "Regelsätze" innerhalb der Service-Definition, um die Ziele für Arbeiten festzulegen. Ein Service-Level-Administrator muß verstehen, wie Arbeit organisiert wird, und ihr Leistungsvorgaben zuordnen können. Eine Service-Definition identifiziert die Workloads, die Ressourcengruppen, die Serviceklassen, die Serviceklassenperioden und Ziele anhand der Leistungsvorgaben. Außerdem enthält eine Service-Definition Klassifizierungsregeln. Alle diese Informationen zusammen bilden die Service-Definitionsbasis. Dabei handelt es sich im einzelnen um folgende Informationen:

• - Ein oder mehrere Service-Regelsätze (Service Policies), bei denen es sich um mit Namen gekennzeichnete Gruppen von Leistungszielen handelt, die das Workload-Management als Richtlinie für die Zuteilung von Ressourcen für die einzelnen Arbeiten verwendet. Wenn ein Regelsatz aktiviert ist, werden die Überschreibungen mit der Service-Definition gemischt. Es können verschiedene Strategien zur Festlegung von Zielen vorhanden sein, die für verschiedene Zeiten bestimmt sind. Service-Strategien werden durch einen Bedienerbefehl oder durch die ISPF- Verwaltungsanwendungsfunktion aktiviert werden.
• - Workloads, die eine Gruppe von Serviceklassen zum Zweck der Berichterstellung zusammenfassen; d. h. eine Gruppe von Arbeiten, die gemeinsam verfolgt, überwacht und berichtet werden soll; außerdem eine Gruppe von Serviceklassen. Innerhalb einer Workload können Arbeiten mit ähnlichen Leistungsmerkmalen zu Serviceklassen zusammengefaßt werden. Eine Serviceklasse kann für Gruppen von Arbeiten erstellt werden, bei denen folgendes ähnlich ist:
  • - Leistungsziele
  • - Ressourcenbedarf
  • - unternehmerische Bedeutung für die Installation
• - Serviceklassen, die in Perioden unterteilt sind, fassen Gruppen von Arbeiten mit ähnlichen Zielen, ähnlicher Wichtigkeit für das Unternehmen, und ähnlichem Ressourcenbedarf zu Verwaltungs- und Berichtszwecken zusammen. Den Perioden innerhalb einer Serviceklasse werden Leistungsziele zugeordnet. Jeder Serviceklassenperiode wird ein Leistungsziel zugeordnet, z. B. eine gewünschte Antwortzeit, die eine Wichtigkeit anzeigt. Entscheidend ist, wie wichtig die Erreichung des Leistungsziels für das Unternehmen ist. Es gibt drei Arten von Zielen: Antwortzeit, Ausführungstempo und Ermessensfreiheit. Antwortzeitziele geben an, wie schnell die Arbeit verarbeitet werden soll. Da Antwortzeitziele nicht für jede Art von Arbeiten geeignet sind, z. B. bei lange dauernden Stapelverarbeitungsjobs, gibt es Ausführungsgeschwindigkeitsziele. Ausfüh­ rungsgeschwindigkeitsziele legen fest, wie schnell eine Arbeit ausgeführt werden soll, wenn sie bereit ist, ohne daß sie in bezug auf Prozessor-, Speicher- oder E/A-Zu­ griffe verzögert wird. Ausführungsgeschwindigkeitsziele sind für Arbeiten gedacht, für die Antwortzeitziele nicht geeignet sind, z. B. für gestartete Tasks oder lange laufende Stapelverarbeitungsjobs. Ermessensfreiheitsziele sind für Arbeiten mit niedriger Priorität gedacht, für die es kein spezielles Leistungsziel gibt. Das Workload- Management verarbeitet dann die Arbeit mit Hilfe von Ressourcen, die nicht von anderen Serviceklassen für die Erreichung ihrer Ziele benötigt werden. Da manche Arbeiten einen variablen Ressourcenbedarf haben, können für eine Serviceklasse mehrere Perioden definiert werden. Perioden sind eine Möglichkeit, verschiedene Ziele für eine Arbeit in Abhängigkeit von den von ihr beanspruchten Ressourcen zu definieren. Typischerweise werden Perioden dazu benutzt, kürzeren Transaktionen aggressivere Ziele und länger dauernden Arbeiten der gleichen Art weniger aggressive Ziele zuzuweisen. Es können mehrere Perioden vorhanden sein, wobei jede Periode mit Ausnahme der letzten eine Dauer hat. Die Dauer ist die Ressourcenmenge in Service- Einheiten, die die Arbeit beansprucht, bevor zu den Zielen der nächsten Periode umgeschaltet wird. Arbeiten können auch nach ihrem Ressourcenbedarf in Serviceklassen eingeteilt werden. Wenn man eine Gruppe von Stapelverarbeitungsarbeiten hat, die sehr viele Ressourcen beanspruchen können, und man diesen Ressourcenbedarf begrenzen will, kann man eine Serviceklasse definieren und sie einer Ressourcengruppe mit maximaler Kapazität zuordnen. Wenn die Arbeit diese Kapazität überschreitet, verringert das Workload- Management das Ausführungstempo. Auch wenn eine bestimmte Gruppe von Arbeiten nur minimale Prozessorkapazitäten benötigt, kann man für sie eine Serviceklasse definieren und diese einer Ressourcengruppe zuordnen.
• - Ressourcengruppen: eine Verarbeitungskapazitätsmenge in einem oder mehreren MVS-Abbildern, die einer oder mehreren Serviceklassen zugeordnet ist, die Grenzwerte für die Prozessorkapazität definiert. Einer Arbeit kann ein Minimalwert und ein Maximalwert von CPU-Service- Einheiten pro Sekunde zugeordnet werden, indem eine Serviceklasse einer Ressourcengruppe zugeordnet wird.
• - Klassifizierungsregeln, die bestimmen, wie eingehende Arbeiten einer Service- und Berichtsklasse zugeordnet wird.
• - Anwendungsumgebungen sind Ausführungsumgebungen, die aus Gruppen von Anwendungsfunktionen bestehen, die in Serveradreßbereichen ausgeführt und von einem Client angefordert werden können. Das Workload-Management verwaltet die Arbeiten gemäß dem definierten Ziel und startet und stoppt bei Bedarf automatisch Serveradreßbereiche.

Eine Enklave ist eine Arbeit, die wie eine Transaktion verarbeitet werden soll, die mehrere zuteilbare Einheiten (SRBs und Tasks) in einem oder mehreren Adreßbereichen umfassen kann und in ihrer Gesamtheit berichtet oder verwaltet wird. Die Enklave wird separat von dem Serveradreßbereich oder den Serveradreßbereichen, in denen sie ausgeführt wird, verwaltet. CPU- und E/A-Ressourcen zur Verarbeitung der Arbeit werden nach dem Leistungsziel der Arbeit verwaltet, für die Arbeit abgerechnet und der Arbeit berichtet. Ein Programm kann eine Enklave erstellen, SRBs in ihr planen oder Tasks in sie aufnehmen. Eine in einem einzigen Adreßbereich erstellte Enklave kann beliebig viele SRBs oder Tasks mit mehreren Adreßbereichen haben. Eine Enklaventransaktion erstreckt sich nur über ein einzelnes System. Dies bedeutet, daß eine Enklaventransaktion nicht auf einem anderen System fortgesetzt werden kann.

Eine Enklave kann verwendet werden, wenn eine Arbeit oder Transaktion, die mehrere Tasks oder SRBs in einem oder mehreren Adreßbereichen umfaßt, als Einheit verwaltet werden soll. Eine Enklave ermöglicht die Verwaltung und Berichterstellung über den Ressourcenverbrauch in der Enklave auf der Basis eines Leistungsziels, das nicht mit dem Leistungsziel oder den Leistungszielen des Adreßbereichs oder der Adreßbereiche, in denen die zuteilbaren Einheiten der Enklave ausgeführt werden, im Zusammenhang steht. Eine unabhängige Enklave stellte ein vollständige Transaktion dar. Ihr Leistungsziel wird anhand der Serviceklasse, der sie beider Erstellung der Enklave zugewiesen wird, zugeordnet. Jede unabhängige Enklave startet in Perioden ihrer Serviceklasse (oder PGN) und führt Periodenwechsel auf der Basis des von den zuteilbaren Einheiten der Enklave verbrauchten Service durch. Eine abhängige Enklave stellt die Fortsetzung einer bestehenden Adreßbereichstransaktion unter einer neuen Gruppe zuteilbarer Einheiten dar.

Ihr Leistungsziel wird aus der bestehenden Adreßbereichstransaktion anhand der Serviceklasse (oder PGN) und Periode übernommen, die zur Verwaltung des Adreßbereichs zum Zeitpunkt der Erstellung der abhängigen Enklave verwendet wird. CPU-Services, die von einer abhängigen Enklave beansprucht werden, werden so behandelt, als würden sie von der Adreßbereichstransaktion beansprucht, und können zur Folge haben, daß der Adreßbereich zusammen mit der abhängigen Enklave in eine spätere Periode überwechselt.

Eine Enklave muß erstellt werden, bevor sie an der Workload- Management-Umgebung teilhaben kann. Folgende Services, die von Anwendungsprogrammierern in der Anwendung codiert werden müssen, um mit Enklaven zu arbeiten, stehen zur Verfügung:

• - Das Makro IWMECREA ermöglicht die Erstellung einer Enklave.
• - Das Makro IEAMSCHD ermöglicht die Einplanung eines SRB in die bestehende Enklave.
• - Das Makro SYSEVENT ENCASSOC macht es möglich, daß eine Enklave SRBs ausführen kann, die einem Adreßbereich zuzuordnen sind, so daß die speicherbezogenen Ressourcen des Serveradreßbereichs für das Leistungsziel der Enklave verwaltet werden können.
• - Das Makro IWMEJOIN ermöglicht das Verbinden mit einer Enklave.
• - Das Makro IWMELEAV ermöglicht das Verlassen einer Enklave.
• - Das Makro IWMECQRY ermöglicht es einem Programm, die Klassifizierungsdaten für eine Enklave abzufragen.
• - Das Makro IWMESQRY liefert einem Programm Informationen darüber, ob die aktuelle zuteilbare Einheit zu einer Enklave gehört.
• - Das Makro IWMEDELE ermöglicht es einem Programm, eine zuvor erstellte Enklave zu löschen.

4.3 Die Lösung 4.3.1 Ableitung von Enklaven aus Prozeßmodellen

Prozeßmodelle z. B. im Workflow-Management-Systemen enthalten viele Informationen über die semantischen Beziehungen zwischen den Anwendungsfunktionen. Aufgrund der Tatsache, daß Enklaven Arbeitsaufträge sind, die "in optimaler Zeit" durch das System geschleust werden sollten, sind Sequenzen automatischer Aktivitäten (genauer: verbundene Graphen, die durch Zusammenfassung automatischer Aktivitäten definiert sind) und atomare Sphären (atomic spheres) (dies sind Zusammenfassungen von Transaktions-Arbeitseinheiten, d. h. Aktivitäten im Prozeßmodell mit einem gemeinsamen COMMIT-Umfang, die deshalb eine globale Transaktion bilden. Für den Zweck der Definition solcher atomaren Sphären kann das Prozeßmodell analysiert werden, um Subgraphen zu finden, die die Eigenschaft haben, daß ein solcher Subgraph nicht notwendigerweise verschiedene Aktivitäten enthalten muß, die durch einen Pfad von Steuerverbindungen verbunden sind, der mindestens eine nicht in der atomaren Sphäre enthaltene Aktivität enthält.) usw. Kandidaten für Enklaven. Die fundamentale Erkenntnis besteht darin, daß Enklavenkandidaten algorithmisch und automatisch aus Prozeßmodellen abgeleitet werden können.

Fig. 1 ist ein Beispiel für die automatische Ableitung von Enklaven für ein Workload-Management-System (WLM) aus Prozeßmodellen eines Workflow-Management-Systems (WFMS). Auf der linken Seiten von Fig. 1 ist ein Beispiel eines Prozeßmodells in einem WFMS zu sehen. Die Knoten stellen die Aktivitäten dar, und die Kanten die Steuerverbindungen. Aktivitäten, die im Prozeßmodell als automatisch ausführbar definiert sind, d. h. keine Interaktion mit dem Benutzer oder Eingabe von einem Benutzer benötigen, sind mit <auto< gekennzeichnet. Außerdem ist ein Subgraph (101) dargestellt, der im Prozeßmodell als atomare Sphäre definiert ist. Auf der linken Seite von Fig. 1 sind die Enklave-Graphen E1, E2, E3 dargestellt, die vom erfindungsgemäßen Verfahren automatisch generiert werden. Für die automatische Generierung von Enklave-Graphe werden zwei Ansätze vorgeschlagen:

• - Die Spezifikationen, die das Prozeßmodell ausmachen, werden auf "automatische" Aktivitäten analysiert. Subgraphen des Prozeßmodells wie E1 und E3, die "automatische" Aktivitäten enthalten, werden dann automatisch als Enklavegraphen definiert.
• - Die Spezifikationen, die das Prozeßmodell ausmachen, werden auf Aktivitäten mit "atomaren Sphären" analysiert. Subgraphen des Prozeßmodells wie E2, die Aktivitäten mit "atomaren Sphären" enthalten, werden dann automatisch als Enklavegraphen definiert.

Wenn die Enklavegraphen in einem Prozeßmodell definiert worden sind, schlägt die vorliegende Erfindung vor, daß das WFMS für die Aktivitäten im Enklavegraphen eine Workload-Management- Enklave im WLM erstellt; weitere Informationen dazu folgen weiter unten.

Kurz gesagt wird also in Fig. 1 gezeigt, wie aufeinanderfolgende Sequenzen von Aktivitäten, die im Prozeßmodell als automatisch zu startende Aktivitäten definiert worden sind, auf Enklaven (E1 und E3) abgebildet werden. Auch die atomische Sphäre AS-1 wird auf eine Enklave abgebildet, nämlich auf E2.

4.3.2 Enklaven als neue Modellkonstruktion innerhalb des WFMS

Zusätzlich zum obigen Ansatz, Enklavegraphen automatisch aus einem Prozeßmodell zu generieren, wird eine neue Konstruktion vorgeschlagen, die dem Workflow-Metamodell hinzugefügt werden kann und eine explizite Angabe von Enklaven im Workflow- Modellierungsprozeß ermöglicht. Diese explizit angegebenen Enklaven können natürlich auf den oben erwähnten Kriterien basieren. Außerdem kann der Ansatz, Enklavegraphen automatisch zu generieren, mit dem Ansatz, Enklavegraphen explizit anzugeben, kombiniert werden.

In Fig. 2 ist ein Beispiel für die Definition eines Enklave- Graphen in der Definitionssprache von FlowMark (FLD) dargestellt. Das neue Schlüsselwort ENCLAVE leitet die Definition eines Enklavegraphen ein; darauf folgt der Name des Enklavegraphen, in diesem Fall E3. Das Beispiel in Fig. 2 könnte die Spezifikation der Enklave E3 aus Fig. 1 sein. Das Schlüsselwort RELATED_CLASSIFICATION bezieht sich auf eine Serviceklassendefinition, in diesem Beispiel "DINKY", im WLM. RELATED_ACTIVITIES ist die Definitionskonstruktion zur Auflistung der Prozeßaktivitäten des Prozeßmodells, die als Enklavegraph behandelt werden sollen. Im vorliegenden Beispiel werden die Prozeßaktivitäten Pr_Act1, Pr_Act2, Pr_Act3 - siehe (102), (103), (104) in Fig. 1 - angegeben, um einen Enklavegraphen zu bilden. Auf die Schlüsselwörter DESCRIPTION und DOCUMENTATION folgen die Beschreibung und der Dokumentationstext.

Ansammlungen von Aktivitäten sind nicht nur aus Unternehmenssicht semantisch miteinander verwandt, sondern auch syntaktisch Kandidaten für die Definition als Enklave, die bei der Ausführung möglicherweise bei nacheinander oder parallel laufen. Ein Beispiel ist in Fig. 3 dargestellt: Sammlung C1 ist ein Kandidat für einen Enklavegraphen, da die einschlossenen Aktivitäten nacheinander ausgeführt werden können. C2 ist kein Kandidat, da Aktivität A ein Verbindungsknoten ist und es deshalb unwahrscheinlich ist, daß die Quellen seiner eingehenden Steuerverbindungen etwa zur gleichen Zeit enden - eine Voraussetzung dafür, daß nicht auf den Start von A gewartet werden muß. C3 ist ein Kandidat, da die parallelen Aktivitäten alle von der gleichen Steuerverbindungsquelle abhängig sind und somit etwa gleichzeitig gestartet werden.

Wenn beispielweise bekannt ist, daß es in einer Aktivitätengruppe, die als Kandidat in Frage kommt, eine lang andauernde Aktivität (wie z. B. eine Netzwerksitzung oder eine Editierungssitzung) gibt, so sollte diese Aktivität nicht Teil einer Enklave sein.

4.3.3 Festlegung von Enklaven durch ein WFMS

Das das WFMS zur Zeit der Ausführung über alle Informationen über die Enklaven (in dem Prozeßmodell) verfügt, kann es auch anstelle und im Namen der Aktivitäten, die Bestandteile eines Enklavegraphen sind, die Enklavengrenzen festlegen. Das WFMS (!) kann die Enklave starten, wenn der Steuerungsfluß erstmals in die Enklave eintritt. Es kann die Enklave beenden, wenn der Steuerungsfluß bereit ist, die Enklave zu verlassen, d. h. wenn klar ist, daß im Rahmen der aktuellen Enklave keine weitere Arbeit gestartet wird. Beim Aufrufen von Aktivitätsimplementationen im Rahmen einer Enklave kann er die Enklave für die Anwendungsfunktion verbinden. Wenn die vorliegende Erfindung das WFMS als Instanz zum Erstellen, Verbinden, Löschen usw. einer Enklave innerhalb des WLM vorschlägt, sind verschiedene Implementierungsvarianten möglich: entweder die Programmstartfunktion des WFMS (bei FlowMark der Program Execution Agent (PEA)), oder die Workflow Engine selber könnte entsprechend erweitert werden. Außerdem kann das WFMS die Enklaven-Identifikation für die Anwendungsfunktion, die die Prozeßaktivität implementiert, verfügbar machen (z. B. über eine spezielle API, oder indem es sie der Anwendung über ihren Eingabebehälter übergibt), so daß diese Funktion über die Enklave, zu der sie gehört, informiert ist. Das WFMS kann die Enklaven-Identifikationen auch an die Einheit übergeben, die die Funktionsumgebung der Anwendung bereitstellt (z. B. CICS, IMS) - d. h. an die Ausführungsumgebung der Anwendung -; dies ist wichtig, um diese Einheiten in die vorliegende Enklave aufzunehmen. Dies ist von besonderer Bedeutung, da bestimmte Ausführungsumgebungen als Subsysteme mit separaten Workload- Managern implementiert sind. Diese separaten Workload-Manager können mit dem globalen WLM zusammenarbeiten, benötigen dafür aber die Enklave-Identifikation einer Enklave im globalen WLM.

4.4 Vorteil

Mit der Erfindung ist die Festlegung und Ableitung von Enklaven wesentlich einfacher als nach dem Stand der Technik. Die Komplexität beim Schreiben von Anwendungsfunktionen, die von WLM verwaltet und in workload-verwaltete Einheiten (d. h. Enklaven) höherer Ebenen aufgenommen werden, wird drastisch reduziert.

Nach dem Stand der Technik nehmen WLM an, daß die verwaltete Anwendung eine selbstinstrumentierte Komponente ist. Dies bedeutet normalerweise, daß die Anwendung selber die WLM API verwenden muß, um Informationen mit der WLM-Umgebung auszutauschen. Dazu wären also invasive Änderungen vorhandener Anwendungen oder eine explizite Einfügung von Code in neu geschriebene Anwendungen erforderlich. Wegen diesem zusätzlichen Aufwand wäre der Einsatzbereich von WLM eingeschränkt. Der Hersteller einer Anwendung muß zum Beispiel entscheiden, an welche der vorhandenen WLM-Umgebungen er sich halten soll; im schlimmsten Fall kann dies bedeuten, daß er alle berücksichtigen muß. Schlimmer noch, die Instrumentierung ist nicht immer möglich; der Quellcode gehört vielleicht einer anderen Organisation oder ist nicht mehr vorhanden usw. Die vorliegende Erfindung macht es möglich, daß Anwendungen in WLM-Umgebungen aufgenommen werden können, ohne daß sie speziell dafür instrumentiert werden müssen.

Aber nicht nur Anwendungen innerhalb eines Prozeßmodells profitieren von der vorliegenden Erfindung. Da es so viel einfacher wird, Aktivitäten für ein Workload-Management bereit zu machen, kann der Durchsatz in einem Computersystem allgemein erhöht werden; davon profitieren dann alle auf diesem Computersystem ausgeführten Programme. Die richtige Verwaltung von Verarbeitungsressourcen reduziert die Gesamtkosten, die für Datenverarbeitungsumgebungen aufgewendet werden müssen. Anwendungssysteme, die für ein Workload-Management geeignet sind, werden in Umgebungen mit Workload-Management zu bevorzugten Systemen.

Claims (11)

1. Ein auf mindestens einem Computersystem ausgeführtes Verfahren zur Bereitstellung eines Workload-Managements in einem Workflow-Management-System (WFMS) durch ein Workload-Management-System (WLM),
wobei das WFMS ein Prozeßmodell enthält, das eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave-Graphen sind, und in dem gerichtete Kanten des Enklave-Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
in dem die Aktivitäten des Enklave-Graphen als Workload- Management-Enklave ausgeführt werden müssen,
wobei das Verfahren einen Enklave-Erstellungsschritt umfaßt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten erzeugt.

2. Ein Verfahren zur Bereitstellung eines Workload-Manage­ ments in einem Workflow-Management-System (WFMS) durch einen WLM nach Anspruch 1,
wobei das Verfahren einen Enklave-Verbindungs-Schritt enthält, in dem, wenn der Kontrollfluß in eine Aktivität eintritt, die ein Knoten in dem Enklave-Graphen ist, und wenn für den Enklave-Graphen bereits eine Workload- Management-Enklave erstellt worden ist, das WFMS die Aktivität mit der Workload-Management-Enklave im WLM hinzufügt.

3. Ein Verfahren zur Bereitstellung eines Workload- Managements in einem Workflow-Management-System (WFMS) durch einen WLM nach Anspruch 1 oder 2, wobei das Verfahren einen Enklave-Lösch-Schritt enthält, in dem, wenn der Steuerfluß den Enklave-Graphen verlassen hat, der WLM die Workload-Management-Enklave für die Aktivitäten löscht.

4. Ein Verfahren zur Bereitstellung eines Workload- Managements in einem Workflow-Management-System (WFMS) durch einen WLM nach einem der vorhergehenden Ansprüche,
in dem eine Enklaven-Identifikation der Workload-Manager- Enklave für die Aktivitäten verfügbar ist, und/oder
in dem, wenn eine Aktivität innerhalb einer Ausführungsumgebung auszuführen ist, eine Enklave- Identifikation der Workload-Management-Enklave für die Ausführungsumgebung verfügbar ist.

5. Ein Verfahren zur Bereitstellung eines Workload- Managements in einem Workflow-Management-System (WFMS) durch einen WLM nach einem der vorhergehenden Ansprüche, in dem die Enklave-Identifikation der Workload- Management-Enklave den Aktivitäten als Element in einem Eingabebehälter zur Verfügung gestellt wird.

6. Ein Verfahren zur Bereitstellung eines Workload- Managements in einem Workflow-Management-System (WFMS) durch einen WLM nach einem der vorhergehenden Ansprüche,
in dem das Verfahren durch eine WFMS Engine ausgeführt wird, die durch das Prozeßmodell navigiert, oder
in dem das Verfahren durch einen WFMS-Agenten ausgeführt wird, der für das Starten einer Aktivität zuständig ist.

7. Ein computerbasiertes Verfahren, das automatisch mindestens einen Enklave-Graphen in einem Prozeßmodell eines Workflow-Management-Systems (WFMS) bestimmt,
wobei das Prozeßmodell eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave- Graphen sind, und in dem gerichtete Kanten des Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
wobei der Enklave-Graph ein Subgraph des Graphen ist, der Aktivitäten enthält, die vom Workload-Management-System (WLM) als Workload-Management-Enklave zu behandeln sind,
wobei das Verfahren den Enklave-Graphen bestimmt, indem es eine Aktivität in den Enklave-Graphen aufnimmt, falls das Prozeßmodell die Aktivität als ohne Benutzereingriff ausführbar definiert.

8. Ein computerbasiertes Verfahren, das automatisch mindestens einen Enklave-Graphen in einem Prozeßmodell eines Workflow-Management-Systems (WFMS) nach Anspruch 7 bestimmt, wobei das Verfahren den Enklave-Graphen bestimmt, indem eine Aktivität in den Enklave-Graphen aufgenommen wird, wenn sie und alle anderen Aktivitäten des Enklave-Graphen Elemente der gleichen atomaren Sphäre sind, wobei die atomare Sphäre Aktivitäten enthält, die in einer Transaktion auszuführen sind.

9. Ein System, das Mittel für die Ausführung der Schritte des Verfahrens nach einem der Ansprüche 1 bis 8 enthält.

10. Ein Datenverarbeitungsprogramm zur Ausführung in einem Datenverarbeitungssystem mit Software-Code-Teilen zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8.

11. Ein auf einem von einem Computer verwendbaren Datenträger gespeichertes Computerprogrammprodukt, das von einem Computer lesbare Programm-Mittel enthält, um den Computer dazu zu veranlassen, ein Verfahren nach einem der Ansprüche 1 bis 8 auszuführen.