Citation
Achieving dynamic inter-organizational workflow management by integrating business processes, e-services, events, and rules

Material Information

Title:
Achieving dynamic inter-organizational workflow management by integrating business processes, e-services, events, and rules
Creator:
Meng, Jie ( Dissertant )
Su, Stanley Y. W. ( Thesis advisor )
Helal, Abdelsalam ( Thesis advisor )
Lam, Herman ( Reviewer )
Hammer, Joachim ( Reviewer )
Bai, Sherman ( Reviewer )
Place of Publication:
Gainesville, Fla.
Publisher:
University of Florida
Publication Date:
Copyright Date:
2002
Language:
English

Subjects

Subjects / Keywords:
Aggregation ( jstor )
Business models ( jstor )
Corporate policies ( jstor )
Corporations ( jstor )
Engines ( jstor )
Flow charting ( jstor )
Flow structures ( jstor )
Mathematical independent variables ( jstor )
Performing artists ( jstor )
Soaps ( jstor )
Business enterprises -- Computer networks -- Management
Computer and Information Science and Engineering thesis, Ph. D ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF ( lcsh )
Electronic commerce -- Computer programs ( lcsh )
Rule-based programming
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Abstract:
As the global marketplace becomes more and more competitive, business organizations often need to team up and operate as a virtual enterprise in order to utilize the best of their resources for achieving their common business goals. Since the business environment of a virtual enterprise is highly dynamic, it is necessary to develop a workflow management technology that is capable of handling dynamic workflows across enterprise boundaries. This dissertation describes a dynamic workflow model and a dynamic workflow management system for modeling and controlling the execution of inter-organizational business processes. In this work, all the sharable tasks performed by people or automated systems in a virtual enterprise are defined and published as e-services. The business process models of inter-organizational workflows are defined in terms of, among other things, compositions of e-services provided by the participating organizations. A dynamic workflow model (DWM) is introduced to enable the specification of dynamic properties associated with a business process model. It extends the underlying model of the Workflow Management Coalition's Workflow Process Definition Language (WPDL) by adding connectors, events, triggers, and rules as its modeling constructs, encapsulating activity definitions and allowing e-service requests to be included as a part of the activity specification. The workflow management system makes use of a business event and rule server to trigger business rules during the enactment of a workflow process model to enforce business constraints and policies and/or to modify the process model at run-time. We also introduce a constraint-based, dynamic service binding mechanism to dynamically bind e-service requests to e-services that satisfy some constraint specifications.
Thesis:
Thesis (Ph. D.)--University of Florida, 2002.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
General Note:
Title from title page of source document.
General Note:
Document formatted into pages; contains xii, 102 p.; also contains graphics.
General Note:
Includes vita.
Statement of Responsibility:
by Jie Meng.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
002825169 ( AlephBibNum )
51589072 ( OCLC )
ANV3713 ( NOTIS )

Downloads

This item has the following downloads:


Full Text











ACHIEVING DYNAMIC INTER-ORGANIZATIONAL WORKFLOW
MANAGEMENT BY INTEGRATING BUSINESS PROCESSES,
E-SERVICES, EVENTS, AND RULES















By

JIE MENG


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Jie Meng



























Dedicated to my parents and husband.















ACKNOWLEDGMENTS

First, I would like to express my gratitude towards Dr. Stanley Y.W. Su, chairman

of my supervisory committee, for his continuous guidance, advice, and support

throughout the course of my Ph.D. study, and for giving me the opportunity to work in

the Database Systems R&D Center. My great appreciation also goes to Dr. Abdelsalam

Helal, co-chairman of my supervisory committee, for constantly providing me with

valuable comments and suggestions during the dissertation work. I would like to thank

my supervisory committee members--Dr. Herman Lam for his constant help, suggestions,

and valuable discussions, and Dr. Joachim Hammer and Dr. Sherman Bai for their

precious time. Thanks also go to Sharon Grant for making the Database Center such a

pleasant place to work.

My wholehearted gratitude goes to my parents, Qingren Meng and Zhenping Ma,

for their unconditional love and continuous encouragement throughout my studies,

especially during these last two years. I also thank my husband, Chuntao Liao, whose

love and support helped me overcome many challenges during my Ph.D. study.

Finally, I thank all the colleagues and friends who helped me with inspiring

discussions and also for making my stay at the Database Systems R&D Center so

enjoyable. I wish them all the best in their studies and their future endeavors.

This research is supported by the NSF grant #EIA-0075284.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TABLES ............... ................. ............ .............. ........... viii

LIST OF FIGURES ......... .................................. ............ ........... ix

A B S T R A C T ............... ................................................................................. ............... ..... x i

CHAPTERS

1 IN TR O D U C TIO N ................. ................................ ........ ........ .................

2 RELATED W ORK ......................................................... ......... .......... ....... 5

2.1 W fM C's W orkflow Reference M odel .......................................... .............. 5
2.2 Workflow Design ............................... ........ ............. ............ 7
2.2.1 Process Modeling Methodologies.................. .......................... 7
2.2.2 Process Specification Languages and Definition Tools.................................. 8
2.2.3 WfMC's Workflow Process Definition Language (WPDL) ..................... 10
2.2.4 O organizational Structure ............................ .. ................................. 11
2.3 W orkflow E nactm ent .............. ................ .................................... .............. 12
2.3.1 Enactment System Architecture..................... ... ......................... 12
2.3.2 Ad Hoc Modification to Process Model ............................................. .. 14
2.4 Virtual Enterprise and Workflow Technology...... ......................................... 15
2.5 Web Service (E-Service) Related Technologies ............................................. 16

3 ARCHITECTURE OF DYNAFLOW......................................................................19

3.1 Overview of ISEE Infrastructure .................... ......................... ............ 19
3.2 G lobal A architecture of D ynaFlow .................................. ................................... 21
3 .3 S erv ers in D yn aF low .................................................................................... 2 3
3.3.1 Process D definition Tool ........................................... .......................... 23
3.3.2 K now ledge Profile M anager.................................... ................................... 24
3.3.3 W orkflow Engine ............................. ............................ .............. 25
3.3.4 E vent Server.................. ................................................ 25
3.3.5 E T R Server......... .............................................................................. 26
3.3.6 B roker Server ... .......................................................... .......... . .. 26
3.3.7 B roker Proxy ......... .... .................................................. ........................ .. 26









3.3.8 E -Service A dapter ...................................................... ..... ..... ..... 27
3.4 Functions of D ynaF low ............................................................................ ...... 27
3.4.1 B uild-tim e A ctivities................................................. ........... .............. 27
3.4.2 Run-tim e Activities............. ................. .............. 28

4 DYNAMIC WORKFLOW MODEL....................................... ......................... 29

4.1 E-Services ......................................... .................. .............. 29
4.1.1 E -Service Tem plate...................................................... ........... .............. 30
4.1.2 E-Service Constraint ....................................... 31
4.1.3 E-Service Request Constraint ..................................................................... 33
4.1.4 Constraint-based Brokering ..................................... ............. ................. 34
4.1.5 E -Service Invocation ................................................. ........... .............. 35
4.2 Dynamic Workflow Model ................... ........ ................... 38
4.3 W orkflow Event D definition .............. ......................................................... 43
4.4 D W M Specification .............. ..................................................................... 44
4.4.1 Process M odel D definition ........................................ .......... .............. 44
4 .4 .2 A ctiv ity ...................................................................... 4 6
4.4.2.1 Regular activity ........................................................ .... ...... .. 46
4.4.2.2 Begin-Activity and End-Activity........................................................ 50
4.4.2.3 Sam ple activity definition............................................... ................. 51
4.4.3 Subflow........................................................ 52
4.4.4 Connector...................................................... 52
4.4.5 Transition Inform ation ........................................................ ......... ..... 53
4.4.6 D ata Flow .................................................................... ......... 54
4 .4 .7 D ata C la ss ....................................................................... 5 5
4 .4 .8 E v ent In form ation .......................................................................................... 5 5
4.5 Dynamic Properties Provided by DWM................................................... 55
4 .5 .1 A ctiv e ..................................................... 5 6
4 .5.2 F lex ible ........................................ 56
4.5.3 A adaptive ................................. .......................... .................. 57
4.5.4 Custom izable............................ ........ .. ............................ .............. 58
4.6 Sample Scenario: Order Processing in a Supply Chain Community.................. 59

5 DESIGN AND IMPLEMENTATION ............................................................. 63

