Interorganizational Workflow Management E-Book

Karin Pargfrieder

• Herausgeber: GRIN Verlag
• Sprache: Englisch

Veröffentlichungsjahr: 2002

Beschreibung

Diploma Thesis from the year 2002 in the subject Computer Science - Commercial Information Technology, grade: very good, University of Linz (Applied Computer Science), language: English, abstract: Konventionelles Workflow Management beschränkt sich auf die Verbesserung der Effizienz von Geschäftsprozessen innerhalb einer Organisation. Jedoch sollten Prozesse auch dann elektronisch unterstützt werden können, wenn sie organisationale Grenzen überschreiten, wie z.B. in virtuellen Unternehmen. Wegen der speziellen Eigenschaften von interorganisationalen Workflows kann konventionelle Workflow Technologie nicht direkt angewendet werden. Die wichtigste Anforderung an interorganisationale Workflow Systeme ist klarerweise, Interoperabilität zwischen heterogenen Systemen zu erreichen. Sehr wichtig sind auch Vertraulichkeit der internen Prozesse und Sicherheit. Die vorliegende Diplomarbeit gibt eine Einführung in interorganisationales Workflow Management, seine Aspekte und Konzepte. Anforderungen an interorganisationale Workflow Systeme werden ausgearbeitet und die wichtigsten Ansätze, Projekte und Initiativen werden beschrieben: XML-basierte Ansätze, die Standards der WfMC, elektronische Marktplätze und elektronische Verträge. Eine Evaluierung dieser Ansätze anhand eines Kriterienkatalogs, der aus den Anforderungen und anderen Eigenschaften der Ansätze abgeleitet wird, zeigt die verschiedenen Stärken und Schwächen. Die XML-basierten Ansätze bieten Standards für die Schnittstellen der Prozesse und eine gute Lösung bzgl. Heterogenität. Manche von ihnen ermöglichen sogar die spontane Zusammenarbeit mit neuen Geschäftspartnern ohne vorherige Absprache. Traditioneller elektronischer Datenaustausch (EDI) ist vom Prinzip her ähnlich, hat aber viele Nachteile. Die Standards der WfMC ermöglichen einen sehr geringen Aufwand bei der Systemintegration, wenn sich die Anbieter daran halten. Aber Vertraulichkeit und Sicherheit sind potentielle Problemfelder und nur einfache Kooperationsmodelle werden unterstützt. Elektronische Marktplätze und elektronische Verträge sind ideal, wenn die Anzahl der Geschäftspartner hoch ist oder die Geschäftspartner abhängig von der jeweiligen Situation dynamisch gewählt werden sollen. Dazu müssen deren Services aber leicht vergleichbar sein und einfache Schnittstellen haben.

Leseprobe

Table of Content

5HTXLUHPHQWVVIRUUU ,QWHURUJDQL DWLRQDOO:RUNIORZZ0DQDJHPHQW

Page 1

Page 2

'DQNVDJXQJJ

Bedanken möchte ich mich bei Fr. Prof. Kappel für die Betreuung und ihre Anregungen zu Beginn der Diplomarbeit und bei Hr. Prof. Retschitzegger für die problemlose Übernahme der Betreuung nach ihrem Wechsel nach Wien. Vor allem möchte ich aber Hr. Dipl.-Ing. Kramler, der am meisten Einfluss auf die Arbeit hatte, meinen Dank für seine Vorschläge und seine Geduld aussprechen. Bei meinen Eltern möchte ich mich dafür bedanken, dass sie mir durch ihre jahrelange Unterstützung mein Studium ermöglicht haben und dass sie trotz Studienwechsel nicht den Glauben daran verloren haben, dass ich es letztendlich auch abschließen werde.

Page 3

.XU]IDVVXQJJ