5.1 Design and Implementation of the Process Definition Tool................................. 63
5.1.1 Build-time Environment of DynaFlow ...................................................... 63
5.1.2 Design and Implementation of the Process Definition Tool.......................... 66
5.2 Design and Implementation of the Workflow Engine.............. ...................... 69
5.2.1 "Code Generation" Approach for the Workflow Engine............................ 70
5.2.2 Run-time Workflow Structures................... ........... ................. 71
5.2.2.1 Entity structures .. ................. ........................ .... .. .......... 71
5.2.2.2 Control flow structures ........................................ ....................... 72
5.2.2.3 D ata flow structures ............. ................. .......... ................. .......... 73
5.2.3 A activity Code ...... ........ ...... .................. ........................75









5.2.4 Design and Implementation of the Workflow Engine .................................. 78
5.2.4.1 Architecture of the Workflow Engine................... ................................ 78
5.2.4.2 Im plem entation details................................................ ... ...................... 79
5.2.4.3 Run-time modification to a business process model............................ 84

6 SUMMARY AND FUTURE WORK .............................................................. 87

6 .1 Su m m ary ..................................................... 87
6 .2 F u tu re W o rk .................................................................. ................................ 8 8

APPENDIX BNF FOR EXTENDED WPDL....................................... ............... 91

REFERENCES ................................. ... .. .... .... ................... .. 96

BIOGRAPHICAL SKETCH ........................................................... ........102
















LIST OF TABLES


Table Page

4-1: E-Service template of e-service OrderProcessing of Distributor................................31

4-2: The attributes of workflow events ................................................... ..................44
















LIST OF FIGURES



Figure Page

2-1: Workflow Reference Model--components and interfaces.................... ..................6

2-2: Top-level entities in workflow process definition of the Workflow Process
D definition Language (W PD L). ........................................................................ ...... 11

3 -1 : IS E E in frastru ctu re ............................................................................... ................ .. 2 0

3-2: G lobal architecture of D ynaFlow ................................................................................22

3-3: Architectural components of DynaFlow ................................. ............ ................... 24

4-1: Constraint specification for operation Process Order ..................................................33

4-2: A sample specification of an e-service request constraint............................................34

4-3: Build-time relationship among the Service Provider, the Broker Server, and the
Process D definition Tool ............................................................. 34

4-4: Run-tim e e-service invocation m mechanism ........................................ .....................36

4-5: SOAP messages for invocation of operation ProcessOrder in e-service
OrderProcessing ..................................................................... ..........37

4-6: W PD L business process m odel ............................................ .............................. 38

4-7: Business process m odel in D W M ........................................................ ............... 43

4-8: A sam ple activity definition ........................................ .............................................52

4-9: OrderProcessing model for Distributors in the Supply Chain Community .................60

5-1: Build-tim e environm ent of DynaFlow ..................................... ........... ........ ....... 65

5-2: The screen layout of the Process Definition Tool .....................................................66

5-3: Activity editor and e-service request editor............................................ .............68









5-4 : E ntity structure of an activity .............................................................. .....................7 1

5-5: Control flow structure of activity A2......................... .... ............. ...............73

5-6: Control flow structure of connector CheckJoin................................... ...............73

5-7: H ash table of control flow structures........................................................... .... ......... 74

5-8: D ata flow structure from A l to A 2........................................... .......................... 74

5-9: General structure of an activity code ...................................................... ............. 76

5-10: Architecture the W orkflow Engine ........................................ ......................... 80

5-11: Components in a Workflow Scheduler............................ .......................81

5-12: Runtime interactions between the Workflow Engine and other servers ....................85















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

ACHIEVING DYNAMIC INTER-ORGANIZATIONAL WORKFLOW
MANAGEMENT BY INTEGRATING BUSINESS PROCESSES,
E-SERVICES, EVENTS, AND RULES


By

Jie Meng

May 2002
Chairman: Dr. Stanley Y.W. Su
Cochairman: Dr. Abdelsalam Helal
Major Department: Computer and Information Science and Engineering

As the global marketplace becomes more and more competitive, business

organizations often need to team up and operate as a virtual enterprise in order to utilize

the best of their resources for achieving their common business goals. Since the business

environment of a virtual enterprise is highly dynamic, it is necessary to develop a

workflow management technology that is capable of handling dynamic workflows across

enterprise boundaries.

This dissertation describes a dynamic workflow model and a dynamic workflow

management system for modeling and controlling the execution of inter-organizational

business processes. In this work, all the sharable tasks performed by people or automated

systems in a virtual enterprise are defined and published as e-services. The business

process models of inter-organizational workflows are defined in terms of, among other

things, compositions of e-services provided by the participating organizations. A









dynamic workflow model (DWM) is introduced to enable the specification of dynamic

properties associated with a business process model. It extends the underlying model of

the Workflow Management Coalition's Workflow Process Definition Language (WPDL)

by adding connectors, events, triggers, and rules as its modeling constructs, encapsulating

activity definitions and allowing e-service requests to be included as a part of the activity

specification. The workflow management system makes use of a business event and rule

server to trigger business rules during the enactment of a workflow process model to

enforce business constraints and policies and/or to modify the process model at run-time.

We also introduce a constraint-based, dynamic service binding mechanism to

dynamically bind e-service requests to e-services that satisfy some constraint

specifications.














CHAPTER 1
INTRODUCTION

The advent of the Internet, World Wide Web, and distributed computing

technologies has enabled business organizations to conduct business electronically: thus,

the e-business was born. According to a white paper from Morgan Stanley Dean Witter

[PhiOO], there have been three major phases in the evolution of e-business technology. E-

business first appeared first in the form of EDI (Electronic Data Interchange) [Ada98].

The second phase of e-business was basic E-commerce, where retailers sell their products

through their Web sites. Phase three of e-business, currently in progress, is in the form of

eMarketPlace "portals," which bring trading partners with related interests together into a

common community (i.e., an exchange) to match buyers and sellers and provide other

services to serve their interests. The current trend is toward collaborative e-business in

which business organizations form virtual alliances under rapidly changing market

conditions and make use of the best of their resources for achieving their common

business goals. Business processes and application system services of the participating

organizations are important resources that need to be used to conduct a joint business.

Workflow technology is an enabling technology for managing, coordinating, and

controlling the activities of a virtual enterprise.

Workflow technology allows people and companies to model business processes

and to control the execution of these processes. Based on the definition given by the

Workflow Management Coalition (WfMC) [WfM99b], a business process is a set of









activities that collectively realizes a business goal, normally within the context of an

organization. Workflow is the automation of a business process, in whole or in part,

during which documents, information, or tasks are passed from one participant to another

for actions according to a set of procedural rules. A workflow management system

(WfMS) defines, creates, and manages the execution of workflows.

The term workflow originated in the mid-1980s and became popular in the early

1990s. Many vendors have introduced general-purpose workflow management systems.

In addition to the general-purpose workflow management systems, some other fields co-

opt workflow capabilities [She99]: e.g., Enterprise Resource Planning (ERP) and

Enterprise Application Integration (EAI) [Oba01]. With the emergence of e-business and

virtual enterprises, interest in workflow technology has escalated. In order to coordinate

different organizations in a virtual enterprise in a highly dynamic business environment, a

workflow management technology used in e-business environment has to be able to

handle workflows that are subject to changes and are distributed across organization

boundaries.

To meet the above requirement, we have developed a dynamic workflow model

(DWM) to enable the introduction of dynamic properties (i.e., active, customizable,

flexible, and adaptive properties) in a business process model. Here, DWM is the

mechanism for modeling business processes. It is analogous to the relational data model

used to model databases. It is an extension of the underlying model of the Workflow

Management Coalition's Workflow Process Definition Language (WPDL [WfM99a]) by

adding event, trigger, and rule to WPDL's modeling constructs. By doing so, we

integrate business events and business rules with business processes. The enactment of a









business process can post events to trigger the processing of business rules, which may in

turn enact other business processes (i.e., the active property). The processing of business

rules may also enforce customized business constraints and policies (i.e., customizable

property) and/or dynamically alter the process model at run-time (adaptive property). We

also separate control information (i.e., split and join) from activity definitions so that each

activity definition is encapsulated and reusable. In this work, we treat all the sharable

tasks performed by people or automated systems in a virtual enterprise as electronic

services (e-services). The e-services are categorized according to different business

types, for which standardized e-service templates are defined. Service providers register

their e-services with a broker by using the templates. E-service requests are specified in

the activity definitions of a process model. Their specifications are also based on the e-

service templates. E-service requests are bound to the proper service providers at run-

time by using the services of a broker to identify the suitable providers (i.e., the flexible

property). By using the above dynamic binding approach, process models are separated

from (i.e., not bound to) the specific service providers when they are defined. Changes in

the membership of a virtual enterprise (i.e., its service providers and their services) will

not affect the specifications of process models because the virtual enterprise has multiple

choices in finding suppliers and business partners. The integration of business processes

with business events and rules and the dynamic binding of e-services to service providers

give the proposed workflow management system its dynamic properties.

We have designed and implemented a dynamic workflow management system

called DynaFlow, which is part of an information infrastructure being developed for

supporting the Internet-based Scalable E-business Enterprise: the ISEE information









infrastructure [SuOlb]. We shall call the virtual enterprise that uses the ISEE information

infrastructure an ISEE virtual enterprise, and call the workflow system for an ISEE

virtual enterprise an ISEE workflow system. This dissertation presents a dynamic

workflow model and the implementation of a dynamic workflow management system.

An early version of the system was reported in our previous publication [Men02].

The organization of this dissertation is as follows. In Chapter 2, research related

to workflow and virtual enterprise is surveyed. In Chapter 3, the architecture of

DynaFlow is introduced. The e-service specification, dynamic workflow model, and the

extensions to WPDL are explained in Chapter 4. The design and implementation of the

key components of DynaFlow are given in Chapter 5. Chapter 6 summarizes our

research contributions and gives some suggestions for future research.














CHAPTER 2
RELATED WORK

We begin in this chapter with the introduction of the WfMC's Workflow

Reference Model. We then discuss the achievements and challenges in the workflow

area from two aspects: workflow design and workflow enactment. At the end of this

chapter, we introduce workflow research that is related to virtual enterprise and e-

business and e-service (web service) related technologies.


2.1 WfMC's Workflow Reference Model

The Workflow Management Coalition (WfMC) was founded in August 1993. It

is a not-for-profit, international organization of workflow vendors, users, analysts, and

university/research groups. The Coalition's mission is to promote and develop the use of

workflow through the establishment of standards for software terminology,

interoperability, and connectivity between workflow products.

The Workflow Reference Model has been developed from the generic workflow

application structure. The model identifies the interfaces within this structure, enabling

products to inter-operate at a variety of levels [WfM95]. The major components and

interfaces in the Workflow Reference Model can be seen in Figure 2-1.

The Coalition has developed a framework for the establishment of workflow

standards based on this reference model. The framework includes five categories of

interoperability and communication standards that will allow multiple workflow products

to coexist and inter-operate within a user's environment. The five categories of interfaces

are the following:
















W.JiL-floR r.P-land IrLcMhangc fiOiLmai. Interface 4
interface 5
W.rkfl.-.. Enactmen Serice Other Wodrflow
Administration Enactment Service(s)

Toots o! o-Vo
Engine(5)



Interface 2 Interface 3

Wodflow
IClient
lient Appioations

Figure 2-1: Workflow Reference Model--components and interfaces.

Interface 1 includes a common meta-model for describing the process definition

and a textual grammar for the interchange of process definitions (the Workflow Process

Definition Language or WPDL). It also includes APIs for the manipulation of process

definition data.

Interfaces 2 and 3 specify standard workflow management APIs that can be

supported by WFM products. These APIs provide a consistent method of access to WFM

functions in cross-product WFM Engines.

Interface 4 provides an abstract specification that defines the functionality

required to support the interoperability between different workflow engines.

Interface 5 specifies what information needs to be captured and recorded out of

the various events that occur during a workflow enactment.









2.2 Workflow Design

Workflow applications begin with workflow designs. Conceptually, a workflow

model consists of three different models: a process model, an information model, and an

organization model. Among them, the process model is the core. The main task of a

workflow design is to define process models.

A process model is an abstract or graphic representation of an organizational

process. Process modeling is a procedure that produces a process model, which serves as

the basis for a workflow specification. We focus our discussion on business process

models since our work focuses on business applications.

2.2.1 Process Modeling Methodologies

There are basically two categories of methodologies to model a business process,

namely, communication-based methodologies and activity-based methodologies [Geo95;

She96]. Communication-based methodologies stem from the Conversation for Action

model proposed by Winograd and Flores [Win87], in which the process of coordination is

represented as a finite-state machine. In these methodologies, an action in a workflow is

represented by the communication between a customer and a performer. The resulting

organizational process reveals a social network in which a group of people, assuming

various roles, fulfills an organizational process.

Activity-based methodologies focus on modeling activities instead of modeling

the communications among people. In this approach, the overall process is decomposed

into tasks that are ordered based on the dependencies among them. An organizational

process modeled with this approach is then reduced to a network of activities and

subprocesses. Workflow management systems typically adopt activity-based

methodologies. For example, in IBM's MQ Workflow [Ley94; IBMOO], a process









consists of activities, including program activities, process activities (subprocess), and

block activities (i.e., a set of activities that can be repeated until an exit condition is met).

The dependencies among these activities are captured by control connectors (control

dependencies) and data connectors (data dependencies).

Like most workflow systems, we adopt activity-based methodologies for process

modeling in our workflow system.

2.2.2 Process Specification Languages and Definition Tools

Process models are specified in some workflow specification language. A

workflow specification language uses rules, constraints, and/or structural constructs to

capture the dependencies among the activities, and uses activity attributes to describe the

properties of activities. No matter which way a workflow system specifies a process

model, the activity structure (control flow) and the information exchange between

activities (data flow) are necessary parts of process modeling.

Most workflow management systems use a graphic specification language for

process modeling. In a process graph, activities are connected by arrows and routing

elements. Examples of such systems include the Build-time of IBM's MQSeries

Workflow [IBMOO], the process modeling environment of Vitria's Businessware

[VITO01], and METEOR Designer of METEOR2 (developed at the University of Georgia)

[She97].

Some workflow management systems provide rule-based or constraint-based

specification languages. For example, EvE project [Gep98] uses events and Event-

Condition-Action (ECA) rules as the fundamental concepts for defining and enforcing

workflow logic. Other workflow specification methods include Petri Nets [Mur89],

Finite State Automata [Pel94], and Computation Tree Logic [Eme90]. A new kind of









high-level Petri net, XML Net, is proposed by Lenz and Oberweis [LenOl] to support

inter-organizational process modeling.

In addition to specifying control flows and data flows in process models, a

workflow specification language may also support the specification of other properties of

business processes. For example, the modeling language in the WIDE project [Cas96]

supports specifications of exception handling and transactional properties. With respect

to exception support, the model specification allows the definition of ECA rules to

support exceptional and asynchronous behavior during workflow enactment. With

respect to transactional support, the model specification provides transactional constructs

so that the designer can group different activities to achieve atomicity, and also allows

the possibility of defining compensation activities for those activities that need to be

rolled back. In the CrossFlow project [Gre99; Cro00], in addition to defining the normal

workflow structure, execution alternatives called flexible elements, can also be defined in

a process model. Different from the OR-split/join structures, the decision of whether or

not these flexible elements are executed at run-time is based, not on the transactional

conditions, but on the global goal of the workflow.

To capture dynamic properties of business processes, the dynamic workflow

model and the dynamic workflow management system presented in this dissertation

integrate both business events and business rules with business processes. Synchronous

events are open points in a process model where the business rules can be attached and be

activated to adapt to a changing business environment. This is a new approach to support

dynamic workflow.









2.2.3 WfMC's Workflow Process Definition Language (WPDL)

Although most workflow management systems define their process models using

activity-based methodologies, workflow specifications for process models vary greatly in

different workflow systems. This can become a hurdle in the integration of different

workflow systems. The need for standardization arises. Among current standardization

efforts, WfMC's WPDL [WfM99a] is the well-accepted one.

In WfMC's Workflow Reference Model, Interface 1 includes a common meta-

model for describing the process definition and a textual grammar for the interchange of

process definitions (WPDL) [WfM99a]. Interface 1 focuses on the specification of a

process definition meta-model. This meta model identifies the basic set of entities and

attributes used in the exchange of process definitions. In this model, a workflow process

contains one or more workflow process activities. The activities are associated with

workflow applications and workflow participants. Transitions that connect these

activities determine the control flow of a workflow process. Transitional conditions can

be defined to specify the flow or execution conditions. A variety of attributes describe

the characteristics of this limited set of entities. Based on this model, vendor specific

tools can transfer models via a common exchange format. The top-level entities

contained in the workflow process definition are shown in Figure 2-2.

WPDL is a language for describing the process meta-model Interface 1. In the

WfMC's document [WfM99a], the WPDL grammar is given in EBNF (Extended Backus

Naur Form).

In our work, we extend the underlying workflow model of WPDL by adding

event, rule, trigger and connectors to its set of modeling constructs and allowing e-service

requests to be a part of the activity specification. These extensions are made to support






11


dynamic inter-organizational workflow management. We will describe these extensions

in Chapter 4.


iWiifilrir in, I krmi i.I ---- --- ------,

l-imt lu- Imi a -
?,,1. .. . . .l .