Konventionelles Workflow Management beschränkt sich auf die Verbesserung der Effizienz von Geschäftsprozessen innerhalb einer Organisation. Jedoch sollten Prozesse auch dann elektronisch unterstützt werden können, wenn sie organisationale Grenzen überschreiten, wie z.B. in virtuellen Unternehmen. Wegen der speziellen Eigenschaften von interorganisationalen Workflows kann konventionelle Workflow Technologie nicht direkt angewendet werden. Die wichtigste Anforderung an interorganisationale Workflow Systeme ist klarerweise, Interoperabilität zwischen heterogenen Systemen zu erreichen. Sehr wichtig sind auch Vertraulichkeit der internen Prozesse und Sicherheit. Die vorliegende Diplomarbeit gibt eine Einführung in interorganisationales Workflow Management, seine Aspekte und Konzepte. Anforderungen an interorganisationale Workflow Systeme werden ausgearbeitet und die wichtigsten Ansätze, Projekte und Initiativen werden beschrieben: XML-basierte Ansätze, die Standards der WfMC, elektronische Marktplätze und elektronische Verträge. Eine Evaluierung dieser Ansätze anhand eines Kriterienkatalogs, der aus den Anforderungen und anderen Eigenschaften der Ansätze abgeleitet wird, zeigt die verschiedenen Stärken und Schwächen. Die XML-basierten Ansätze bieten Standards für die Schnittstellen der Prozesse und eine gute Lösung bzgl. Heterogenität. Manche von ihnen ermöglichen sogar die spontane Zusammenarbeit mit neuen Geschäftspartnern ohne vorherige Absprache. Traditioneller elektronischer Datenaustausch (EDI) ist vom Prinzip her ähnlich, hat aber viele Nachteile. Die Standards der WfMC ermöglichen einen sehr geringen Aufwand bei der Systemintegration, wenn sich die Anbieter daran halten. Aber Vertraulichkeit und Sicherheit sind potentielle Problemfelder und nur einfache Kooperationsmodelle werden unterstützt. Elektronische Marktplätze und elektronische Verträge sind ideal, wenn die Anzahl der Geschäftspartner hoch ist oder die Geschäftspartner abhängig von der jeweiligen Situation dynamisch gewählt werden sollen. Dazu müssen deren Services aber leicht vergleichbar sein und einfache Schnittstellen haben.

Page 4

$EVWUDFWW

Conventional workflow management focuses on improving the efficiency of business processes within one organization. However, processes should not only be supported within the enterprise, but also when crossing organizational boundaries, e.g. in order to support new forms of collaborations as virtual enterprises. Due to the different nature of interorganizational workflows, conventional workflow technology cannot be directly applied. The most important requirement specific to interorganizational workflow systems is obviously that they are able to deal with heterogeneity and that it is not too expensive to achieve interoperability. Also maintaining the privacy of internal processes is a major concern, and security issues should be addressed.

This diploma thesis gives an introduction to conventional and interorganizational workflow management, their aspects and concepts. It elaborates the requirements relevant for interorganizational workflow systems, describes the most important approaches, projects, and initiatives that currently exist in the area of interorganizational workflows, including XML-based approaches, the standards of the WfMC, electronic marketplaces and electronic contracting. An evaluation of these approaches based on criteria derived from the requirements and other characteristics shows the differing strengths and weaknesses. The XMLbased approaches provide standards for the process interfaces, and can cope with heterogeneous environments very well. Some of them even allow spontaneous commerce with new trading partners without custom integration. Traditional EDI is in principle similar, but has many disadvantages. The standards of the WfMC enable integration with a very low effort, if they are followed by software providers. But privacy and security are potential problem areas and the models of interoperability that realistically can be supported are simple. Electronic marketplaces and electronic contracting are ideal, if a high number of business partners has to be supported and the services are chosen dynamically depending on the situation. But these services have to be comparable with rather simple interfaces.

Page 8