,.cope *I*h l t I--- w fmlin
Wakno Iy Ait" ic
i --- -I i ------- -- -----
















Figure 2-2: Top-level entities in workflow process definition of the Workflow Process
Definition Language (WPDL).

2.2.4 Organizational Structure

In the workflow model, the organizational structure captures the relations between

roles (resource classes based on functional aspects) and groups (resource classes based on

organizational aspects) [She99]. Traditional workflow systems are designed for a


specific organization, so it is relatively simple to define an organizational structure. For

example, MQSeries Workflow provides a complete mechanism to be used to define the

organizational model [BMOO]. However, for workflow systems that are used for a


virtual enterprise, the workflow processes will not be defined for a single organization.

Workflow processes for these workflow systems will cross organizational boundaries.

This requires a new paradigm to capture the organizational structure for these workflow
systems. Although research is currently being conducted inter-organizational
VItlc n Kn LA CIJ I 1&run liifkiMn Lr xcdutfsi

Figure 2-2: Top-level entities in workflow process definition of the Workflow Process
Definition Language (WPDL).

2.2.4 Organizational Structure

In the workflow model, the organizational structure captures the relations between

roles (resource classes based on functional aspects) and groups (resource classes based on

organizational aspects) [She99]. Traditional workflow systems are designed for a

specific organization, so it is relatively simple to define an organizational structure. For

example, MQSeries Workflow provides a complete mechanism to be used to define the

organizational model [IBMOO]. However, for workflow systems that are used for a

virtual enterprise, the workflow processes will not be defined for a single organization.

Workflow processes for these workflow systems will cross organizational boundaries.

This requires a new paradigm to capture the organizational structure for these workflow

systems. Although research is currently being conducted in inter-organizational









workflow, a good solution to this problem has yet to emerge. Some systems have tried to

solve it by adopting trading communities or broker mechanisms [Gre98; Alo99; StrOO].

A virtual enterprise modeling approach is proposed in [Dav99].

In our work, the services provided by participants in the virtual enterprise are

standardized as e-services according to some predefined e-service templates. These e-

services are categorized into different business types according to the roles they play in a

virtual enterprise. E-service requests in a process model are defined based on some

standardized e-service templates. A broker server is used to manage these e-services.

The binding of an e-service request to an e-service and its provider is done at run-time.


2.3 Workflow Enactment

Workflow enactment service controls the instantiation of processes and

sequencing of activities, according to the process model information. The workflow

enactment service may consist of one or more workflow engines, which manages) the

execution of individual instances of the various processes [WfM95]. Normally, there are

two main components in a workflow engine, namely, workflow scheduler and activity

handler. The workflow scheduler enforces inter-activity dependencies and coordinates

the execution of activities in the workflow. The activity handler handles the execution of

an activity instance.

2.3.1 Enactment System Architecture

Most existing commercial workflow systems use centralized architecture to

implement the workflow engines. The run-time architecture is centralized in the sense

that a single workflow engine handles the execution of a workflow instance. MQ

Workflow [MQW] adopts the centralized control of one workflow instance. It employs a

three-tiered client-server architecture and incorporates external applications that perform









geographically distributed tasks on different platforms. The advantages of the centralized

architecture include lightweight clients, easy monitoring and auditing, simpler

synchronous mechanisms, and overall design simplicity. However, there are also many

shortcomings, namely, a single point of failure, performance limitations, scalability

problems, and so on [Alo97]. To solve these problems, alternative architectures are

proposed and implemented. Sheth et al. [She99] summarizes some alternative

architectures, including a fully distributed architecture, a client-server or web-enabled

distributed architecture, a mobile agent architecture, a distributed object-based

architecture, and a lightweight agent-based architecture.

An example of the fully distributed architecture is METEOR2 [She97]. In

METEOR2, two fully distributed workflow enactment systems (ORBWork and

WEBWork) are implemented. In these systems, there is no single entity responsible for

scheduling tasks. The scheduling information is distributed among the individual task

managers. Another example of a distributed architecture is WIDE [Cer97]. WIDE

provides a distributed workflow enactment system based on an active database-

management system. The distributed architecture of the workflow enactment service can

enhance reliability and scalability. Other workflow systems with distributed run-time

architecture include EvE [Gep98], Mentor [Mut98], and Exotica [Alo95].

Still another example is WW-FLOW [KimOO], which uses a web-enabled

distributed architecture to accomplish the workflow enactment service. Through its

modular design and run-time encapsulation, a complex process can be executed by

multiple workflow engines on the web.

Another interesting approach is mobile agent workflow. An example of this

architecture is the Migrating Workflow developed by the University of Houston [Cic98].









In the Migrating Workflow architecture, a migrating workflow instance transfers its code

(specification) and its execution state to a site, negotiates a service to be executed on its

behalf, receives the result, and moves on. Another example is the ad hoc mobile agent

based workflow system introduced by Meng et al. [MenOO].

Miller et al. [Mil96] present five run-time architectures for implementing a

Workflow Management System. They range from highly centralized to fully distributed

architectures. The work also discusses the advantages and disadvantages of these

architectures and the suitability of CORBA as a communication infrastructure.

2.3.2 Ad Hoc Modification to Process Model

Most workflow management systems currently on the market are not suitable for

dealing with the dynamic nature of present-day business environments. Their use of static

process models cannot react to and handle instantaneous changes in policies, constraints,

market conditions, and the like. A workflow management system needs to be able to

modify a process model at run-time to adapt to dynamic business conditions and

exceptional situations [Han98]. While evolutionary changes to process models can be

easily handled, ad hoc changes are much more challenging. Ad hoc changes are changes

to the execution course of a specific workflow instance at run-time. They require the

support of a dynamic workflow engine. Most research efforts in this area deal with the

dynamic changes of process models used in transitional workflow systems. Ellis et al.

[E1195] introduce an approach to provide dynamic changes to a process structure. The

changes are conducted by replacing a given sub-workflow by another completely

specified sub-workflow. Petri-net formalism is used to analyze structural changes.

Reichert and Dadam [Rei98] present a formal foundation for supporting dynamic

structural changes of running workflow instances. Based upon a formal workflow model









(ADEPT), a complete and minimal set of change operations (ADEPTflex) is defined to

support users in modifying the structure of a running workflow, while maintaining its

(structural) correctness and consistency. The modification operations include inserting

tasks as well as task blocks into a workflow graph, deleting tasks, skipping tasks,

serializing tasks that were previously allowed to run in parallel, and dynamically iterating

and dynamically rolling-back a workflow. Muller and Rahm [Mul99] describe a rule-

based approach for the detection of semantic exceptions and for dynamic workflow

modifications, with a focus on medical workflow scenarios. Rules are used to detect

semantic exceptions and to decide which activities have to be dropped or added.

Different from the works mentioned above, we address run-time modifications to inter-

organizational process models.


2.4 Virtual Enterprise and Workflow Technology

Recently, the use of the workflow technology to manage e-businesses and virtual

enterprises has drawn much attention from the academic community. Several research

projects attempt to tackle workflow management problems in these new application

areas. Here we describe two representative projects.

WISE (Workflow-based Internet SErvices) is a project at the Swiss Federal

Institute of Technology [Alo99; LazOl]. It aims to design, build, and test a commercially

viable infrastructure for developing distributed applications over the Internet. The

infrastructure provides an Internet-based workflow engine acting as the underlying

distributed operating system for controlling the execution of distributed applications, and

a process modeling tool for defining and monitoring the process. However, the workflow

system they provide does not offer the needed facilities to capture and manage the

dynamic properties of business processes.









CrossFlow is a European research project for supporting the cross-organizational

workflow management of virtual enterprises [Gre99]. Its goal is to develop and

implement a mechanism for connecting WfMS and other WfMS-like systems from

different organizations in cross-organizational workflows and electronic commerce

settings. CrossFlow provides a service-oriented model for cross-organizational

workflows. In this service-oriented model, a service specifies which part of the workflow

it fulfills and can span multiple activities. The service provider of each service can be

either an internal resource (internal service) or an external organization (external service).

For an external service, service selection at run-time will be based on the QoS parameters

given in service specifications [Kli98]. A flexible change-control mechanism is also

introduced in CrossFlow to react to potential problems during a workflow execution

[Cro00].

Our inter-organizational workflow system integrates e-services provided by the

participating organizations in a virtual enterprise. Unlike the service definition in

CrossFlow [Gre99], the e-services in our inter-organizational workflow system are

defined and provided independent of business process models. By introducing events,

rules, and constraint-based e-service requests, our process model can capture more

dynamic properties than that of the other workflow systems described in Chapter 2. The