/LVWWRII)LJXUHVV Figure 2-1. Types of Data in Workflow Management Systems [WfMC99a]...........12 Figure 2-2. Generic Workflow Product Structure [Holl95] .....................................20 Figure 3-1. Interorganizational Control Flow [DDDE00] ........................................28 Figure 3-2. Processes at Telco and Logis [DDDE00] ..............................................30 Figure 3-3. Horizontal and Vertical Partitioning......................................................31 Figure 3-4. Centralized Process Management [Aals00b] .........................................33 Figure 3-5. Chained Subprocesses [Aals00b]...........................................................34 Figure 3-6. Nested Subprocesses [Aals00b].............................................................35 Figure 3-7. The Parallel Synchronized Model of Interoperability [WfMC96].........37 Figure 3-8. Case Transfer [Aals00b] ........................................................................38 Figure 3-9. Example (Extended) Case Transfer .......................................................38 Figure 3-10. Loosely Coupled Processes [Aals00b].................................................40 Figure 3-11. Example Loosely Coupled Processes ..................................................40 Figure 3-12. Peer-to-Peer Collaborative Process Management [ChHs01] ...............41 Figure 3-13. Partitioning Dimensions of the Models of Workflow Interoperability 42 Figure 3-14. Models of Workflow Interoperability ..................................................43 Figure 4-1. Open-edi Reference Model [EdiI96]......................................................45 Figure 4-2. Three Levels of Standardization [Huem01b].........................................46 Figure 6-1. The Workflow Reference Model [Holl95] ............................................60 Figure 6-2. ACE-Flow System [SRKT00] ...............................................................69 Figure 6-3. Sequence in Bidding and Execution [SRKT00] ....................................72 Figure 6-4. Contract and Workflow Level [KGV00] ...............................................77 Figure 6-5. Making Contracts [KGV00] ..................................................................78 Figure 6-6. The CrossFlow Architecture [KGV00]..................................................80 Figure 6-7. Architecture of EVE and Example Workflow System [GeTo98]..........87 Figure 6-8. Multiple Vertical Connection [LiDe99].................................................90 Figure 6-9. Horizontal Connection of Three Fragments [LiDe99]...........................90 Figure 6-10. Partner Interface Process (RosettaNet) [ChHs01] ...............................95 Figure 6-11. The Common Business Library [GTM99].........................................101 Figure 6-12. Fragment of an XML Service Definition [GTM99] ..........................102

Page 9

/LVWWRII)LJXUHVV

Figure 6-13. Use of ebXML [Huem01b]................................................................105 Figure 6-14. High-Level Overview of ebXML Interaction between two Companies

[Mert01] ............................................................................................107 Figure 7-1. Supported Models of Interoperability ..................................................111 Figure 7-2. Overview..............................................................................................121

Page 10

Chapter 1

,QWURGXFWLRQQ

Conventional workflow management focuses on improving the efficiency of business processes within one organization. However, today’s corporations are challenged to cross organizational boundaries. Besides traditional business relations, as supplier, partner or customer, new forms of collaboration between enterprises come into existence due to increased competition and globalization, e.g. virtual enterprises or the trend to outsourcing.

Until recently, given the significant effort and investment required to deploy the necessary technology, business-to-business electronic commerce was a prerogative of large enterprises with well established commercial links. Nowadays, the advent of the Internet and the proliferation of inexpensive computing power in the form of clusters of workstations or PCs has changed this situation. Small and medium enterprises can now afford to engage in business-to-business electronic commerce by using the Internet to link their information processing systems. With the hardware infrastructure in place, there is a great demand for software support. The benefits expected from supporting not only internal, but also cross-organizational processes are e.g. reduced costs due to automation, the possibility to redesign and optimize processes and to benefit from increased competition between service providers.

But conventional workflow systems are primarily designed for intra-enterprise process management, and they can hardly be used to handle processes with tasks and

Page 11

,QWURGXFWLRQQ

data separated by enterprise boundaries, for reasons such as security, privacy, sharability, firewalls, etc.

New concepts to support cross-organizational processes are needed. There are numerous research issues in the field of interorganizational workflows, such as how to model these workflows and the virtual enterprise in which they are executed, how to deal effectively with heterogeneous workflow environments, how to provide wellspecified levels of autonomy of partners in a virtual enterprise, and how to support dynamic formation and dismantling of existing collaborations (a business partnership may be created dynamically and maintained only for the required duration such as a single transaction).

The approaches to interorganizational workflow are diverse: The work of the Workflow Management Coalition (WfMC) is focused on the technical level and provides a reference architecture and standard application programming interfaces (APIs) for workflow management systems (WfMSs). Traditional EDI and XMLbased approaches are interface based, and usually connect different WfMS by exchanging messages. Approaches like electronic marketplaces or electronic contracts introduce market brokers that match business partners and mediate between them.

The aim of this diploma thesis is to provide a description and evaluation of the most important approaches to interorganizational workflow management. Requirements have to be elaborated, which will be used as criteria for the evaluation. The diploma thesis is structured as follows:

Chapter 2 gives an introduction to conventional workflow management. Chapter 3 introduces into the area of interorganizational workflows and describes the different models of workflow interoperability in order to provide an overview, what different views on interorganizational workflows exist. It also contains examples for the different models.