constraint-based dynamic service binding, event and rule mechanism, and run-time

modification to process models described in this document provide a comprehensive

solution to inter-organizational workflow management.


2.5 Web Service (E-Service) Related Technologies

The World Wide Web (WWW) has achieved a great success as an easy way to

access information. Web services, the next step in the evolution of the WWW, allow









programmable elements to be placed on web sites where others can access the distributed

behaviors captured by them. As communications protocols (e.g., HTTP) and message

formats (e.g., XML) are standardized in the Web community, it becomes increasingly

possible and important to have a standardized way to describe, manage, and access Web

services.

Simple Object Access Protocol (SOAP) [BoxOO] is an XML/HTTP-based

protocol for accessing services, objects, and servers in a platform-independent manner. It

provides a simple and lightweight mechanism for exchanging structured and typed

information between peers in a decentralized, distributed environment. Web Service

Description Language (WSDL) [ChrOl] defines an XML grammar for describing

network services as a collection of communication endpoints capable of exchanging

messages. In WSDL service definitions, the operations and messages are described

abstractly, then bound to a concrete network protocol and message format to define an

endpoint. Both SOAP and WSDL have been submitted to the Wold Wide Web

Consortium as proposals for the W3C XML activity on XML Protocols.

The Universal Description, Discovery and Integration (UDDI) [AriOO] is the first

truly cross-industry effort driven by all the major platform and software providers, as

well as marketplace operators and e-business leaders. The UDDI project has created a

platform-independent, open framework for describing services, discovering businesses,

and integrating business services using the Internet. It has also created an operational

registry that is available today. The UDDI takes advantage of W3C and Internet

Engineering Task Force (IETF) standards such as XML, HTTP and Domain Name

System (DNS) protocols. Additionally, cross platform programming features are

addressed by adopting early versions of the proposed SOAP. The UDDI protocol is the









building block that will enable businesses to quickly, easily, and dynamically find and

transact with one another using their preferred applications.

While web services (also known as e-services) are becoming the programmatic

backbone for electronic commerce, an XML language for the description of Web services

compositions, the Web Services Flow Language (WSFL [Ley01]), is under development

by IBM. WSFL supports two types of composition and choreography. The first type, the

flow models, specifies the appropriate usage pattern for a collection of Web services in

such a way that the resulting composition describes how to achieve a particular business

goal; typically, the result is a description of a business process. The second type, the

global models, describes how the parts of a set of Web services interact with each other.

Thus, WSFL builds a framework in which service providers and consumers can come

together to implement standard business processes.

Since a business process model defined by our DWM can be used by a business

organization to define a new e-service in a similar way as IBM's WSFL, our model is

also a tool to compose e-services. Moreover, in addition to e-service requests, our model

provides additional constructs for capturing the dynamic properties of a business process,

i.e. events, rules, and constraints associated with e-services and e-service requests.

In our Dynamic Workflow Model (DWM), e-service requests specified in an

activity are defined according standardized e-service templates, whose format is

consistent with the format of web services defined in WSDL. We assume that e-services

are maintained by an UDDI-enabled Broker Server, and SOAP messages are used to

invoke requested e-services during the execution of workflow instances.














CHAPTER 3
ARCHITECTURE OF DYNAFLOW

A research project, supported by the National Science Foundation and conducted

at the Database Systems Research and Development Center of the University of Florida,

is entitled "Research on Advanced Technologies to Support Internet-based Scalable E-

business Enterprises (ISEE)." It aims to build an advanced information infrastructure to

support collaborative e-business and other distributed applications [SuOlb]. The ISEE

information infrastructure provides a number of servers that complement the services

provided by existing web servers. Our work on dynamic workflow management systems

makes use of a number of these servers in its implementation. This chapter begins with

an overview of the ISEE information infrastructure. Then the global architecture of the

dynamic workflow management system DynaFlow is described and the interaction

among the servers that constitute DynaFlow is presented. At the end of this chapter, we

give a brief overview on how DynaFlow works.


3.1 Overview of ISEE Infrastructure

The ISEE infrastructure is formed by a network of ISEE Hubs, as shown in Figure

3-1(A), each of which has a number of replicable ISEE servers providing various services

to individuals and business companies. Its relationship with the existing application

systems, distributed objects, agents, active distributed objects [LeeOO, Lee01], and web

browsers, is illustrated in Figure 3-1(A).










Warehouses &
Distribution Centers







Manufacturers &
Suppliers


Transportation
Companies








Retailers


(B)

Figure 3-1: ISEE infrastructure. (A) Overall architecture. (B) An ISEE hub.


At present, each ISEE Hub has a Web Server, an Event Server, an Event-Trigger-

Rule (ETR) Server, a Workflow Server, an automated Negotiation Server, and a

Constraint Satisfaction Processing (CSP) Server as shown in Figure 3-1(B). These

servers are middlewares that provide ISEE-services useful for collaborative e-business

applications. For example, the Event Server enables flexible and dynamic

communication among loosely coupled systems that are distributed across organizations.

The Event-Trigger-Rule Server provides timely and automated responses to events by

invoking triggers and rules. Another important server provided by the ISEE









infrastructure is the Dynamic Workflow Server. DynaFlow, which makes use of this

server to provide dynamic workflow management, will be described in the next section.

ISEE Hubs are installed at the sites of ISEE organizations. Users of an ISEE Hub

not only have full access to Internet and Web services, but also to the additional services

provided by ISEE servers.


3.2 Global Architecture of DynaFlow

The architecture of DynaFlow is shown in Figure 3-2. The system consists of a

Workflow Server, an Event Server, and an ETR Server. A centralized Broker Server is

also used in DynaFlow to manage the e-service specifications of an e-service domain that

have been registered by participating business organizations and to match e-service

requests against these specifications for selecting the suitable e-service providerss. A

Broker Proxy is installed in each ISEE Hub to communicate with the centralized Broker

Server. Multiple Broker Servers can be installed to handle multiple e-business domains.

The Workflow Server is the key component of DynaFlow. It is composed of two

sub-components: namely, the Process Definition Tool and the Workflow Engine. The

Process Definition Tool is used to design inter-organizational process models, which are

modeled by a dynamic workflow model (DWM). The Workflow Engine schedules the

execution of the workflow instances according to the process model specification.

During the execution, the Workflow Engine makes use of the ISEE services provided by

other servers, such as the Event Server, the ETR Server, and the Broker Server to achieve

the dynamic properties (i.e., the active, flexible, and adaptive properties) of the workflow

management system.











Organization 1

E-Services

E-Service Adapter


Event Server ETR Server WebServer ISEE
Workflow Server Broker Proxy Hub
Broker Server ...............





Internet


ISEE Hub
ISEE Hub

Event Server ETR Server Web Server
Event Server ETR Server Web Server
Workflow Server Broker Proxy
Workflow Server Broker Proxy

- - - - - - -^ '- - - --- --- - -- - - - - --- -
E-Service Adapter E-Service Adapter E-Service Adapter

E-Services E-Services E-Services
------------------------- L------------------------ --------------------------I
Organization 2 Organization 3 Organization 4


Figure 3-2: Global architecture of DynaFlow.

In an ISEE virtual enterprise, inter-organizational process models are designed to


capture the business processes of the entire virtual enterprise. The participating


organizations of a virtual enterprise may have their own process models that are


processed by their own workflow systems. These "local" process models can be enacted


by the dynamic workflow management system as a part of an inter-organizational process


model. The inter-organizational process models, once designed, are made accessible to


all the participating organizations. The models can be stored in a central repository and


can be checked out and customized by participating organizations to meet their local


needs. However, for scalability reasons, we replicate these inter-organizational process


models, as well as the Workflow Server, at all the ISEE-hub sites. Authorized users of









the virtual enterprise, who may travel from one collaborative site to another, can enact a

process model at any site. The workflow instance created by the enactment will then be

managed by an instance of the Workflow Server at that site. Thus, concurrent workflow

instances initiated at different sites are controlled and managed by multiple instances of

the Workflow Servers.

Participating business organizations can perform and contribute different manual

or automated tasks, which is useful for the operation of a joint business. These tasks are

to be invoked in the execution of an inter-organizational business process. In our work,

we uniformly treat all the sharable tasks performed by people or automated systems as

electronic services or e-services. An e-service adapter needs to be installed at each

organization's site as a wrapper for its e-services so that they can be invoked during the

execution of an inter-organizational business process.


3.3 Servers in DynaFlow

The relationship between the servers of DynaFlow is shown in Figure 3-3. In this

figure, the dashed lines represent build-time actions, and the solid lines represent run-

time actions.

3.3.1 Process Definition Tool

The Process Definition Tool is a Graphic User Interface (GUI) used for designing