Chapter 4 describes reference models for standardization activities in the area of EDI, which is closely related to interorganizational workflows. In Chapter 5, the requirements on systems that support interorganizational workflows are elaborated. They are grouped into build-time of the interorganizational workflow system and run-time.

Page 12

,QWURGXFWLRQQ

Chapter 6 describes the most important approaches, projects, and initiatives, which are evaluated in Chapter 7.

Finally, Chapter 8 concludes the diploma thesis with a summary, conclusion and outlook. Important terms are explained in a glossary.

Page 13

Chapter 2

:RUNIORZZ0DQDJHPHQWW

In this chapter, the term workflow management is explained and different functional and qualitative requirements for workflow management systems are discussed. The two main services each WfMS should support are workflow modeling and enactment. In order to be able to reason about and to optimize business processes, a third service has to be provided by a WfMS: workflow analysis. Modeling, analysis, and enactment of workflows are not sequentially ordered steps one following after the other, but are rather interleaved and incremental subtasks of workflow management. Afterwards, architectural issues for WfMSs will be introduced and the

'HILQLWLRQAZRUNIORZis 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. [WfMC99a]

'HILQLWLRQAZRUNIORZZ PDQDJHPHQWW V\VWHPis a system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. [WfMC99a]

This definition of a workflow management system follows the Workflow Reference Model of the WfMC (see Section 6.2.) However, there is only little agreement on what workflow management means and which features a workflow management system should provide. Therefore, the introduction to workflow management in this

Page 14

:RUNIORZZ0DQDJHPHQWW

chapter is not based on a certain system. Rather it is tried to describe the concepts independently from any system as far as possible. Therefore, it is an idealized view upon WfMS. Real WfMS will only offer parts of the functionality described. Since workflow technology seems essential for so many organizations, great research

efforts have been put on workflow management systems for several years. TheVWRU\\ RII ZRUNIORZZ PDQDJHPHQWW V\VWHPV- which originally have been named office information systems - goes back to the late 70ies, when Zisman presented a simple office procedure support system based on augmented petri-nets and e-mail technology [Zism77]. The boom, however, started almost ten years later, when technology was mature to meet at least some basic requirements of workflow management systems. Especially better hardware, computer networks, user-interfaces and databases provide a solid ground for workflow management systems. [Raus97] Computer support of analysis and execution of business processes is becoming more and more important for today’s business organizations in order to survive. Workflow management systems provide the technical basis for the support of business processes, i.e., they enable its computer-supported modeling and drive its execution

while keeping specified constraints. Among others, five basicLPSURYHPHQWVin the quality of the business process are expected from WfMS [Raus97]:

(IIHFWLYHQHVVSince a business process is explicitly represented within a •

WfMS, it can be more easily adapted to changing situations.(IILFLHQF\One of the most important criteria for efficient business processes •

is the reduction of the runtime of processes, e.g. by means of its parallelization, or by exchanging information between producer and consumer in-time.7UDQVSDUHQF\In WfMSs, information about the business process as well as •

data processed by it is available within the whole organization independent from its storage location.

&RQVLVWHQF\Due to control over processes and data, the WfMS is able to •

systematically maintain and monitor consistency requirements.,QQRYDWLRQThe installation of a WfMS within an organization requires •

reengineering of the organization’s basic business processes which usually results in improvements of their quality. [Raus97]

Page 15

:RUNIORZZ0DQDJHPHQWW

5HTXLUHPHQWVVRQ:I06VV

According to [Rein93], the main goal of a WfMS is the transparent integration of applications running on different nodes of a distributed system by means of control flow and data flow mechanisms. The terms applications and distributed system in this respect are not further restricted in size, etc. but are used in its most general meaning. In this context, the integration of arbitrary existing software components with new ones is of major concern. According to these goals, the following requirements have been derived by Jablonski and Reinwald [JabI95], [Rein93]. [Raus97]

'LVWULEXWLRQWorkflows are executed in a distributed environment. In big 1.

organizations, often a distributed system exists a priori, in which several WfMSs work together to execute the workflows of the organization. Thus, it has to be possible to transfer workflows from one WfMS to another for further execution.

2SHQQHVVTheWfMS has to be open in that pre-existing infrastructure within 2.

an organization can be incorporated into the business processes. First, it is essential that available, possibly heterogeneous application programs are reused for new business process applications. Only then, the user is able to interact with software she or he is acquainted with. Second, parts of the system have to be easily replaceable by other parts with the same or more functionality without having to change large parts of the whole software architecture. Closely related to this requirement are reusability of legacy systems, and easy maintainability and extensibility of the business process applications realized by the WfMS.

([SOLFLWW6SHFLILFDWLRQQRIIDDD3URFHGXUHH6FKHPDDThis schema should contain 3.

a description of the pre-existing nodes of the distributed system where activities are performed, including their contexts in which they are to be performed, i.e. required data, and the order of execution of these activities. For the latter, sequential as well as parallel execution has to be supported. To perform a certain activity, a node may call an application program or simply inform a user to perform a manual activity.

)OH[LELOLW\\DQGG'\QDPLFF&KDQJHOften it is necessary to change arbitrary 4.

aspects of the procedure schema, like the control flow, when the workflow is running. This should be possible without having to stop or to restart the workflow. Thus, concerning the control flow, the procedure schema must not

Page 16

:RUNIORZZ0DQDJHPHQWW

be a "hard-coded" sequence of activities, but rather has to allow to flexibly choose an appropriate subsequent activity on the basis of actual data. In particular, this is necessary to allow flexible exception handling by means of alternative activities. Similar mechanisms are also needed for the flexible assignment of application programs or users to activities.6XSSRUWWRII5ROHVRoles allow the specification of abstract organizational 5.

entities, i.e., a group of users from which a concrete user can be selected at run time according to the context of the activity to be performed. The support of roles, thus, allows the execution of activities of a workflow independently of the actual population of the organization.

'DWDD,QWHJUDWLRQQDQGG3UHSDUDWLRQOnevery start of an activity, that activity 6.

has to be provided with the actual context of the workflow, i.e., the complete set of input data needed for the activity to perform. For an editing process, for instance, the corresponding activity might have to be provided with the document to be edited. Input data may be provided by former activities, and output data may be needed as input data by subsequent activities. Thus, data sources which are used by different activities in order to exchange data and which may be distributed and represented heterogeneously within these activities have to be logically integrated. The WfMS is responsible for an automated system-controlled data flow within the distributed system and for proper conversion of these data as expected by the different activities.6\QFKURQL]DWLRQQRII$FWLYLWLHVSeveral workflows which are instances of the 7.

procedure schema may be running at the same time and compete for shared resources to process required activities. Thus, upon start of an activity, active workflows requesting that activity have to be synchronized. Note, that this synchronization is independent from the workflow-internal synchronization of two parallel activities having a common successor activity (as in Subsection 2.2.3.).

&RQFXUUHQF\\&RQWUROODQGG5HFRYHU\A workflow is inherently defined as 8.

cooperative task involving multiple users. Thus, consistency of data has to be ensured by means of concurrency control and recovery mechanisms similar to those of database systems.

3HUVLVWHQFHTypical workflows often last several months. In order to survive 9.

system crashes or temporary shutdowns of a WfMS, workflow relevant data including information about the current state of a workflow have to be persistent.

Page 17

:RUNIORZZ0DQDJHPHQWW

10.6HFXULW\Since workflows not only use public data, but also sensitive data, appropriate authorization mechanisms have to be provided to prohibit unauthorized access.

11.6FDODELOLW\For some application areas of WfMSs, a huge number of workflows has to be executed simultaneously. For example, in the area of electronic publishing [Blum93], [BQRT95], sometimes thousands of workflows are active concurrently. Also, the size of the distributed system is not restricted. Thus, scalability has to be a major concern.

12.3HUIRUPDQFHWfMSs have to be performant to guarantee efficient execution within the distributed environment. An increase in workload must not result in a proportional decrease of the processing speed. [Raus97]

:RUNIORZZ0RGHOLQJJ

This section presents a general model for the specification of workflows. In particular, the different aspects constituting a complete workflow description are discussed. [Raus97]

7KHH)XQFWLRQDOO$VSHFW:RUNIORZVVDQGG$FWLYLWLHVV

The functional aspect of a workflow description specifies what has to be executed. This is specified by means of workflow types which define logical units of execution. A workflow is an instance of a certain workflow type. It can be decomposed into smaller units, which can be further decomposed, and so on, until reaching elementary steps of execution. [Raus97]

A workflow which is used within another workflow is calledVXEZRUNIORZ,and a workflow using another workflow is calledVXSHUZRUNIORZ.A workflow at the outermost nesting level is called top-level workflow. Elementary workflows (or activities) are workflows at the lowest level of nesting and do not contain any subworkflow. They reference so-called applications (see Subsection 2.2.2.), whereas composite workflows contain further subworkflows. [Raus97]

Each workflow type is characterized by the followingSURSHUWLHV[Raus97]:1DPHuniquely identifies the workflow type. •

)RUPDOOZRUNIORZZSDUDPHWHUVAnalogous to procedures in programming •

languages, input as well as output parameters can be distinguished. The

Page 18

:RUNIORZZ0DQDJHPHQWW

parameters may be typed and may reference simple as well as complex data, like documents or drawings [KRSR97]

&RQVWUDLQWVAccording to [Jabl95], constraints may be classified into •

workflow-internal and workflow-external constraints. Examples for workflowinternal constraints are maximal duration of the workflow, preconditions or postconditions. A typical example for a workflow-external constraint is the synchronization of two workflows: Only after the first (external) workflow has reached a certain state, the execution of the second (constrained) workflow may be continued.

:RUNIORZZERG\The workflow body contains the actual specification of the •

different aspects mentioned above, including the specification of subworkflows. [Raus97]

How these execution units are implemented is specified by the operational aspect discussed in the following subsection.

7KHH2SHUDWLRQDOO$VSHFW$SSOLFDWLRQVV

Applications define how elementary workflows are implemented. Application in this context is used in its most general meaning, i.e. need not be a computer-supported task. Accordingly, several types of applications can be classified according to their

implementation: First, there are applications realized bySURJUDPV.The execution of such an application corresponds to the execution of the program or at least the call of

a function. Programs are further classified intoOHJDF\\SURJUDPVandDGDSWDEOH(or integratable)SURJUDPV.While the former can hardly be integrated into a workflow since they cannot be modified a posteriori, the latter may easily be adapted to the WfMS’s interface. Whether a program is started automatically or by a certain user, is specified as part of the organizational aspect (Subsection 2.2.5.). Second, there are

so-calledIUHHH DSSOLFDWLRQV.These applications are not realized by means of predefined, implemented programs, but are rather simple descriptions of some piece of work. The user may decide, whether he or she uses a program or some computer-supported tool to accomplish the requested task. In this way, manual work can be integrated into a workflow type. [Raus97]

Analogous to a workflow type, an application is defined by means of several

SURSHUWLHV[Raus97]:

1DPH,which uniquely identifies the application. •

Page 19

:RUNIORZZ0DQDJHPHQWW

• Input and outputSDUDPHWHUV

&RQVWUDLQWVfurther restricting the execution of the application analogous to • workflow type constraints.

$SSOLFDWLRQQERG\,which in case of programs simply references the program, •

and in case of manual tasks references the implementation of a wrapper that can be used to display parameters to the user or request them from the user. [Raus97]

7KHH%HKDYLRUDOO$VSHFW&RQWUROO)ORZZ