process models. It invokes a GUI that has been implemented for a Knowledge Profile

Manager [LeeOO, LeeOl] to define business events, business rules, and triggers that are

related to process models. It also invokes a Constraint Definition Tool (For clarity, it is

not shown in the figure) to define constraints that are associated with the e-service

requests specified in the process models. The definitions of events generated by the










process models are passed on to both the ETR Server and the Event Server for

installations of the events. The run-time workflow structures and activity codes (both

will be explained in detail in Chapter 5) are generated from the meta-information of the

process models and are used by the Workflow Engine to schedule the execution of

workflow instances.



ISEE Hub

(......... .. ......... .. ......... .. ...............
S ,Icl c










I ..I E
i i .i\ -- ISEE



--Hub




R
N
E


ISEE
Hub
E-Service Adapter

Broker Server
E-Services--


Figure 3-3: Architectural components of DynaFlow.

3.3.2 Knowledge Profile Manager

In DynaFlow, the Knowledge Profile Manager is responsible for defining the

events, triggers, and rules related to business process models. The definitions of events

are given to both the ETR Server and the Event Server for storage and use. The

definitions of rules and triggers are given to and managed by the ETR Server.









3.3.3 Workflow Engine

The Workflow Engine schedules the execution of a workflow instance according

to the run-time workflow structures and activity codes generated from the meta-

information of the process model. It is connected to the Event Server in order to post

asynchronous events to it. The Event Server performs event notifications for the

subscribers to these events. The Workflow Engine also posts synchronous events to

directly the ETR Server to trigger those rules that are linked to these events. During the

execution of the workflow instance, the Workflow Engine would contact the Broker

Server to get the service provider information for those e-services that are specified in the

activities of a process model. After getting the information about the proper service

provider for an e-service request, the workflow engine generates a SOAP message for the

e-service request, and sends it to the e-service adapter at the service provider's site to

invoke the e-service. A SOAP message containing the e-service result will be returned to

the Workflow Engine after the e-service invocation is completed. The Workflow Engine

also provides APIs to modify the process model at run-time.

3.3.4 Event Server

The Event Server handles the incoming and outgoing events to and from an ISEE

Hub. It is connected to a local copy of the Workflow Engine (to receive the

asynchronous events issued by it) and to the remote Event Servers at the other ISEE Hubs

(to notify them the occurrences of events). It provides an event registration facility for

the participants of the virtual enterprise to register their interest by subscribing to certain

events. The ETR Server is a default subscriber to the local Event Server. When the

Event Server receives an event from a remote event server, it forwards it to the local ETR









Server to initiate the processing of triggers and rules that are associated with the remote

event.

3.3.5 ETR Server

The ETR Server processes the triggers and rules in an ISEE Hub. The trigger and

rule definitions that are input through the Knowledge Profile Manager are provided to the

ETR server and are transformed to internal data structures used for executing the triggers

and rules. The ETR server receives events from the Event Server (for asynchronous

workflow events) or directly from the Workflow Engine (for synchronous workflow

events), and performs the trigger and rule processing. The relationships between events

and rules are specified by triggers. On receiving an event, the ETR Server can

immediately identify the trigger related to the event and schedule the structure of rules

specified in the trigger for processing.

3.3.6 Broker Server

The Broker Server provides several functions to DynaFlow. It provides facilities

for the registration and publication of e-services provided by e-service providers and

manages the registered e-service information. It also provides facilities for e-service

requesters and process model designers to browse and access the registered e-services

information. The constraint-based selection of service providers is another important

function of the Broker Server: It makes use of a constraint satisfaction processing (CSP)

server to match e-service requests with the e-service specifications of different service

providers to identify the proper providers.

3.3.7 Broker Proxy

The Broker Proxy in each ISEE-hub is the local proxy of the remote Broker

Server. The Workflow Engine in the ISEE-hub contacts the Broker Server through the









Broker Proxy. The functions that the Broker Server provides to the Workflow Engine

include dynamic service binding of e-service requests to e-services and their providers

and the processing of inquiries for service provider information and service templates.

3.3.8 E-Service Adapter

E-Service Adapters are installed at participating organizations' sites to wrap

services, which could be implemented in different ways. These services can then be

invoked using SOAP messages transmitted by the HTTP protocol according to the format

of the corresponding e-service templates. An E-Service Adapter thus hides the

heterogeneity of service implementations and presents a uniform view of these services

as e-services.


3.4 Functions of DynaFlow

Except the Broker Server and the e-service adapters, the architectural components

described above are replicated in all the ISEE-hubs over the Internet, making the ISEE

infrastructure symmetrical and the architecture a peer-to-peer, multi-server architecture.

The execution of a workflow instance is handled by the Workflow Engine of the ISEE

Hub at the site where the workflow instance is initiated. Other ISEE Hubs'

responsibilities are to receive the asynchronous events posted by a workflow instance and

deliver them to their corresponding ETR Servers to trigger the rules defined by the

subscribers of these events.

The activities of the participants in DynaFlow are divided into two phases: build-

time and run-time.

3.4.1 Build-time Activities

1. Process model designers use the Process Definition Tool to design inter-
organizational process models based on DWM.









2. When specifying an e-service request, a designer can invoke Constraint Definition
GUI to define constraints for the e-service request.

3. The run-time workflow structures and activity code are generated based on the
meta-information of the process models.

4. Organizations that want to initiate workflow instances of a process model can
invoke the GUIs of the Knowledge Profile Manager through the Process
Definition Tool. These GUIs are used to define events, triggers and rules, which
specify some local business events, policies, constraints, and/or regulations.

5. The event definitions are installed in both the ETR Server and the Event Server.
The rule and trigger definitions are installed in the ETR Server.

6. Organizations that are interested in the progress of an enactment of a business
process can subscribe to asynchronous events posted by the workflow instance,
and they can define rules and tie these rules to the events by trigger specifications.

3.4.2 Run-time Activities

1. A participating organization, as the workflow initiator, initiates a workflow
instance of a defined process model at an ISEE Hub site.

2. The Workflow Engine schedules the execution of the instantiated workflow
instance according to the run-time workflow structure and activity code.

3. During its execution, the Workflow Engine may contact the Broker Server
through the Broker Proxy to get the proper service providers for the e-service
requests specified in the process model.

4. To invoke an e-service, a SOAP message containing the request data is generated
and sent to the e-service adapter at the selected service provider's site to invoke
the corresponding e-service. After the invocation, a SOAP message containing
the result data is sent back to the Workflow Engine.

5. Synchronous events are posted directly to the local ETR Server to trigger business
rules to enforce the local business constraints and policies, and/or to dynamically
alter the process model.

6. Asynchronous workflow events are posted to the local Event Server.

7. The local Event Server forwards the asynchronous events to the Event Server of
the ISEE Hubs of their subscribers, causing the firing of subscribers' rules. The
events are also delivered to the local ETR Server to trigger the local business
rules.














CHAPTER 4
DYNAMIC WORKFLOW MODEL

In this chapter, we introduce a dynamic workflow model (DWM) for modeling

business processes. Since process models defined in a DWM may invoke manual and

automated tasks that can be carried out by different organizations, we shall first present a

uniform way of specifying these two general types of tasks uniformly as e-services. We

then present DWM as an extension of the underlying model ofWfMC's WPDL. After

introducing DWM, we shall delineate the dynamic properties that a workflow

management system can have if it is built upon DWM and give the specifications of the

modeling constructs. We then give a sample process scenario defined in DWM at the end

of this chapter.


4.1 E-Services

In our work, we regard e-services as services offered on the Internet that can be

accessed programmatically using a standard Internet Protocol and representation formats,

such as HTTP and XML. In other words, E-services can be accessed in a uniform way,

irrespective to the types of systems and the programming languages used to implement

these services [Hel02].

In a virtual enterprise, participating business organizations can perform and

contribute different manual or automated tasks that can be specified uniformly as e-

services. A participating organization can provide multiple e-services, and an e-service

can be provided by multiple organizations. In the Internet environment, providers of e-









services may change frequently; new providers are added and old providers become

unavailable. In modeling business processes, it is therefore important to separate e-

service requests specified in a process model from their providers. That is, a process

model should not statically bind its e-service requests to specific providers at the time a

process model is defined, except for rare and special cases. Instead, the binding should

occur at run-time when the available providers are known to the workflow management

system.

In the following subsections, we will explain how we specify e-services and e-

service requests. We also describe how we dynamically bind e-service requests to e-

services.

4.1.1 E-Service Template

In order to introduce a standard way for defining e-service in a specific business

domain, it is useful to categorize e-services and their providers by the types of business

that the providers conduct. The e-service categorization and specification in our work are

patterned after the Universal Description, Discovery and Integration (UDDI)

specification [AriOO] and the Web Service Description Language (WSDL) [Chr01]. For

example, a business organization may be of business type Distributor in a supply chain

domain. For each business type, a set of useful e-services can be defined. Business

organizations that are of the same business type may provide all or some of these e-

services. To standardize the specification of an e-service, an e-service template can be

jointly defined by those business organizations of the same business type. An e-service

template consists of one or more operations offered by the e-service. For each operation,

there are three general types of attributes:









Input attributes, which specify the data needed as input to invoke an e-service
operation.

Output attributes, which specify the returned data of an e-service operation.

Service attributes, which specify some properties of the operation, such as the
length of time the operation takes, the side effects of the operation, and the like.

An e-service template can also contain service attributes for the e-service. These

attributes specify the properties of the e-service, such as the cost for using the e-service,

the quality of the e-service, and so on, which may be useful for service negotiation,

contracting, service selection, and service level management. An example of an e-service

template for the e-service OrderProcessing provided by the business type Distributor is

shown in Table 4-1. This e-service provides one operation: Process Order.

Table 4-1: E-Service template of e-service OrderProcessing of Distributor.

Name Type
Operations Process Input Attributes ProductName String
Order ModelName String
Quantity Int
User Info UserInfo
Output Attributes Status Status
Service Attributes Duration Time
Shipping_Method String
Service Attributes (e-service) Cost Double

All e-service templates are managed by an UDDI-enabled Broker Server [HelOl;

Hel02]. They are used by service providers to register their e-services and by process

model designers to specify their e-service requests in a process model.

4.1.2 E-Service Constraint

A service provider registers its e-services with the Broker Server by first browsing

and selecting the proper e-service templates, which are displayed as a form to be filled by

the service provider. During the registration process, the service provider first provides









the broker with its general information, such as its name, URL, telephone, email, etc. It

then specifies which e-services it provides. For each e-service, the service provider needs

to specify the e-service binding description, which contains the location of the service

implementation and details on the protocol and the port to be used to access the server

that hosts the e-service. The service provider can also specify some attribute and inter-

attribute constraints on the service attributes of the e-service, and the constraints on the

input attributes and service attributes of the operations. Attribute constraints are used to

specify the values that the individual input and service attributes can have, and inter-

attribute constraints are used to specify the interrelationship between the values of these

attributes. These constraints restrict the kind of data that the requester of an e-service can

provide when the e-service is invoked. By allowing constraints associated with e-service

attributes to be explicitly specified, we can extend the Web Service Declaration

Language (WSDL) to increase its expressive power. For constraint specifications, we

adopt the syntax and semantics of the Constraint-Based Requirement Specification

Language used in a previous project [HuaOO]. We shall call these constraints e-service

constraints.

For example, a distributor Worldwide which provides the e-service named

OrderProcessing may specify constraints on the operation Process Order, as given in

Figure 4-1. They state that the operation Process Order of the e-service OrderProcessing

can only process the order of computer products with the quantity less than 1000, and if

the quantity of the order is larger than 500, this e-service needs to take more than 10 time

units. Iacl is the name of the inter-attribute constraint.









For each e-service, the e-service attributes in the e-service template and the e-

service constraints defined by the service provider together form the e-service

specification. After registration, the general information of service providers and their e-

service specifications are managed by the Broker Server.


ATTRIBUTE CONSTRAINT:
ProductName String ENUMERATION ["Computer"] priority[l]
ModelName String ANY priority[2]
Quantity Integer RANGE [1-1000] priority[3]

INTER ATTRIBUTE CONSTRAINT:
lacl Quantity > 500 implies Duration>10
Figure 4-1: Constraint specification for operation Process Order.

4.1.3 E-Service Request Constraint

During process modeling, an e-service request specified in an activity of a process

model is defined in terms of the attributes given in the corresponding e-service template.

To define an e-service request in the activity, in addition to the variable mappings of the

input and output attributes, which map the variables in this activity to the input/output

attributes of the requested e-service operation, the constraints on the service attributes can

also be specified. We shall call these constraints, e-service request constraints. We will

give the full e-service request specification when we define the activities of a process

model in Section 4.3.2.

An example of an e-service request constraint for the operation Process Order of

the e-service OrderProcessing is shown in Figure 4-2. It states that the requestor expects

that the Process Order operation should not take more than 10 time units, the cost of the

e-service should not be more than $1,000, and if it takes more than 4 time units, then the

cost must be less than $800.











ATTRIBUTE CONSTRAINT:
Duration int RANGE [0.. 10] priority[l]
Cost float RANGE [0.. 1000] priority[2]

INTER ATTRIBUTE CONSTRAINT
iacl: Duration >4 implies Cost < 800


Figure 4-2: A sample specification of an e-service request constraint.

In summary, at build-time, the service providers register their e-services with the

Broker Server according to these e-services' corresponding templates. The e-service

specifications are maintained at the Broker Server site. The process model designers

define e-service requests according to the same corresponding e-service templates. The

build-time relationship among the Broker Server, the service providers, and the process

definition tool is shown in Figure 4-3.


Broker
Server


Si4


/ register


Figure 4-3:


reference'


Service /Process Model
Provider / Designer
E_
E-Service Adapter Services

I...................................... E-See
Requests

Build-time relationship among the Service Provider, the Broker Server, and
the Process Definition Tool.


4.1.4 Constraint-based Brokering

An important function of the Broker Server is to do constraint-based brokering

and service provider selection. To achieve this, the Broker Server would match e-service









requests with the e-service specifications given by service providers to identify the proper

service providers for the request. The data provided for the input attributes of the

requested e-services and the constraints specified in these requests will have to be

compatible with (i.e., not conflict with) the attribute constraints and inter-attribute

constraints specified by a service provider. The constraint matching is accomplished by

calling on a Constraint Satisfaction Processor (CSP) [HuaOO; SuOla].

In a matching operation, there are three possible results. First, the Broker Server

cannot find a service provider that can provide e-services that satisfy the constraints and

input data given in the e-service requests. In this case, the matching operation has failed.

Second, there is a single service provider, which provides e-services that satisfy all the

requirements of the e-service requests or match the requirements within an acceptable

threshold. In this case, the matching operation succeeds and the e-service of the provider

is used to service the request. In the third case, multiple service providers can satisfy the

requests. In this case, a Cost Benefit Evaluation Server [HuaOO; SuOla] is used to

evaluate and rank the e-services provided by these service providers and the best provider

is selected.

The constraint-based service provider selection is an important function that the

Broker Server provides to the Workflow Engine. In our dynamic workflow management

system, this function is used by the Workflow Engine to do dynamic service binding. We

will explain the dynamic service binding technique in Section 4.4, in which the dynamic

properties of DWM are discussed.

4.1.5 E-Service Invocation

When a workflow instance needs to access an e-service to submit its e-service

request, the Workflow Engine first gets the URL address of a selected service provider










from the Broker Server. It then wraps the e-service request in a SOAP message and

sends it through HTTP to the e-service adapter at the selected service provider's site. The

E-Service Adapter parses the SOAP message to determine the operation of the e-service

to be invoked [Kri01]. The E-service Adapter then determines the corresponding method

that implements the service, builds the parameter list as required by the method, and

invokes the method. After the invocation is completed, the E-Service Adapter

encapsulates the return data into a SOAP message and returns it to the Workflow Engine

at the requestor's site. Figure 4-4 shows the run-time e-service invocation mechanism in

DynaFlow. Sample SOAP messages that are used to invoke the operation Process Order

of the e-service OderProcessing are shown in Figure 4-5. Figure 4-5(A) shows the

SOAP message containing the input data of the operation Process Order. The SOAP

message containing the result of this e-service invocation is shown in Figure 4-5 (B).



ISEE Hub


Broker Proxy WF Engine





Intemet (HTTP)

SOAP
SOAP SOAP SOAP
Response Request Response
Message Message Message

E-Service Adapter E-Service Adapter

Legacy Distributed Local
Application Object Workflow


Figure 4-4: Run-time e-service invocation mechanism.










































(A)

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">



www.eservices.ufl.edu/services/Distributor/OrderProcessing






order shipped






(B)

Figure 4-5: SOAP messages for invocation of operation ProcessOrder in e-service
OrderProcessing. (A) SOAP request message. (B) SOAP response message.


xmlns="www.eservices.ufl.edu/services/OrderProcessing"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">



www.eservices.ufl.edu/services/Distributor/OrderProcessing






Omnibook
6000
5

DB Center
CSE470, University of Florida, Gainesville, FL
















4.2 Dynamic Workflow Model

As described in Chapter 2, WfMC's WPDL defines a well-accepted standard of

workflow meta-model that can be used to enable workflow vendors to exchange

workflow models. In WPDL, a process definition is a network of transition edges that

connect activity nodes. The edges are optionally labeled by transition conditions. Figure

4-6 shows a business process model that conforms to the WPDL standard.



Al
AND-Spht



A2 A3 A4




AND-Join
A5







Figure 4-6: WPDL business process model.

However, there are some factors that limit WPDL's ability to support the dynamic

inter-organizational workflow required in a virtual enterprise. In WPDL, the

specifications of join and split constructs and their constraints (AND, OR, or XOR) are

embedded in the specifications of activities. These constructs and their constraints define

the structural relationships and constraints among activities. Since they are part of the

activity specifications, changes made to them would entail changes to activity

specifications. Also in a process model defined in WPDL, all activities can make

reference to all the workfloww reference data" like global variables in programming









languages. The data flows among activities are not explicitly defined. This makes the

data relationship among activities unclear. Furthermore, a process model defined in

WPDL is static. WPDL does not provide any mechanism for run-time modifications of a

process model, as discussed before. Finally, since WPDL is defined for traditional

workflows, it does not support the dynamic binding of e-service requests, which is

required for inter-organization process modeling and execution.

In order to adapt to the changing nature of e-business, we made the following

extensions and modifications to the underlying workflow model of WPDL. These

extensions and modifications not only make it easier to modify a process model both at

definition-time (or build-time) and run-time, but also enable it to support inter-

organizational business processes.

(1) Introduction of Connector. We extract the specification of Join and Split

constructs and their constraints (i.e., OR, AND, and XOR) from the activity definition

and introduce a new modeling construct called Connector to specify the above extracted

aggregation properties. By separating activity specifications from the specifications of all

types of control information, any change made in one will not affect the other. As we

shall explain later, the separation also facilitates the run-time modification of the process

model itself.

(2) Encapsulation of the activity definition. We extend the WPDL's activity

definition by adding the specification of input parameters and output parameters. An

activity can only reference the data passed by the input parameters. It exposes the result

of operations (or tasks) specified in the activity only through the output parameters. By

doing this, an activity definition is encapsulated. The activity definitions and the code









generated for them become reusable. In addition, a modification to the task items inside

an activity can be made without affecting other part of the process model.

(3) Inclusion of e-service requests in activity definitions. In a process model

defined for a single organization, an activity specification can include manual or

automated tasks to be performed within the organization. In a process model defined for

an inter-organizational workflow, the activity specification should include e-service

requests) that can be serviced by different business organizations. For this reason, we

include e-service requests in the activity definition in addition to using direct invocations

of manual or automated tasks.

(4) Inclusion of explicit data flow specification. In a process model defined in

WPDL, there is no explicit specification of data flow between activities. Data transfer

between activities is through a common data area, which contains the so-called workflow

relevant data. Any activity can modify and access the workflow relevant data. In our

model, we define data flows explicitly. We use inter-activity parameter mappings to

define the data flows between activities.

(5) Introduction of event trigger, and rule. Another important extension we make

to WPDL is the introduction of events, rules, and triggers in a process model

specification. The activities inside the process model can post events. We distinguish

the following three types of events:

Before-Activity-Event: Before an activity is executed, the Workflow Engine
that oversees the processing of a workflow instance would post a Before-
Activity-Event.

After-Activity-Event: After the processing of an activity, the Workflow Engine
would post an After-Activity-Event.









External events: An activity can also explicitly post events to report data
conditions or exceptions to the subscribers of the events. Posting an external
event is regarded as an operation or task item in an activity.

In the remaining part of this dissertation, we refer to Before-Activity-Event and

After-Activity-Event as workflow events because they are treated as an integral part of a

process model. Different from external events posted inside activities, workflow events

are automatically generated. We will describe the definition of workflow events and their

generation in detail in the next section.