The behavioral aspect describes the control flow between the elements of a workflow, i.e. it defines when to execute a workflow or an activity in relation to each

other, respectively. For the definition of such dependencies, severalFRQWUROO IORZZ FRQVWUXFWVare used. Three basic control flow constructs are: sequence (serial execution), conditional branching (alternative execution) and unconditional branching (parallel execution). In case of alternative and parallel execution, some or all of the different execution paths are joined again at some later point. While in case of alternative execution no synchronization is necessary, parallel execution paths usually have to be synchronized at their ends, i.e. the subsequent activity may not be started before all preceding parallel activities have finished their execution. [Raus97]

However, often rather complex control flow descriptions have to be defined. In order to avoid large, confusing control flow descriptions realizing complex relationships between workflows and activities, it is thus inevitable to provide also higher level constructs. [Jabl95] suggests to provide macros which allow an application specific

definition ofKLJKHUU OHYHOO FRQWUROO IORZZ FRQVWUXFWV.They propose the following macros [Raus97]:

/RRSVlike while-do, repeat-until and for loops, as also known from • programming languages.

5HSHWLWLRQA subworkflow has to be repeated until a certain condition is true. •

The difference to a simple loop is that the various instances of the subworkflow may be initiated in parallel instead of executing them sequentially one after another.

2SWLRQDOO([HFXWLRQDepending on the context, an optional subworkflow is •

executed or skipped. A generalization of conditional branching is reached by