By introducing these events, the execution of a workflow instance would post

events to automatically trigger the processing of some business rules. These rules have

the format of Condition-Action-AlternativeAction. They may simply perform operations

in addition to the task items (including e-service requests) specified in activities to

enforce some business policies, regulations, or constraints. They may also modify the

execution flow of the workflow instance (e.g., skip the next activity or branch to a

specific activity in a process model). Different organizations may "attach" different sets

of business rules to the events of a process model when they enact the model. Thus, the

workflow instances initiated by different organizations will trigger a different set of rules.

In this way, a process model can be tailored to fit individual organizations' local needs.

Rules can also be dynamically attached to the events posted by a running workflow

instance to handle situations that were not foreseen when the instance was initiated.

Asynchronous events can be used as notifications of the milestones of the enacted

business process.

By extending WPDL in the ways described above, we construct our dynamic

workflow model (DWM). In DWM, the modeling constructs used to define a process

model include activity, transition, connector, subflow, block, data flow, event, rule, and









trigger. In addition to normal activities, two special purpose activities are introduced:

the Begin-Activity and the End-Activity. The Begin-Activity and the End-Activity are

used to define the entry and exit points of a process model or a block in a process model,

respectively. A block is a connected network of transitions, activities, subflows, and

connectors. It is connected to the rest of a process model only via the Begin-Activity and

the End-Activity of this block. A block can be a loop-block, which defines a set of

activities that can be iterated until an exit condition is met. For each process model or

block, only one Begin-Activity and one End-Activity can be defined.

The graphic representation of a business process model is shown in Figure 4-7.

The nodes in the graph can be activities, connectors, or subflows. The oval nodes

represent the Begin-Activity or the End-Activity, the rectangle nodes represent activities,

the hexagram node represents a subflow, the rounded rectangle node represents a block,

and the small circle nodes represent connectors. The solid edges represent conditional

transitions between activities, connectors, and subflows. The connectors and transitions

together specify the control flow. The data dependencies among the activities and

subflows are captured by data flows. The data flows can be either implicitly defined

together with the transitions, or they can be explicitly defined. A thick solid line between

activities/subflows ending in a diamond shape in the graph represents an explicitly

defined data flow. The small ovals inside activities represent the events posted by the

activities. The three types of events that can be posted by activities are Before-Activity-

Event (BE), After-Activity-Event (AE), and External Event (EE). Business rules can be

attached to these events by using trigger specifications (represented by dashed lines).










Legend
(Z Begin-Activity or
End-Activity

I I Activity
D> Subflow

= Block

Q Connector
S* Condition
Before-
Activity-Event
-- BE ------- -After-
|| .---- Activity-Event
External Event

r! Rule
S Transition
4 Data flow
------ Triggers

Figure 4-7: Business process model in DWM.


4.3 Workflow Event Definition

In business process modeling, a process model designer can specify whether an

activity posts synchronous workflow events, asynchronous workflow events, or both.

Event definitions are then automatically generated based on the name of the process

model, the name of an activity, and the input and output data of the activity.

The workflow events are named after the corresponding process name, activity

name, and workflow type. For example, the name of a synchronous Before-Activity-

Event of activity "Al" in process "OrderProcessing" is "OrderProcessing

Before Al SYNC."

The event attributes are used to deliver the data to the event subscribers. For

synchronous events, return data from subscribers are expected. Table 4-2 shows the

attributes of workflow events and their return data (only for synchronous Workflow









Events). The Before-Activity-Events pass the input data of the activity to the rules linked

to them, and the After-Activity-Events deliver the output data of the activity to the

subscribers.

In addition to the input parameters or the output parameters of the activity, the

attributes of the generated asynchronous workflow events contain the identifier of the

service provider, to whose e-services the e-service requests specified in the activity are

bound. The identifier can be used to selectively trigger the rules defined by that service

provider when it is selected to be the performer of the activity.

Table 4-2: The attributes of workflow events.
Workflow Event Type Input Attributes Return Attributes

Async, Before Service Provider ID, Activity None
Input Parameters
Async, After Service Provider ID, Activity None
Output Parameters
Sync, Before Instance ID, Activity Input Activity Input Parameters
Parameters
Sync, After Instance ID, Activity Output Activity Output Parameters
Parameters

For synchronous workflow events, we add the identifier of the workflow instance,

which posts the events, and the identifier of the organization, which initiates the

workflow instance, to the input attributes of the events. The instance identifier is used to

trigger rules defined only for a specific workflow instance.


4.4 DWM Specification

4.4.1 Process Model Definition

A process model is defined in terms of the modeling constructs provided by the

DWM. Descriptive attributes, such as author, creation time, process description, time









estimation, priority, classification, documentation, and so on, can be used to define a

process model. The syntax of a process model definition is shown below:

PROCESS

[CREATED ]

[DESCRIPTION ]

[CLASSIFICATION ]

[PRIORITY ]

[