<%BANNER%>

A Code Generation Approach to Support Dynamic Workflow Management


PAGE 1

A CODE GENERATION APPROACH TO SUPPORT DYNAMIC WORKFLOW MANAGEMENT By XIAOLI LIU A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2001

PAGE 2

Copyright 2001 by Xiaoli Liu

PAGE 3

To My Family

PAGE 4

iv ACKNOWLEDGMENTS I would like to thank my advisor, Dr. Herman Lam, for giving me an opportunity to work on this challenging topic and for providing continuous guidance throughout the course of this work and thesis writing. I wish to thank Dr. Stanley Su as well for his guidance and support during this work. Thanks are also due to Dr. Joachim Hammer for agreeing to be on my committee. I thank Sharon Grant for making the Database Center a great research place, and I also thank all my friends at the University of Florida for their support and encouragement. I thank my parents and my brother for their constant love and support. Thanks also go to my husband, Haifei Li, and my daughter, Joy Li.

PAGE 5

v TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF FIGURES..........................................................................................................vii ABSTRACT....................................................................................................................... ix CHAPTERS 1 INTRODUCTION...........................................................................................................1 2 SURVEY OF RELATED WORK...................................................................................5 2.1 Process Modeling and Process Enactment................................................................5 2.2 Dynamic Workflow Projects.....................................................................................6 2.2.1 The EvE Project.................................................................................................7 2.2.2 The RWS Project...............................................................................................8 2.3 Virtual Enterprise and Workflow Technology.........................................................9 2.3.1 The WISE Project..............................................................................................9 2.3.2 The CrossFlow Project.....................................................................................10 3 ARCHITECTURE OF THE ISEE WfMS.....................................................................12 3.1 ISEE Architecture...................................................................................................12 3.2 ISEE WfMS............................................................................................................15 3.3 Run-Time Architecture of ISEE WfMS.................................................................17 3.4 Build-Time Architecture of the ISEE WfMS.........................................................18 3.4.1 Generation of Run-time Workflow Structures.................................................20 3.4.2 Generation of Activity Code............................................................................21 3.4.3 Summary..........................................................................................................22 4 DYNAMIC WORKFLOW MODEL.............................................................................23 4.1 WfMC’s WPDL......................................................................................................23 4.2 Dynamic Workflow Model Specification...............................................................25 4.2.1 Process Model Specification............................................................................26 4.2.2 Activity Specification......................................................................................28

PAGE 6

vi 4.2.3 Connector Specification...................................................................................33 4.2.4 Transition Specification...................................................................................33 4.2.5 Block Specification..........................................................................................34 4.2.6 Subflow Specification......................................................................................35 4.2.7 Data Flow Specification...................................................................................35 4.2.8 External Event Specification............................................................................36 4.3 Dynamic Properties of the DWM...........................................................................37 5 RUN-TIME WORKFLOW STRUCTURES GENERATION......................................39 5.1 Run-Time Workflow Structures Generation...........................................................40 5.2 Generated Run-Time Workflow Structures............................................................41 5.2.1 Entity Structures Generation............................................................................42 5.2.2 Control Flow Structures Generation................................................................44 5.2.3 Data Flow Structures Generation.....................................................................47 5.3 Implementation of the Run-time Structure Generator............................................49 5.3.1 ProcessRTSGenerator......................................................................................50 5.3.2 BeginActivityRTSGenerator............................................................................51 5.3.3 ActivityRTSGenerator.....................................................................................51 5.3.4 CFSGenerator..................................................................................................51 5.3.5 DFSGenerator..................................................................................................52 5.3.6 SubFlowRTSGenerator....................................................................................52 5.3.7 BlockRTSGenerator.........................................................................................53 5.3.8 EndActivityRTSGenerator...............................................................................53 5.4 Dynamic Changes to The Business Process...........................................................53 6 ACTIVITY CODE GENERATION..............................................................................55 6.1 Activity Code Generation.......................................................................................55 6.2 Generated Activity Code.........................................................................................58 6.2.1 Member Variables............................................................................................59 6.2.2 The Activity Constructor.................................................................................62 6.2.3 The Activate Method.......................................................................................63 6.3 Implementation of Activity Code Generator..........................................................65 6.3.1 Activity Translator...........................................................................................66 6.3.2 ActivityCodeGen.............................................................................................66 7 SUMMARY AND CONCLUSIONS............................................................................68 LIST OF REFERENCES...................................................................................................70 BIOGRAPHICAL SKETCH.............................................................................................73

PAGE 7

vii LIST OF FIGURES Figure Page 3.1 ISEE Infrastructure........................................................................................................ ..13 3.2 Overall Architecture of ISEE WfMS...............................................................................16 3.3 The Run-Time Architecture of the ISEE WfMS.............................................................17 3.4 Run-time Workflow Structures Generation.....................................................................20 3.5 Activity Code Generation................................................................................................21 4.1 Process Model OrderProcessing for Distributors in the Supply Chain Community.......25 4.2 Process Model Specification Language...........................................................................27 4.3 Activity Specification Language......................................................................................28 4.4 E-Service Request Specification Language.....................................................................31 4.5 BeginActivity Specification Language............................................................................32 4.6 EndActivity Specification Language...............................................................................32 4.7 Connector Specification Language..................................................................................33 4.8 Transition Specification Language..................................................................................34 4.9 Subflow Specification Language.....................................................................................35 4.10 Data Flow Specification Language................................................................................35 4.11 Event Specification Language.......................................................................................36 4.12 Data Class Specification Language...............................................................................36 5.1 Run-Time Workflow Structures Generation....................................................................40 5.2 Activity Run-time Structure.............................................................................................43

PAGE 8

viii 5.3 Specification for Activity InitiateShipping in Process Model “Order Processing”.........44 5.4. Run-time Structure for Activity InitiateShipping ...........................................................45 5.5. Control Flow Structure...................................................................................................4 5 5.6 Hash table for Transition in Control Flow Structure for C2 ............................................47 5.7 Data Flow Structure........................................................................................................ .48 5.8 Class Diagram of Run-time Structures Generation.........................................................50 6.1 Activity Code Generation................................................................................................57 6.2 General Structure of Generated Activity Class................................................................59 6.3 Declarations and Constructor in Code Generated for the Activity InitiateShipping .......60 6.4 Activate Method in Code Generated for the Activity InitiateShipping ...........................62 6.5 Class Diagram for Activity Code Generation..................................................................65

PAGE 9

ix Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science A CODE GENERATION APPROACH TO SUPPORT DYNAMIC WORKFLOW MANAGEMENT By Xiaoli Liu December 2001 Chairman: Dr. Herman Lam Major Department: Computer and Information Science and Engineering Inter-enterprise workflow technology is a key service needed to coordinate the activities of different organizations in a virtual enterprise. A Dynamic Workflow Model (DWM) has been proposed to support dynamic management of inter-enterprise business processes. The Dynamic Workflow Model (DWM) has the following properties: active, flexible, adaptive, and customizable. This thesis presents a code generation approach to support the adaptive property of the DWM, the ability to dynamically change the activities, control flow, and data flow of an executing workflow instance. A Code Generator has been designed and implemented. Based on the specification of a workflow model, the Code Generator generates (1) a set of run-time workflow structures and (2) activity code. The run-time workflow structures are used by the Workflow Engine to schedule and execute a workflow instance. Changes can be made at run-time to the control and data flows of an executing workflow instance by

PAGE 10

x adding, modifying, or deleting run-time structures. The activity code is generated based on the activity specifications of a workflow model. During activity code generation, activity specifications are translated and compiled into Java classes which, when executed, efficiently request the binding of e-service requests to service providers for execution. If the specification of an activity is changed, the code for the modified activity is re-generated and re-loaded using Java’s class reloading capability. In this manner, adaptability is maintained without sacrificing performance, resulting in a lightweight and efficient Workflow Engine.

PAGE 11

1 CHAPTER 1 INTRODUCTION Workflow technology and workflow management systems (WfMSs) enable organizations to model their business processes and control their execution. This allows organizations to reduce processing time, allocate resources efficiently, and shorten product time to market. However, traditional workflow management systems currently available on the market usually work within a single organization and support a static workflow model. The rapid growth of the Internet and Web technologies has brought about significant changes in the way business organizations operate and altered the nature of business competition. To stay competitive in the rapidly changing and expanding marketplace, it is often necessary for business organizations to form virtual enterprises with other businesses to achieve common business goals. In order to work in a virtual enterprise, characterized by its dynamic nature, the concept of dynamic workflow management should be introduced to workflow management systems to handle interenterprise business processes. Today, there are many workflow management systems available on the market (e.g., Vitria’s Business Ware and IBM’s MQSeries [GEO95, VIT99, MQW00]). There are also several research projects which have explored the concept of dynamic workflow to support workflow management across enterprise boundaries [ELL95, CAS96, REI98, MUL99]. Recently, several research projects aim to solve workflow management

PAGE 12

2 problems in the virtual enterprise environment [LAZ00, ALO99, CRO00, GRE99]. We will survey these works in Chapter 2. Currently, there is an on-going project at the Database Systems Research and Development Center at the University of Florida to build an information infrastructure for supporting Internet-based Scalable E-business Enterprises (ISEE) [SU01]. A key ISEE service is the ISEE workflow service which incorporates “dynamic” properties into the workflow management system (WfMS). The work presented here is a part of that project. A Dynamic Workflow Model (DWM) has been proposed [MEN01] to model business processes. The Dynamic Workflow Model is an extension of the Workflow Process Definition Language (WPDL) [WFM99a] by including business events and rules to capture the active properties of business processes. By integrating business processes with business events and rules, the enactment of a business process can post events to trigger business rules, which may in turn cause the enactment of other business processes. The processing of rules enables the dynamic changes made to the business processes. Connectors are introduced to represent control information (i.e., Split, Join) extracted from activity definition so that each activity definition is encapsulated and reusable. All the sharable tasks performed by people or automated systems in a virtual enterprise are regarded as Web services, or e-services. E-service requests are specified in each activity definition within a process model according to standardized e-service templates and are bound to the proper service providers at run-time with the help of the Broker Server. Therefore, the process models defined are independent of the service providers coming and going in a virtual enterprise. Dynamic properties are achieved by integrating

PAGE 13

3 business processes with events and rules, and the dynamic binding of e-services with service providers. The focus of this thesis is the design and implementation of build-time tools to support a dynamic workflow management system. Using a “code generation” approach, the build-time tools generate (1) run-time workflow structures and (2) activity code, based on the specification of a workflow model. The run-time workflow structures are used by the Workflow Engine to schedule and execute a workflow instance. Dynamic changes to the control and data flows of an executing workflow instance can be made at run-time by changing these run-time structures by invoking methods via the API of the Workflow Engine. The generated activity code is in the form of Java code. The Workflow Engine, when scheduling the activities for a process instance, simply loads the Java activity classes from a Run-time Repository and executes the code directly to perform specified tasks. This code generation approach results in a lightweight and efficient Workflow Engine. It is lightweight because the Workflow Engine does not need the logic to interpret the activity specification in order to determine how to bind the e-service requests and calling the bound service provider to perform the e-services. Taking advantage of the performance of compiled classes, the Workflow Engine is efficient. Finally, changes to an activity (e.g., e-service requests, performer, performer constraints, etc.) can be made using a Process Definition Tool. The code for the modified activity is re-generated and re-loaded using Java’s class reloading capability. In this manner, any change made to an activity specification will be reflected in the execution of the activity

PAGE 14

4 as long as the re-generated code is placed in the Run-Time Repository before the execution of the activity. Thus, flexibility is maintained without sacrificing performance. The organization of this thesis is as follows. Chapter 2 presents a survey of research works related to dynamic workflow management and workflow management in a virtual enterprise environment. Chapter 3 describes the global architecture of the ISEE information infrastructure and the dynamic WfMS. The modeling constructs of the Dynamic Workflow Model are presented in Chapter 4. Chapters 5 and 6 focus on the details of the run-time workflow structures generation and the activity code generation, respectively. Chapter 7 provides a summary and conclusion of the thesis.

PAGE 15

5 CHAPTER 2 SURVEY OF RELATED WORK Inter-enterprise workflow technology is a key e-service to coordinate the activities of different organizations in a virtual enterprise. In the highly competitive and rapidly changing and expanding global marketplace, business organizations often find the need to form virtual alliances with other businesses to achieve various business goals. Unlike a “real” enterprise when business processes and policies may be relatively static, the processes and policies of a virtual enterprise are much more dynamic. This chapter surveys related research focusing on bringing dynamism to workflow management and projects focusing on workflow management in virtual enterprises. 2.1 Process Modeling and Process Enactment Process modeling and process enactment are the two essential parts of any workflow management system. The purpose of process modeling is to produce an abstract representation of a process model upon which the workflow specification is based. There are basically two kinds of process modeling methodologies, namely communication-based, and activity-based [GEO95, SHE96, WIN87]. Communicationbased methodologies stem from “The Winograd/Flores Conversation for Action Model” [WIN87] in which the progress of a 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.

PAGE 16

6 Activity-based methodology is most frequently adopted by workflow management systems because it decomposes a process into tasks that are ordered according to dependencies among them. This kind of process model can be easily turned into a workflow specification. Most commercial workflow management systems, including IBM’s MQ Workflow [MQW00, LEY94], adopt this activity-based methodology in its process modeling. Our project also uses activity-based methodology to model processes to facilitate the dynamic workflow model specification. Workflow specification languages are used to describe process models. To capture the dependencies among activities, workflow specification languages often use rules, constraints, and/or graphical constructs. During process enactment, the workflow engine is responsible for interpreting the process definition, creating the instance of the process, and managing its execution. A workflow management system may consist of one or more workflow engines. Most existing commercial workflow systems are centralized in the sense that a single workflow engine handles the execution of one process instance. For example, MQ Workflow [MQW00] adopts the centralized control of one workflow instance. It employs a threetier client-server architecture and involves external applications that perform geographically distributed tasks on different platforms. 2.2 Dynamic Workflow Projects There have been several projects that focused on various aspects of dynamic workflow management. Most of them deal with the dynamic changes of process models used in transitional workflow systems. In Ellis et al. [ELL95], an approach to provide dynamic changes to a process structure is introduced. The dynamic changes are accomplished by replacing a given sub-workflow with another completely specified sub-

PAGE 17

7 workflow. This approach makes use of Petri-net formalism to analyze structural changes. Reichert and Dadam [REI98] presents 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 (ADEPT_flex) is defined to support users in modifying the structure of a running workflow instance, while maintaining its (structural) correctness and consistency. The change 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. In this approach, rules are used to detect semantic exceptions and to determine which activities need to be skipped or added. The remainder of this section describes two major projects related to dynamic workflow management: EvE and RWS. 2.2.1 The EvE Project EvE [GEP98] is an EVent Engine implementing event-driven distributed workflow execution. This project was carried out at the University of Zurich. The event engine performs event registration, detection, and management, as well as event notification to distributed, reactive software components. In the EvE project, events and Event-Condition-Action (ECA) rules are used as the fundamental concept for defining and enforcing workflow logic, and processing entities are used to represent the software applications that enact the workflow by reacting to events and generating new events. A broker/services model is used to describe the software and process architecture. In this

PAGE 18

8 model, brokers are interacting, reactive components representing the processing entities. Broker behavior is defined by ECA rules specifying their reactions to events. The execution of a workflow starts when some event occurs. The event engine server then performs event detection and rule execution. While executing the rule, task assignment determines the brokers to be notified. These brokers then react according to their ECA rules. Brokers may generate new events, which are again processed by the event engine until the execution of the workflow is complete. The event-based EvE eases integration and coordination of the processing entities. Due to this infrastructure, dynamic changes to the workflow can be achieved by either changing or introducing new ECA rules. 2.2.2 The RWS Project Reliable Workflow Systems (RWS) [SHR98, WHE98] is implemented at the University of Newcastle in joint collaboration with Nortel technology. There are two main components in the system architecture: the workflow repository service and the workflow execution service. The workflow repository service stores workflow schemas and provides operations of initializing, modifying, and inspecting schemas. A scripting language has been designed for defining the workflow schemas represented in terms of tasks and dependencies. The workflow execution service coordinates the execution of a workflow instance. It records inter-task dependencies of a schema and ensures that tasks are scheduled to run respecting their dependencies. The dependency information is maintained and managed by task controllers. Distributed task controller objects interacting and communicating directly with each other implement the workflow logic. Dynamic changes to workflow are done by changing the inter-task dependencies, either

PAGE 19

9 in the workflow schema, or directly in the workflow instance, in this case the task controller. 2.3 Virtual Enterprise and Workflow Technology The expansion of the Internet and the proliferation of inexpensive computing power provide the basic hardware infrastructure for B2B electronic business in virtual enterprise. However, the corresponding software infrastructure is still missing. Fortunately, there are some ongoing projects to address the limitation. Among them, WISE and CrossFlow are presented here. 2.3.1 The WISE Project Workflow based Internet Services (WISE) [ALO99, LAZ00] is a project funded by the Swiss National Science Foundation. Its objective is to design, build, and test a commercially viable infrastructure for business to business e-commerce in the form of a working system capable of defining, enacting, and monitoring virtual enterprise business processes. The infrastructure provides an Internet workflow engine acting as the underlying distributed operating system controlling the execution of business processes, a process modeling tool for defining and monitoring the processes, and a catalogue tool for virtual enterprise services. There are four components in the WISE architecture, namely, process definition, process enactment, process monitoring, and process coordination. The process definition component defines virtual business processes with available services offered by different companies in the virtual enterprise. The process enactment component controls the execution of the process by invoking the corresponding services of the virtual enterprise. The process monitoring component keeps track of the progress made in the execution of the virtual enterprise business process. The process coordination component supports multimedia conferencing and browsing of relevant information between all participants in the virtual enterprise.

PAGE 20

10 In WISE, different companies join their services to form a virtual enterprise, which provides a business process that can be executed over the Internet. The workflow system provided in WISE, however, does not have the facilities to capture and manage the dynamic properties of business processes. 2.3.2 The CrossFlow Project CrossFlow [LUD99, CRO00] is a European research project for supporting crossorganizational workflow management in virtual enterprises. In this project, IBM’s MQSeries Workflow is used. The goal of this project is to develop and implement the mechanism for connecting WfMS and other WfMS-like systems of different organizations in dynamically formed virtual organizations. Virtual organizations are dynamically formed by contract-based matchmaking between service providers and consumers. In CrossFlow, there is a trader known to consumers for service providers to post services. If a process in a WfMS requires some services from another organization, the WfMS sends a request to the search manager to look for suitable service providers. After the service provider is found and a contract is made between the consumer and the provider, the service can be initiated and a process in the provider WfMS can be activated on behalf of the consumer. Different workflow systems are linked through proxy gateways which are dynamically generated modules at organizational boundaries. A flexible change control mechanism is also introduced in CrossFlow to react to potential problems during a workflow execution. The ISEE dynamic workflow management system (WfMS) described in this thesis supports dynamic workflow management. By introducing events, triggers, rules, and constraint-based dynamic service binding, our process model can capture more dynamic properties, such as active, flexible, adaptive and customizable. The integration

PAGE 21

11 of constraint-based dynamic service binding, event, trigger, and rule mechanism with business processes provides a comprehensive solution to inter-enterprise workflow management. The code generation approach described in this thesis supports the dynamic properties in the ISEE WfMS.

PAGE 22

12 CHAPTER 3 ARCHITECTURE OF THE ISEE WfMS A research project on advanced technologies to support I nternet-based S calable E business E nterprises (ISEE) is in progress at the Database Systems Research and Development Center of the University of Florida. Its purpose is to build an advanced information infrastructure capable of providing ISEE services for collaborative ebusiness [SU01]. One of the key services provided by the ISEE information infrastructure is the ISEE Workflow Management System (WfMS) which implements the dynamic workflow service. This chapter describes the overall ISEE architecture, and the overall architecture of the ISEE WfMS. Section 3.1 describes the ISEE architecture, followed by an introduction of the overall architecture of the ISEE WfMS in Section 3.2. Section 3.3 presents the run-time architecture of the ISEE WfMS, while Section 3.4 describes the build-time architecture of the ISEE WfMS. 3.1 ISEE Architecture With the Internet, World Wide Web (WWW), and other existing Information Technologies (IT), a user today can connect to Web servers, access their back-end database systems, and transact business. The emerging distributed object technology further enhances the information technology by allowing distributed applications to be invoked in a structured manner, in forms of communicating Distributed Objects (DOs). DOs can be used to encapsulate existing application systems and to develop new

PAGE 23

13 applications. Their services are accessible by users through Web browsers. Thus, the current (Web + existing IT) paradigm provides a basic infrastructure over the Internet to interconnect enterprises and allow data and application systems to be shared among customers, suppliers, and business partners. Figure 3.1 ISEE Infrastructure In [SU01], an information infrastructure to support an ISEE was proposed to enable collaborative e-business among multiple organizations to conduct business over the Internet. In an ISEE, the basic infrastructure is enhanced to, not only support the sharing of data and application systems over the Internet, but also provide ISEE services necessary for collaborative e-business and other general distributed applications. That is, App Internet Communication Infrastructure Agent ADO DO Browser ISEE Infrastructure . Manufacturers & Suppliers Warehouses & Distribution Centers Retailers Transportation Companies ISEE Hub ISEE Hub ISEE Hub ISEE Hub ISEE Hub (a). Overall Architecture Other Servers Workflow Server Broker Server Event Server ETR Server DO Server Web Server Internet Communication Infrastructure ISEE-HUB … (b). An ISEE Hub

PAGE 24

14 ISEE Infrastructure = Web + Existing IT + ISEE Services for Collaborative ebusiness The proposed infrastructure and its relationship with existing application systems, distributed objects, agents, active distributed objects, Web browsers, and Web servers in a virtual enterprise environment are shown in Figure 3.1. In Figure 3.1(a), ISEE hubs are replicated and deployed at the sites of participating ISEE members, much the same way the Web servers are deployed now to support Web services. As shown in Figure 3.1(b), each ISEE hub consists of a number of ISEE servers such as an Event Server, an EventTrigger-Rule (ETR) Server, a Workflow Server, a Broker Server, a DO Server, a Web Server, and other general purpose servers. Internet users can still use the Internet and Web services as they are but the ISEE members can have access to the additional services. The ISEE servers in an ISEE hub work together to provide a wide range of collaborative ISEE services to connected members. We have been developing and integrating a number of what we regard as the core information infrastructure technologies and services. They include active distributed object modeling, business event management, business rule management, messaging infrastructure for interenterprise communication, cost-benefit analysis and evaluation, trust management and access control, and constraint satisfaction processing. Other services needed to support collaborative e-business, such as constraint-based brokering, supplier selection, automated negotiation, dynamic workflow modeling and control, can be built upon these core technologies. The implementations of all these services in forms of servers are intended to complement the services by the Internet and Web.

PAGE 25

15 The dynamic workflow service is a key ISEE service for managing interenterprise processes, and is the focus of this thesis. In a virtual enterprise, business processes such as an e-supply-chain, can cross company boundaries. Thus, workflow systems are required to manage business processes across enterprise boundaries. Unlike a “real” enterprise when business processes and policies may be relatively static, the processes and policies of a virtual enterprise are much more dynamic. In chapter 4, a Dynamic Workflow Model is presented to support the management of inter-enterprise business processes. 3.2 ISEE WfMS The ISEE WfMS is the implementation of the ISEE dynamic workflow service. The architecture of the ISEE WfMS is shown in Figure 3.2. It involves several servers including a centralized Broker Server; and several servers in an ISEE hub: an Event Server, an ETR Server, and a Workflow Server. The constraint-based Broker Server provides information about service providers. It also performs dynamic service binding to bind a requested e-service specified in an activity of an inter-enterprise process (workflow) to a specific service provider at runtime. In order to communicate with the Broker Server, a Broker Proxy is installed in each ISEE hub. All sharable tasks, which can be performed by different organizations, are considered as e-services. An e-service adapter exists in each organization to wrap its e-services so that the organization’s e-services can be invoked in the execution of an inter-enterprise business process. The Event Server manages events coming to and leaving an ISEE hub. The ETR Server takes care of event, trigger and rule processing.

PAGE 26

16 Workflow ServerISEE Hub E-Services E-Services E-Service Adapter E-Service Adapter Broker Proxy ETR Server Event Server Web ServerISEE Hub E-Service Adapter E-Services E-Services E-Service Adapter Broker Server Workflow Server Broker Proxy ETR Server Event Server Web Server Workflow ServerISEE Hub Broker Proxy ETR Server Event Server Web Server Organization 3 Organization 2 Organization 1 Organization 4 Internet Figure 3.2 Overall Architecture of ISEE WfMS The Workflow Server is the key component of the ISEE WfMS. The implementation of the Workflow Server is based on workflow technology which enables the modeling of business processes and automates the control of their execution. Before we continue, let us define some terms. A workflow model (also called process model ) is used to model a business process and consists of a network of activities and their control/data flow of these activities. A workflow model can be instantiated as a workflow instance (also called process instance ) and executed in the Workflow Server. The Workflow Server is composed of a set of build-time tools and the Workflow Engine. The build-time tools include the Process Definition Tool (PDT) and the Code Generator. The PDT is a Graphical User Interface (GUI) used to define and edit workflow models (note these are also called process models). The Code Generator is used to generate run-time

PAGE 27

17 workflow structures and activity codes according to workflow model specifications defined with PDT. The Workflow Engine schedules and executes workflow instances according to the workflow model specifications. 3.3 Run-Time Architecture of ISEE WfMS The run-time architecture of the ISEE WfMS is shown in Figure 3.3. The main components involved in the architecture are: Internet ISEE Hub ISEE Hub WF Engine E-Service Adapter E-Services Broker Server Broker ProxyService Provider Inquiry Notify Events Event ServerReceive Events Forward Events Receive Events Notify Events Post Async Events ETR Server Service invocation Post Sync Events Runtime WF Structure Activity Codes ISEE Hub Figure 3.3 The Run-Time Architecture of the ISEE WfMS 1. Workflow Engine: The Workflow Engine manages the execution of a business process until completion by assigning activities to each specified performer at the specified time. During the execution, the Workflow Engine makes use of other collaborative ISEE services provided by other servers, namely, 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 WfMS. While executing a workflow instance, the Workflow Engine may post asynchronous events to the Event Server,

PAGE 28

18 which then notifies the subscribers of these events. It may also post synchronous events to the ETR Server to trigger rules attached to the events. The Workflow Engine also contacts the Broker Server through the Broker Proxy to obtain service provider information for e-service requests specified in the activities of a process model. After a qualified service provider is selected, the Workflow Engine invokes the specified service through an e-service adapter. 2. Event Server: The Event Server provides the publish-subscribe model of an event service for asynchronous events. At the Event Server, event providers publish available events, while event consumers, as participants of the virtual enterprise, can subscribe or unsubscribe to events of their interest. When an event is posted, the Event Server will notify all subscribers to that event. The Workflow Engine, as one of the event providers, may post asynchronous events to the Event Server. The Event Server is also connected with the Event Servers in other ISEE hubs to notify them of events and receive event notifications from them. 3. ETR Server: The ETR Server and the Event Server provide the “active” property of the Dynamic Workflow Model. At run-time, the events specified in a Dynamic Workflow Model will be posted to the Event Server and the ETR Server to trigger rules in the ETR Server. The ETR Server is a subscriber to an Event Server. Thus, the ETR Server may receive event notifications from the Event Server (for asynchronous workflow events). Also, the ETR Server may receive events directly from the Workflow Engine (for synchronous workflow events). The posted events will activate all triggers associated with that event. The event history specified in a trigger will be processed and appropriate rules will be executed. 4. Broker Server: The Broker Server allows e-service providers to register and publish their e-services in terms of descriptive attributes and constraints through GUIs. It manages the registered e-service information and processes inquiries to service provider information. The e-service requests are also specified in terms of descriptive attributes and constraints. The Broker Server makes use of a Constraint Satisfaction Processing (CSP) server as its key component. The CSP is used by the Broker Server to dynamically bind e-service requests to e-service specifications and their providers according to the e-service requests specifications and their constraints. 5. Broker Proxy: The Broker Proxy in each ISEE hub maintains communication with the remote Broker Server. The Workflow Engine contacts the Broker Server through the Broker Proxy. 3.4 Build-Time Architecture of the ISEE WfMS The build-time architecture discussed in this thesis is designed to support a code generation approach to realize a dynamic workflow management system. The main

PAGE 29

19 components involved in the build-time architecture of the ISEE WfMS are outlined below. 1. MetaData Manager: The MetaData Manager is a server which provides a persistent repository for storing meta-information. The specifications for process model, data classes, event, rule and e-service request constraints are captured using GUI editors and stored in the MedaData Manager. Components of the ISEE WfMS make references to the MetaData Manager to access the specifications. The MetaData Manager is built on top of a Persistent Object Manager (POM) [SHE01]. It was developed for IKnet [LEE00, SU00] and is extended in our project to support workflow concepts. 2. GUI Editors: Three GUI editors are involved in defining a process model, namely, the Process Definition Tool (PDT), the Knowledge Profile Manager (KPM), and the Constraint Definition Tool (CDT). The Process Definition Tool is used to specify various parts of a process model, including activities, transitions, connectors, etc.. Knowledge Profile Manager is invoked from the PDT to define events, triggers, and rules related to a process model. The definitions of events generated by the process models are sent to both the ETR Server and the Event Server to perform installation operations. Also, the Constraint Definition Tool is invoked from the PDT to define constraints associated with the e-service requests specified in the process models. 3. Code Generator: The focus of this thesis is the Code Generator component used to support the dynamic workflow management system. The Code Generator translates the process model specifications into run-time workflow structures. The run-time workflow structures generation separates the run-time workflow structures from the process model specifications and supports the dynamic changes to a business process. The Code Generator also generates the code to implement the activities specified in a process model. Activity code generation results in an efficient and lightweight Workflow Engine and also supports dynamic changes to a business process. Specifically, activity specifications are translated and compiled into Java classes. These Java classes, when executed, perform tasks specified in the activities and may invoke the Broker Server for dynamic binding of the e-service requests with appropriate e-services and their providers. The compiled activity codes benefit the performance of the Workflow Engine. When the Workflow Engine is going to execute a workflow instance, it will read in the run-time workflow structures generated for the appropriate process model. According to the run-time workflow structures, activities are scheduled and executed by loading the corresponding activity code already generated. The Code Generator generates run-time workflow structures and activity code to support a combination of “interpretative” and “code generation” approach to realize dynamic workflow management.

PAGE 30

20 3.4.1 Generation of Run-time Workflow Structures Figure 3.4 illustrates how the main components are related to each other during the generation of run-time workflow structures. Process Definition Tool MetaData Manager Run-time Structures Generator Get process model spec WF EngineGenerate run-time structures Run-Time Repository Get run-time structures Figure 3.4 Run-time Workflow Structures Generation The Process Definition Tool is used to define new process models and edit existing ones. The process model specification is saved in the MetaData Manager. The Run-time Structures Generator is invoked to generate run-time workflow structures according to the process model specification. The generated run-time workflow structures will be written to a serialization file and stored into the run-time repository to be used by the Workflow Engine to execute the workflow instance. The process model specification is separated from the workflow execution environment by run-time workflow structures generation. Dynamic changes to a business process during process

PAGE 31

21 enactment can be accomplished by modifying the corresponding run-time structures of the process model. 3.4.2 Generation of Activity Code Figure 3.5 shows how the main components are related to each other during the generation of activity code. Activity Editor Process Definition Tool Constraint Definition Tool KPM MetaData Manager Activity Code Generator Get activity spec WF EngineGenerate and deploy activity code Run-Time Repository Figure 3.5 Activity Code Generation The Activity Editor is a component of the Process Definition Tool. It is used to define new activities and edit existing activities in a process model. While defining an activity, the Activity Editor may invoke KPM to define external events in the activity, or it may invoke the Constraint Definition Tool to define e-service request constraints, depending on the type of tasks the activity is going to perform. Activity, event, and eservice request constraint specifications are stored in the MetaData Manager. The

PAGE 32

22 Activity Code Generator is invoked by the Process Definition Tool to generate the Java code according to the activity specifications and to compile them. Finally, the compiled Java class files are placed into a run-time repository ready for the Workflow Engine to use. 3.4.3 Summary The chapters that follow will present the details of the code generation approach to support the dynamic ISEE workflow management system. Chapter 4 presents the Dynamic Workflow Model specification. Chapter 5 focuses upon run-time workflow structures generation, and Chapter 6 focuses upon the code generation for activities.

PAGE 33

23 CHAPTER 4 DYNAMIC WORKFLOW MODEL The rapid growth of the Internet has made it necessary for different organizations to form virtual enterprises to do business together in order to stay competitive in the market. In order to work in a virtual enterprise environment, workflow systems have to be able to manage business processes across enterprise boundaries. As the processes and policies of a virtual enterprise are much more fluid, the inter-enterprise workflow system is required to have the capability of accommodating the changing business policies and strategies of participating organizations, handling expected and unexpected situations, and support dynamic changes to business processes. In [MEN01], a Dynamic Workflow Model is proposed to model inter-enterprise business processes. This chapter describes the modeling constructs of the Dynamic Workflow Model. Section 4.1 summarizes WfMC’s Workflow Process Definition Language (WPDL) [WFM99a] upon which the Dynamic Workflow Model is based. Section 4.2 presents the specifications for different entities in the Dynamic Workflow Model. Section 4.3 is a summary of dynamic properties provided by the Dynamic Workflow Model. 4.1 WfMC’s WPDL The Workflow Management Coalition (WfMC) [WFM99a, WFM99b] was founded in August 1993. It has been established to identify functional areas and develop appropriate specifications for implementation in workflow products. The Coalition’s

PAGE 34

24 mission is to promote the use of workflow technology through the development of standards for software terminology, interoperability, and connectivity between workflow products. The Workflow Process Definition Language (WPDL) is one of the major contributions of WfMC. It is a language for describing workflow models in a structured and standardized manner for the interchange of process definitions. With WPDL, a set of activities can be defined with conditioned transitions to enable conditioned branching from activities to activities. In WPDL, the activity information include the specifications of Join and Split constructs and their constraints (AND, OR, and XOR). These constructs help define the structural relationships and constraints among activities. In a process model defined with WPDL, the data flows are implicitly defined by making use of global variables, which are called “workflow reference data”. This makes the data relationship between activities unclear. Also a process model defined with WPDL is static. The Dynamic Workflow Model (DWM) specification is an extension to WfMC’s WPDL [WFM99a] to support the dynamic ISEE WfMS. Extensions and modifications to the WPDL include more modeling constructs such as connectors, events, triggers, rules, data flow, and e-service requests. Graphically, a Dynamic Workflow Model can represent a business process using a dynamic process model diagram. An example process model diagram, named “Order Processing” is shown in Figure 4.1. This figure will be used throughout the remainder of the chapter to illustrate modeling constructs in the Dynamic Workflow Model.

PAGE 35

25 4.2 Dynamic Workflow Model Specification In order to support the dynamic nature of business processes in a virtual enterprise, the following extensions and modifications are made to the WPDL to form the DWM specification. 1. Introduction of Connectors: The specification of Join and Split constructs and their constraints (AND, OR, and XOR) is embedded in the specifications of activities in WPDL. The specification of this control information is extracted and represented by a new modeling construct named Connector The introduction of connectors separates control flow information from the activity specification so that any change made in an activity will not affect the control flow and vice versa. This separation facilitates the dynamic changes to a business process. OrderEntry AdjustInventory C1 Acknowledge PurchaseOrder InitiateShipping EndActivity Distributor (ANY) Distributor (SameAs OrderEntry ) Transportation Agency (ANY) B E SYNC AE ASYNC AE Legend: : Activity : Connector : Condition B E: BeforeActivity-Event AE: AfterActivity-Event : Transition : WF Event Posting AND AND Distributor (SameAs OrderEntry ) ASYNC C2 BeginActivity D1 T1 T2 T3 T4 T5 T6 T7 T8 : Data Flow Figure 4.1 Process Model OrderProcessing for Distributors in the Supply Chain Community 2. Encapsulation of the activity specification: The specifications of input and output parameters are added to the WPDL’s activity specifications. An activity can only reference the data passed to it by the input parameters. Secondly, the only data

PAGE 36

26 outputted by an activity is through its output parameters. Thus, the activity specification is encapsulated. 3. Inclusion of e-service requests in activity specification: In an activity specified within a process model for an inter-enterprise workflow, there may exist tasks which can be performed by different business organizations. The business organizations which actually provide the requested e-services (we call these organizations service providers) can be dynamically bound to the e-service requests at run-time by the Broker Server according to constraints associated with e-service requests. 4. Introduction of Data Flows: In WPDL, data transfer among activities is through the workflow relevant data, which can be accessed by all workflow process definitions (and associated activities and transitions). In DWM, Data Flows are used to define inter-activity parameter mapping information. The introduction of Data Flows is used to eliminate any possible ambiguity in data relationship between activities. 5. Introduction of events, triggers, and rules: Events, triggers and rules are introduced to the process model specification as an important part of the DWM. Activities specified in a DWM can post events. Three different types of events can be posted, namely, Before-Activity-Event, After-Activity-Event, and External Events. A Before-Activity-Event can be posted before an activity is started. An After-ActivityEvent can be posted after an activity is completed. External events are published “user defined” events posted inside an activity. When an activity is activated during the execution of a business process instance, their events are posted to automatically trigger the processing of some business rules. These rules are Event Condition Action (ECA) or Event Condition Alternative Action (ECAA) rules. The processing of these rules may cause some actions taken to enforce some business policies, regulations, or constraints. It may also cause the execution flow of the process instance to be modified, for example, by skipping some activities. With events, triggers, and rules, different users can attach different sets of rules to the same process model. The execution of different workflow instances can trigger different sets of rules. Therefore, one process model can be tailored to fit different organizations’ needs. 4.2.1 Process Model Specification A process model is specified in terms of its modeling constructs. In DWM, there are eight different modeling constructs including activity, connector, transition, block, subflow, data flow, event, and data class. The syntax of a process model specification language is shown in Figure 4.2.

PAGE 37

27 The pair of brackets, “[]”, indicates the clauses surrounded are optional. The CREATED DESCRIPTION CLASSIFICATION PRIORITY time estimation and DOCUMENTATION clauses specify the descriptive attributes of a process model. Activity list contains a set of activities specified in a process model. Activities are the most important components in a process model. They are used to define tasks that need to be fulfilled for a business process. There are two special types of activities in DWM: BeginActivity which indicates the entry point of a process model or a block, and EndActivity which indicates the end point of a process model or a block. Each process model or block can have only one BeginActivity and one EndActivity. Figure 4.2 Process Model Specification Language Connector list contains a list of connectors specified in a process model. Transition list is a list of transitions. Block list is a list of blocks in a process model. Subflow list lists all the subflows referring to already defined process models. Data flow list specifies the explicit data flows defined. Event list has all the events while Data class list has all the data classes contained in a process model. PROCESS [CREATED ] [DESCRIPTION ] [CLASSIFICATION ] [PRIORITY ] [
Permanent Link: http://ufdc.ufl.edu/UFE0000330/00001

Material Information

Title: A Code Generation Approach to Support Dynamic Workflow Management
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000330:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000330/00001

Material Information

Title: A Code Generation Approach to Support Dynamic Workflow Management
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000330:00001


This item has the following downloads:


Full Text











A CODE GENERATION APPROACH TO SUPPORT DYNAMIC WORKFLOW
MANAGEMENT


















By

XIAOLI LIU


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

Xiaoli Liu




























To My Family
















ACKNOWLEDGMENTS

I would like to thank my advisor, Dr. Herman Lam, for giving me an opportunity

to work on this challenging topic and for providing continuous guidance throughout the

course of this work and thesis writing.

I wish to thank Dr. Stanley Su as well for his guidance and support during this

work. Thanks are also due to Dr. Joachim Hammer for agreeing to be on my committee.

I thank Sharon Grant for making the Database Center a great research place, and I

also thank all my friends at the University of Florida for their support and

encouragement.

I thank my parents and my brother for their constant love and support. Thanks

also go to my husband, Haifei Li, and my daughter, Joy Li.
















TABLE OF CONTENTS

page

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

L IST O F FIG U R E S .... .................................. .................... ........ .. .............. vii

A B S T R A C T ............... ................................................................................. ............... ..... ix

CHAPTERS

1 INTRODUCTION .................... .................... ...................1

2 SURVEY OF RELATED W ORK .......................................................... ...............5

2.1 Process M odeling and Process Enactment............................ ....................... 5
2.2 Dynamic Workflow Projects.................... ............................... 6
2.2.1 The EvE Project ....... ... .... ....... .... ........... .. ........ .............. ... 7
2.2.2 The RW S Project ............................................. ...... .. .... .. .......... .. 8
2.3 Virtual Enterprise and Workflow Technology ...................................................... 9
2.3.1 The W ISE Project .................................... ................ .. .. ...... .... 9
2 .3.2 T he C rossF low P roject.......................................................................... .... 10


3 ARCHITECTURE OF THE ISEE WfMS.................. ..................12

3.1 ISEE A architecture ....................................... .......... ...... .......... 12
3 .2 IS E E W fM S .............. ........ ................. ......................................... 15
3.3 Run-Time Architecture of ISEE WfMS ........................................... 17
3.4 Build-Time Architecture of the ISEE WfMS ............................................... 18
3.4.1 Generation of Run-time Workflow Structures................................... 20
3.4.2 G generation of A activity Code.................................... .......................... ........ 21
3.4.3 Sum m ary ...................................... ............................... ........ 22


4 DYNAM IC W ORKFLOW M ODEL....................................... .......................... 23

4.1 WfMC's WPDL .......................................... .... .. .... ........... 23
4.2 Dynamic Workflow Model Specification.................................................... 25
4.2.1 Process M odel Specification...................... .... ........................... 26
4.2.2 A activity Specification ............................................... ........................... 28









4.2.3 Connector Specification...................... ...... ............................ 33
4.2.4 Transition Specification ......................... .... ................. ............ .............. 33
4.2.5 Block Specification...................... ........ .............. .............. 34
4.2.6 Subflow Specification...................... ....... ........................... 35
4.2.7 Data Flow Specification..................... ..... ............................. 35
4.2.8 External Event Specification...................... .... ........................... 36
4.3 Dynam ic Properties of the DW M .................................... .......................... ....... 37


5 RUN-TIME WORKFLOW STRUCTURES GENERATION.............. ...................39

5.1 Run-Time W orkflow Structures Generation................................. .................... 40
5.2 Generated Run-Time Workflow Structures................................. ............... 41
5.2.1 E ntity Structures G generation .................................................. ... ................. 42
5.2.2 Control Flow Structures Generation ................................................. 44
5.2.3 Data Flow Structures Generation........................ ................ 47
5.3 Implementation of the Run-time Structure Generator .......................................... 49
5.3.1 P rocessR T SG enerator........................................................................... .... 50
5.3.2 BeginA ctivityRTSG enerator................................................................. ..... 51
5.3.3 A ctivityR TSG enerator ........................................................ ............. 51
5.3.4 CFSGenerator ..................................... .................... 51
5 .3 .5 D F S G en erator ..................................................... .. ...... ........... 52
5.3.6 SubFlowRTSGenerator.................................................... 52
5.3.7 BlockRTSGenerator........................................................ 53
5.3.8 EndA ctivityR T SG enerator..................................................... ... ................. 53
5.4 Dynamic Changes to The Business Process ................................. .............. 53


6 ACTIVITY CODE GENERATION ................................................... .....................55

6.1 Activity Code Generation ....................................................... .............. 55
6.2 G generated A activity Code..................... .................................... .......................... 58
6.2.1 M em ber V ariables.......................................... ........................ ................. 59
6.2.2 The A activity Constructor ........................................................ ......... ..... 62
6.2.3 The A ctivate M ethod ................................................. .............. ....... .. 63
6.3 Implementation of Activity Code Generator ....................................................... 65
6.3.1 A activity Translator ......................................... .. .. ...... .. .......... .. 66
6.3.2 ActivityCodeGen ... ..... ............................................ .............. 66


7 SUMMARY AND CONCLUSIONS ........................................ ........................ 68

L IST O F R E FE R E N C E S ........................................... ......... ...................... ...................70

BIOGRAPHICAL SKETCH ............ ........ ........... ....... ............... 73
















LIST OF FIGURES



Figure Page

3.1 ISEE Infrastructure ........................... .......... .. ... .. .......... ........ 13

3.2 Overall Architecture of ISEE W fM S ....................................................................16

3.3 The Run-Time Architecture of the ISEE WfMS .................. .................................17

3.4 Run-time Workflow Structures Generation ............................................ ...............20

3 .5 A activity C ode G en eration ..................................................................... .....................2 1

4.1 Process Model OrderProcessing for Distributors in the Supply Chain Community.......25

4.2 Process M odel Specification Language ................................. ....................27

4.3 A activity Specification Language........................................................... ............... 28

4.4 E-Service Request Specification Language............................ .....................31

4.5 BeginActivity Specification Language................................ ......................... ........ 32

4.6 EndA activity Specification Language ........................................ .......................... 32

4.7 C onnector Specification Language...................................................................... ...... 33

4.8 Transition Specification Language ............................................................................ 34

4.9 Subflow Specification Language .............................................................................. 35

4.10 Data Flow Specification Language ................................................... ..................35

4.11 Event Specification Language ............................................... ............................ 36

4.12 D ata Class Specification Language ........................................ .......... ............... 36

5.1 Run-Time Workflow Structures Generation ........................................... ...............40

5.2 Activity Run-tim e Structure............... ........................... ................. ............... 43



vii









5.3 Specification for Activity l/i/irite.\/,l//ig in Process Model "Order Processing".........44

5.4. Run-time Structure for Activity ltl/i/ t.'\ / y / ................... ............................................45

5.5. C control F low Structure ......................................................................... ....................4 5

5.6 Hash table for Transition in Control Flow Structure for C2.......................... .........47

5.7 Data Flow Structure ................ .............................................. ........... 48

5.8 Class Diagram of Run-time Structures Generation ............................... ................50

6.1 A activity C ode G generation ....................................................................... ................... 57

6.2 General Structure of Generated Activity Class................................... ............... 59

6.3 Declarations and Constructor in Code Generated for the Activity lihiiitie.1 /hlpig .......60

6.4 Activate Method in Code Generated for the Activity /i/irite.\nl///yg ...........................62

6.5 Class Diagram for Activity Code Generation............................................................... 65















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

A CODE GENERATION APPROACH
TO SUPPORT
DYNAMIC WORKFLOW MANAGEMENT
By

Xiaoli Liu

December 2001


Chairman: Dr. Herman Lam
Major Department: Computer and Information Science and Engineering

Inter-enterprise workflow technology is a key service needed to coordinate the

activities of different organizations in a virtual enterprise. A Dynamic Workflow Model

(DWM) has been proposed to support dynamic management of inter-enterprise business

processes. The Dynamic Workflow Model (DWM) has the following properties: active,

flexible, adaptive, and customizable. This thesis presents a code generation approach to

support the adaptive property of the DWM, the ability to dynamically change the

activities, control flow, and data flow of an executing workflow instance.

A Code Generator has been designed and implemented. Based on the

specification of a workflow model, the Code Generator generates (1) a set of run-time

workflow structures and (2) activity code. The run-time workflow structures are used by

the Workflow Engine to schedule and execute a workflow instance. Changes can be

made at run-time to the control and data flows of an executing workflow instance by









adding, modifying, or deleting run-time structures. The activity code is generated based

on the activity specifications of a workflow model. During activity code generation,

activity specifications are translated and compiled into Java classes which, when

executed, efficiently request the binding of e-service requests to service providers for

execution. If the specification of an activity is changed, the code for the modified

activity is re-generated and re-loaded using Java's class reloading capability. In this

manner, adaptability is maintained without sacrificing performance, resulting in a

lightweight and efficient Workflow Engine.














CHAPTER 1
INTRODUCTION

Workflow technology and workflow management systems (WfMSs) enable

organizations to model their business processes and control their execution. This allows

organizations to reduce processing time, allocate resources efficiently, and shorten

product time to market. However, traditional workflow management systems currently

available on the market usually work within a single organization and support a static

workflow model.

The rapid growth of the Internet and Web technologies has brought about

significant changes in the way business organizations operate and altered the nature of

business competition. To stay competitive in the rapidly changing and expanding

marketplace, it is often necessary for business organizations to form virtual enterprises

with other businesses to achieve common business goals. In order to work in a virtual

enterprise, characterized by its dynamic nature, the concept of dynamic workflow

management should be introduced to workflow management systems to handle inter-

enterprise business processes.

Today, there are many workflow management systems available on the market

(e.g., Vitria's Business Ware and IBM's MQSeries [GE095, VIT99, MQWOO]). There

are also several research projects which have explored the concept of dynamic workflow

to support workflow management across enterprise boundaries [ELL95, CAS96, REI98,

MUL99]. Recently, several research projects aim to solve workflow management









problems in the virtual enterprise environment [LAZOO, AL099, CRO00, GRE99]. We

will survey these works in Chapter 2.

Currently, there is an on-going project at the Database Systems Research and

Development Center at the University of Florida to build an information infrastructure for

supporting Internet-based Scalable E-business Enterprises (ISEE) [SU01]. A key ISEE

service is the ISEE workflow service which incorporates "dynamic" properties into the

workflow management system (WfMS). The work presented here is a part of that

project. A Dynamic Workflow Model (DWM) has been proposed [MEN01] to model

business processes.

The Dynamic Workflow Model is an extension of the Workflow Process

Definition Language (WPDL) [WFM99a] by including business events and rules to

capture the active properties of business processes. By integrating business processes

with business events and rules, the enactment of a business process can post events to

trigger business rules, which may in turn cause the enactment of other business processes.

The processing of rules enables the dynamic changes made to the business processes.

Connectors are introduced to represent control information (i.e., Split, Join) extracted

from activity definition so that each activity definition is encapsulated and reusable. All

the sharable tasks performed by people or automated systems in a virtual enterprise are

regarded as Web services, or e-services. E-service requests are specified in each activity

definition within a process model according to standardized e-service templates and are

bound to the proper service providers at run-time with the help of the Broker Server.

Therefore, the process models defined are independent of the service providers coming

and going in a virtual enterprise. Dynamic properties are achieved by integrating









business processes with events and rules, and the dynamic binding of e-services with

service providers.

The focus of this thesis is the design and implementation of build-time tools to

support a dynamic workflow management system. Using a "code generation" approach,

the build-time tools generate (1) run-time workflow structures and (2) activity code,

based on the specification of a workflow model. The run-time workflow structures are

used by the Workflow Engine to schedule and execute a workflow instance. Dynamic

changes to the control and data flows of an executing workflow instance can be made at

run-time by changing these run-time structures by invoking methods via the API of the

Workflow Engine.

The generated activity code is in the form of Java code. The Workflow Engine,

when scheduling the activities for a process instance, simply loads the Java activity

classes from a Run-time Repository and executes the code directly to perform specified

tasks. This code generation approach results in a lightweight and efficient Workflow

Engine. It is lightweight because the Workflow Engine does not need the logic to

interpret the activity specification in order to determine how to bind the e-service

requests and calling the bound service provider to perform the e-services. Taking

advantage of the performance of compiled classes, the Workflow Engine is efficient.

Finally, changes to an activity (e.g., e-service requests, performer, performer constraints,

etc.) can be made using a Process Definition Tool. The code for the modified activity is

re-generated and re-loaded using Java's class reloading capability. In this manner, any

change made to an activity specification will be reflected in the execution of the activity









as long as the re-generated code is placed in the Run-Time Repository before the

execution of the activity. Thus, flexibility is maintained without sacrificing performance.

The organization of this thesis is as follows. Chapter 2 presents a survey of

research works related to dynamic workflow management and workflow management in

a virtual enterprise environment. Chapter 3 describes the global architecture of the ISEE

information infrastructure and the dynamic WfMS. The modeling constructs of the

Dynamic Workflow Model are presented in Chapter 4. Chapters 5 and 6 focus on the

details of the run-time workflow structures generation and the activity code generation,

respectively. Chapter 7 provides a summary and conclusion of the thesis.














CHAPTER 2
SURVEY OF RELATED WORK

Inter-enterprise workflow technology is a key e-service to coordinate the activities

of different organizations in a virtual enterprise. In the highly competitive and rapidly

changing and expanding global marketplace, business organizations often find the need to

form virtual alliances with other businesses to achieve various business goals. Unlike a

"real" enterprise when business processes and policies may be relatively static, the

processes and policies of a virtual enterprise are much more dynamic. This chapter

surveys related research focusing on bringing dynamism to workflow management and

projects focusing on workflow management in virtual enterprises.


2.1 Process Modeling and Process Enactment

Process modeling and process enactment are the two essential parts of any

workflow management system. The purpose of process modeling is to produce an

abstract representation of a process model upon which the workflow specification is

based. There are basically two kinds of process modeling methodologies, namely

communication-based, and activity-based [GEO95, SHE96, WIN87]. Communication-

based methodologies stem from "The Winograd/Flores Conversation for Action Model"

[WIN87] in which the progress of a 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 methodology is most frequently adopted by workflow

management systems because it decomposes a process into tasks that are ordered

according to dependencies among them. This kind of process model can be easily turned

into a workflow specification. Most commercial workflow management systems,

including IBM's MQ Workflow [MQWOO, LEY94], adopt this activity-based

methodology in its process modeling. Our project also uses activity-based methodology

to model processes to facilitate the dynamic workflow model specification. Workflow

specification languages are used to describe process models. To capture the

dependencies among activities, workflow specification languages often use rules,

constraints, and/or graphical constructs.

During process enactment, the workflow engine is responsible for interpreting the

process definition, creating the instance of the process, and managing its execution. A

workflow management system may consist of one or more workflow engines. Most

existing commercial workflow systems are centralized in the sense that a single workflow

engine handles the execution of one process instance. For example, MQ Workflow

[MQWOO] adopts the centralized control of one workflow instance. It employs a three-

tier client-server architecture and involves external applications that perform

geographically distributed tasks on different platforms.


2.2 Dynamic Workflow Projects

There have been several projects that focused on various aspects of dynamic

workflow management. Most of them deal with the dynamic changes of process models

used in transitional workflow systems. In Ellis et al. [ELL95], an approach to provide

dynamic changes to a process structure is introduced. The dynamic changes are

accomplished by replacing a given sub-workflow with another completely specified sub-









workflow. This approach makes use of Petri-net formalism to analyze structural changes.

Reichert and Dadam [REI98] presents 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 instance, while

maintaining its (structural) correctness and consistency. The change 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. In this approach, rules are

used to detect semantic exceptions and to determine which activities need to be skipped

or added.

The remainder of this section describes two major projects related to dynamic

workflow management: EvE and RWS.

2.2.1 The EvE Project

EvE [GEP98] is an EVent Engine implementing event-driven distributed

workflow execution. This project was carried out at the University of Zurich. The event

engine performs event registration, detection, and management, as well as event

notification to distributed, reactive software components. In the EvE project, events and

Event-Condition-Action (ECA) rules are used as the fundamental concept for defining

and enforcing workflow logic, and processing entities are used to represent the software

applications that enact the workflow by reacting to events and generating new events. A

broker/services model is used to describe the software and process architecture. In this









model, brokers are interacting, reactive components representing the processing entities.

Broker behavior is defined by ECA rules specifying their reactions to events. The

execution of a workflow starts when some event occurs. The event engine server then

performs event detection and rule execution. While executing the rule, task assignment

determines the brokers to be notified. These brokers then react according to their ECA

rules. Brokers may generate new events, which are again processed by the event engine

until the execution of the workflow is complete. The event-based EvE eases integration

and coordination of the processing entities. Due to this infrastructure, dynamic changes

to the workflow can be achieved by either changing or introducing new ECA rules.

2.2.2 The RWS Project

Reliable Workflow Systems (RWS) [SHR98, WHE98] is implemented at the

University of Newcastle in joint collaboration with Nortel technology. There are two

main components in the system architecture: the workflow repository service and the

workflow execution service.

The workflow repository service stores workflow schemas and provides

operations of initializing, modifying, and inspecting schemas. A scripting language has

been designed for defining the workflow schemas represented in terms of tasks and

dependencies.

The workflow execution service coordinates the execution of a workflow

instance. It records inter-task dependencies of a schema and ensures that tasks are

scheduled to run respecting their dependencies. The dependency information is

maintained and managed by task controllers. Distributed task controller objects

interacting and communicating directly with each other implement the workflow logic.

Dynamic changes to workflow are done by changing the inter-task dependencies, either









in the workflow schema, or directly in the workflow instance, in this case the task

controller.


2.3 Virtual Enterprise and Workflow Technology

The expansion of the Internet and the proliferation of inexpensive computing

power provide the basic hardware infrastructure for B2B electronic business in virtual

enterprise. However, the corresponding software infrastructure is still missing.

Fortunately, there are some ongoing projects to address the limitation. Among them,

WISE and CrossFlow are presented here.

2.3.1 The WISE Project

Workflow based Internet Services (WISE) [AL099, LAZOO] is a project funded

by the Swiss National Science Foundation. Its objective is to design, build, and test a

commercially viable infrastructure for business to business e-commerce in the form of a

working system capable of defining, enacting, and monitoring virtual enterprise business

processes. The infrastructure provides an Internet workflow engine acting as the

underlying distributed operating system controlling the execution of business processes, a

process modeling tool for defining and monitoring the processes, and a catalogue tool for

virtual enterprise services. There are four components in the WISE architecture, namely,

process definition, process enactment, process monitoring, and process coordination.

* The process definition component defines virtual business processes with available
services offered by different companies in the virtual enterprise.

* The process enactment component controls the execution of the process by invoking
the corresponding services of the virtual enterprise.

* The process monitoring component keeps track of the progress made in the execution
of the virtual enterprise business process.

* The process coordination component supports multimedia conferencing and browsing
of relevant information between all participants in the virtual enterprise.









In WISE, different companies join their services to form a virtual enterprise, which

provides a business process that can be executed over the Internet. The workflow system

provided in WISE, however, does not have the facilities to capture and manage the

dynamic properties of business processes.

2.3.2 The CrossFlow Project

CrossFlow [LUD99, CRO00] is a European research project for supporting cross-

organizational workflow management in virtual enterprises. In this project, IBM's

MQSeries Workflow is used. The goal of this project is to develop and implement the

mechanism for connecting WfMS and other WfMS-like systems of different

organizations in dynamically formed virtual organizations. Virtual organizations are

dynamically formed by contract-based matchmaking between service providers and

consumers. In CrossFlow, there is a trader known to consumers for service providers to

post services. If a process in a WfMS requires some services from another organization,

the WfMS sends a request to the search manager to look for suitable service providers.

After the service provider is found and a contract is made between the consumer and the

provider, the service can be initiated and a process in the provider WfMS can be activated

on behalf of the consumer. Different workflow systems are linked through proxy

gateways, which are dynamically generated modules at organizational boundaries. A

flexible change control mechanism is also introduced in CrossFlow to react to potential

problems during a workflow execution.

The ISEE dynamic workflow management system (WfMS) described in this

thesis supports dynamic workflow management. By introducing events, triggers, rules,

and constraint-based dynamic service binding, our process model can capture more

dynamic properties, such as active, flexible, adaptive and customizable. The integration






11


of constraint-based dynamic service binding, event, trigger, and rule mechanism with

business processes provides a comprehensive solution to inter-enterprise workflow

management. The code generation approach described in this thesis supports the

dynamic properties in the ISEE WfMS.














CHAPTER 3
ARCHITECTURE OF THE ISEE WfMS

A research project on advanced technologies to support Internet-based Scalable E-

business Enterprises (ISEE) is in progress at the Database Systems Research and

Development Center of the University of Florida. Its purpose is to build an advanced

information infrastructure capable of providing ISEE services for collaborative e-

business [SU01]. One of the key services provided by the ISEE information

infrastructure is the ISEE Workflow Management System (WfMS) which implements the

dynamic workflow service.

This chapter describes the overall ISEE architecture, and the overall architecture

of the ISEE WfMS. Section 3.1 describes the ISEE architecture, followed by an

introduction of the overall architecture of the ISEE WfMS in Section 3.2. Section 3.3

presents the run-time architecture of the ISEE WfMS, while Section 3.4 describes the

build-time architecture of the ISEE WfMS.


3.1 ISEE Architecture

With the Internet, World Wide Web (WWW), and other existing Information

Technologies (IT), a user today can connect to Web servers, access their back-end

database systems, and transact business. The emerging distributed object technology

further enhances the information technology by allowing distributed applications to be

invoked in a structured manner, in forms of communicating Distributed Objects (DOs).

DOs can be used to encapsulate existing application systems and to develop new









applications. Their services are accessible by users through Web browsers. Thus, the

current (Web + existing IT) paradigm provides a basic infrastructure over the Internet to

interconnect enterprises and allow data and application systems to be shared among

customers, suppliers, and business partners.

Warehouses & Browser DO Agent ADO Transportation
Distribution Centers Ap Companies

"ISEE Hub ISEE Infrastructure ISEE Hub



ISEE Hub IfSEE Huh ISEE Hub
Manufacturers &
Suppliers (a). Overall Architecture Retailers


(b). An ISEE Hub

Figure 3.1 ISEE Infrastructure



In [SU01], an information infrastructure to support an ISEE was proposed to

enable collaborative e-business among multiple organizations to conduct business over

the Internet. In an ISEE, the basic infrastructure is enhanced to, not only support the

sharing of data and application systems over the Internet, but also provide ISEE services

necessary for collaborative e-business and other general distributed applications. That is,









ISEE Infrastructure = Web + Existing IT + ISEE Services for Collaborative e-

business.

The proposed infrastructure and its relationship with existing application systems,

distributed objects, agents, active distributed objects, Web browsers, and Web servers in

a virtual enterprise environment are shown in Figure 3.1. In Figure 3.1(a), ISEE hubs are

replicated and deployed at the sites of participating ISEE members, much the same way

the Web servers are deployed now to support Web services. As shown in Figure 3.1(b),

each ISEE hub consists of a number of ISEE servers such as an Event Server, an Event-

Trigger-Rule (ETR) Server, a Workflow Server, a Broker Server, a DO Server, a Web

Server, and other general purpose servers. Internet users can still use the Internet and

Web services as they are but the ISEE members can have access to the additional

services.

The ISEE servers in an ISEE hub work together to provide a wide range of

collaborative ISEE services to connected members. We have been developing and

integrating a number of what we regard as the core information infrastructure

technologies and services. They include active distributed object modeling, business

event management, business rule management, messaging infrastructure for inter-

enterprise communication, cost-benefit analysis and evaluation, trust management and

access control, and constraint satisfaction processing. Other services needed to support

collaborative e-business, such as constraint-based brokering, supplier selection,

automated negotiation, dynamic workflow modeling and control, can be built upon these

core technologies. The implementations of all these services in forms of servers are

intended to complement the services by the Internet and Web.









The dynamic workflow service is a key ISEE service for managing inter-

enterprise processes, and is the focus of this thesis. In a virtual enterprise, business

processes such as an e-supply-chain, can cross company boundaries. Thus, workflow

systems are required to manage business processes across enterprise boundaries. Unlike

a "real" enterprise when business processes and policies may be relatively static, the

processes and policies of a virtual enterprise are much more dynamic. In chapter 4, a

Dynamic Workflow Model is presented to support the management of inter-enterprise

business processes.


3.2 ISEE WfMS


The ISEE WfMS is the implementation of the ISEE dynamic workflow service.

The architecture of the ISEE WfMS is shown in Figure 3.2. It involves several servers

including a centralized Broker Server; and several servers in an ISEE hub: an Event

Server, an ETR Server, and a Workflow Server.

The constraint-based Broker Server provides information about service providers.

It also performs dynamic service binding to bind a requested e-service specified in an

activity of an inter-enterprise process workfloww) to a specific service provider at run-

time. In order to communicate with the Broker Server, a Broker Proxy is installed in

each ISEE hub. All sharable tasks, which can be performed by different organizations,

are considered as e-services. An e-service adapter exists in each organization to wrap its

e-services so that the organization's e-services can be invoked in the execution of an

inter-enterprise business process. The Event Server manages events coming to and

leaving an ISEE hub. The ETR Server takes care of event, trigger and rule processing.












Organization 1



.. ....: ..._.L.... ... ... ..
S--------- -----------alL
I I ISEE
Hub
Broker Server Workflow Server Broker Proxy






ISEE IIl ll I IR %.iai ISEE
Hub I flub
Workflow Server Broker Proxy I Workflow Server Broker Proxy
. . . --,- -- . .. ..-. . .

S.- nk.. ipl I..r u ir .. ..v 1 ... .villple

Organization 2 Organization 3 Organization 4




Figure 3.2 Overall Architecture of ISEE WfMS





The Workflow Server is the key component of the ISEE WfMS. The

implementation of the Workflow Server is based on workflow technology which enables

the modeling of business processes and automates the control of their execution. Before

we continue, let us define some terms. A work/low model (also called process model) is

used to model a business process and consists of a network of activities and their

control/data flow of these activities. A workflow model can be instantiated as a workflow

instance (also called process instance) and executed in the Workflow Server. The

Workflow Server is composed of a set of build-time tools and the Workflow Engine. The

build-time tools include the Process Definition Tool (PDT) and the Code Generator. The

PDT is a Graphical User Interface (GUI) used to define and edit workflow models (note

these are also called process models). The Code Generator is used to generate run-time









workflow structures and activity codes according to workflow model specifications

defined with PDT. The Workflow Engine schedules and executes workflow instances

according to the workflow model specifications.


3.3 Run-Time Architecture of ISEE WfMS


The run-time architecture of the ISEE WfMS is shown in Figure 3.3. The main

components involved in the architecture are:


Figure 3.3 The Run-Time Architecture of the ISEE WfMS



1. Workflow Engine: The Workflow Engine manages the execution of a business
process until completion by assigning activities to each specified performer at the
specified time. During the execution, the Workflow Engine makes use of other
collaborative ISEE services provided by other servers, namely, 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 WfMS. While executing a workflow
instance, the Workflow Engine may post asynchronous events to the Event Server,









which then notifies the subscribers of these events. It may also post synchronous
events to the ETR Server to trigger rules attached to the events. The Workflow
Engine also contacts the Broker Server through the Broker Proxy to obtain service
provider information for e-service requests specified in the activities of a process
model. After a qualified service provider is selected, the Workflow Engine invokes
the specified service through an e-service adapter.

2. Event Server: The Event Server provides the publish-subscribe model of an event
service for asynchronous events. At the Event Server, event providers publish
available events, while event consumers, as participants of the virtual enterprise, can
subscribe or unsubscribe to events of their interest. When an event is posted, the
Event Server will notify all subscribers to that event. The Workflow Engine, as one
of the event providers, may post asynchronous events to the Event Server. The Event
Server is also connected with the Event Servers in other ISEE hubs to notify them of
events and receive event notifications from them.

3. ETR Server: The ETR Server and the Event Server provide the "active" property of
the Dynamic Workflow Model. At run-time, the events specified in a Dynamic
Workflow Model will be posted to the Event Server and the ETR Server to trigger
rules in the ETR Server. The ETR Server is a subscriber to an Event Server. Thus,
the ETR Server may receive event notifications from the Event Server (for
asynchronous workflow events). Also, the ETR Server may receive events directly
from the Workflow Engine (for synchronous workflow events). The posted events
will activate all triggers associated with that event. The event history specified in a
trigger will be processed and appropriate rules will be executed.

4. Broker Server: The Broker Server allows e-service providers to register and publish
their e-services in terms of descriptive attributes and constraints through GUIs. It
manages the registered e-service information and processes inquiries to service
provider information. The e-service requests are also specified in terms of descriptive
attributes and constraints. The Broker Server makes use of a Constraint Satisfaction
Processing (CSP) server as its key component. The CSP is used by the Broker Server
to dynamically bind e-service requests to e-service specifications and their providers
according to the e-service requests specifications and their constraints.

5. Broker Proxy: The Broker Proxy in each ISEE hub maintains communication with the
remote Broker Server. The Workflow Engine contacts the Broker Server through the
Broker Proxy.

3.4 Build-Time Architecture of the ISEE WfMS


The build-time architecture discussed in this thesis is designed to support a code

generation approach to realize a dynamic workflow management system. The main









components involved in the build-time architecture of the ISEE WfMS are outlined

below.

1. MetaData Manager: The MetaData Manager is a server which provides a persistent
repository for storing meta-information. The specifications for process model, data
classes, event, rule and e-service request constraints are captured using GUI editors
and stored in the MedaData Manager. Components of the ISEE WfMS make
references to the MetaData Manager to access the specifications. The MetaData
Manager is built on top of a Persistent Object Manager (POM) [SHE01]. It was
developed for IKnet [LEEOO, SUOO] and is extended in our project to support
workflow concepts.

2. GUI Editors: Three GUI editors are involved in defining a process model, namely, the
Process Definition Tool (PDT), the Knowledge Profile Manager (KPM), and the
Constraint Definition Tool (CDT). The Process Definition Tool is used to specify
various parts of a process model, including activities, transitions, connectors, etc..
Knowledge Profile Manager is invoked from the PDT to define events, triggers, and
rules related to a process model. The definitions of events generated by the process
models are sent to both the ETR Server and the Event Server to perform installation
operations. Also, the Constraint Definition Tool is invoked from the PDT to define
constraints associated with the e-service requests specified in the process models.

3. Code Generator: The focus of this thesis is the Code Generator component used to
support the dynamic workflow management system. The Code Generator translates
the process model specifications into run-time workflow structures. The run-time
workflow structures generation separates the run-time workflow structures from the
process model specifications and supports the dynamic changes to a business process.
The Code Generator also generates the code to implement the activities specified in a
process model. Activity code generation results in an efficient and lightweight
Workflow Engine and also supports dynamic changes to a business process.
Specifically, activity specifications are translated and compiled into Java classes.
These Java classes, when executed, perform tasks specified in the activities and may
invoke the Broker Server for dynamic binding of the e-service requests with
appropriate e-services and their providers. The compiled activity codes benefit the
performance of the Workflow Engine. When the Workflow Engine is going to
execute a workflow instance, it will read in the run-time workflow structures
generated for the appropriate process model. According to the run-time workflow
structures, activities are scheduled and executed by loading the corresponding activity
code already generated. The Code Generator generates run-time workflow structures
and activity code to support a combination of "interpretative" and "code generation"
approach to realize dynamic workflow management.










3.4.1 Generation of Run-time Workflow Structures



Figure 3.4 illustrates how the main components are related to each other during

the generation of run-time workflow structures.


Generate
run-timne
structures


WF Engine
Get run-tmne
structures


Figure 3.4 Run-time Workflow Structures Generation




The Process Definition Tool is used to define new process models and edit

existing ones. The process model specification is saved in the MetaData Manager. The

Run-time Structures Generator is invoked to generate run-time workflow structures

according to the process model specification. The generated run-time workflow

structures will be written to a serialization file and stored into the run-time repository to

be used by the Workflow Engine to execute the workflow instance. The process model

specification is separated from the workflow execution environment by run-time

workflow structures generation. Dynamic changes to a business process during process










enactment can be accomplished by modifying the corresponding run-time structures of

the process model.

3.4.2 Generation of Activity Code


Figure 3.5 shows how the main components are related to each other during the

generation of activity code.


____ activity
spec Generate
and deploy
activity
code


WF Engine


Figure 3.5 Activity Code Generation



The Activity Editor is a component of the Process Definition Tool. It is used to

define new activities and edit existing activities in a process model. While defining an

activity, the Activity Editor may invoke KPM to define external events in the activity, or

it may invoke the Constraint Definition Tool to define e-service request constraints,

depending on the type of tasks the activity is going to perform. Activity, event, and e-

service request constraint specifications are stored in the MetaData Manager. The









Activity Code Generator is invoked by the Process Definition Tool to generate the Java

code according to the activity specifications and to compile them. Finally, the compiled

Java class files are placed into a run-time repository ready for the Workflow Engine to

use.

3.4.3 Summary


The chapters that follow will present the details of the code generation approach

to support the dynamic ISEE workflow management system. Chapter 4 presents the

Dynamic Workflow Model specification. Chapter 5 focuses upon run-time workflow

structures generation, and Chapter 6 focuses upon the code generation for activities.














CHAPTER 4
DYNAMIC WORKFLOW MODEL

The rapid growth of the Internet has made it necessary for different organizations

to form virtual enterprises to do business together in order to stay competitive in the

market. In order to work in a virtual enterprise environment, workflow systems have to

be able to manage business processes across enterprise boundaries. As the processes and

policies of a virtual enterprise are much more fluid, the inter-enterprise workflow system

is required to have the capability of accommodating the changing business policies and

strategies of participating organizations, handling expected and unexpected situations,

and support dynamic changes to business processes.

In [MEN01], a Dynamic Workflow Model is proposed to model inter-enterprise

business processes. This chapter describes the modeling constructs of the Dynamic

Workflow Model. Section 4.1 summarizes WfMC's Workflow Process Definition

Language (WPDL) [WFM99a] upon which the Dynamic Workflow Model is based.

Section 4.2 presents the specifications for different entities in the Dynamic Workflow

Model. Section 4.3 is a summary of dynamic properties provided by the Dynamic

Workflow Model.


4.1 WfMC's WPDL

The Workflow Management Coalition (WfMC) [WFM99a, WFM99b] was

founded in August 1993. It has been established to identify functional areas and develop

appropriate specifications for implementation in workflow products. The Coalition's









mission is to promote the use of workflow technology through the development of

standards for software terminology, interoperability, and connectivity between workflow

products.

The Workflow Process Definition Language (WPDL) is one of the major

contributions of WfMC. It is a language for describing workflow models in a structured

and standardized manner for the interchange of process definitions. With WPDL, a set of

activities can be defined with conditioned transitions to enable conditioned branching

from activities to activities. In WPDL, the activity information include the specifications

of Join and Split constructs and their constraints (AND, OR, and XOR). These constructs

help define the structural relationships and constraints among activities. In a process

model defined with WPDL, the data flows are implicitly defined by making use of global

variables, which are called workfloww reference data". This makes the data relationship

between activities unclear. Also a process model defined with WPDL is static.

The Dynamic Workflow Model (DWM) specification is an extension to WfMC's

WPDL [WFM99a] to support the dynamic ISEE WfMS. Extensions and modifications to

the WPDL include more modeling constructs such as connectors, events, triggers, rules,

data flow, and e-service requests.

Graphically, a Dynamic Workflow Model can represent a business process using

a dynamic process model diagram. An example process model diagram, named "Order

Processing" is shown in Figure 4.1. This figure will be used throughout the remainder of

the chapter to illustrate modeling constructs in the Dynamic Workflow Model.










4.2 Dynamic Workflow Model Specification


In order to support the dynamic nature of business processes in a virtual

enterprise, the following extensions and modifications are made to the WPDL to form the

DWM specification.

1. Introduction of Connectors: The specification of Join and Split constructs and their
constraints (AND, OR, and XOR) is embedded in the specifications of activities in
WPDL. The specification of this control information is extracted and represented by
a new modeling construct named Connector. The introduction of connectors
separates control flow information from the activity specification so that any change
made in an activity will not affect the control flow and vice versa. This separation
facilitates the dynamic changes to a business process.


Distributor (ANY) T1


Distributor (SameAs OrderEntry) IT2


-------9


___ D1
SYNC


..____.I


ASYNC
T3

Distributor (SameAs OrderEntry) AND Transportation Agency (ANY)


ASC--------
i647 ASYNC


Legend:

: Activity

O :Connector
o : Condition

S: Before-
Activity-Event
CD : After-
Activity-Event
-- : Transition
----- : WF Event Posting
e---+ Data Flow


Figure 4.1 Process Model OrderProcessing for Distributors in the Supply Chain
Community



2. Encapsulation of the activity specification: The specifications of input and output
parameters are added to the WPDL's activity specifications. An activity can only
reference the data passed to it by the input parameters. Secondly, the only data









outputted by an activity is through its output parameters. Thus, the activity
specification is encapsulated.
3. Inclusion of e-service requests in activity specification: In an activity specified within
a process model for an inter-enterprise workflow, there may exist tasks which can be
performed by different business organizations. The business organizations which
actually provide the requested e-services (we call these organizations service
providers) can be dynamically bound to the e-service requests at run-time by the
Broker Server according to constraints associated with e-service requests.

4. Introduction of Data Flows: In WPDL, data transfer among activities is through the
workflow relevant data, which can be accessed by all workflow process definitions
(and associated activities and transitions). In DWM, Data Flows are used to define
inter-activity parameter mapping information. The introduction of Data Flows is used
to eliminate any possible ambiguity in data relationship between activities.

5. Introduction of events, triggers, and rules: Events, triggers and rules are introduced to
the process model specification as an important part of the DWM. Activities
specified in a DWM can post events. Three different types of events can be posted,
namely, Before-Activity-Event, After-Activity-Event, and External Events. A
Before-Activity-Event can be posted before an activity is started. An After-Activity-
Event can be posted after an activity is completed. External events are published
"user defined" events posted inside an activity. When an activity is activated during
the execution of a business process instance, their events are posted to automatically
trigger the processing of some business rules. These rules are Event Condition
Action (ECA) or Event Condition Alternative Action (ECAA) rules. The processing
of these rules may cause some actions taken to enforce some business policies,
regulations, or constraints. It may also cause the execution flow of the process
instance to be modified, for example, by skipping some activities. With events,
triggers, and rules, different users can attach different sets of rules to the same process
model. The execution of different workflow instances can trigger different sets of
rules. Therefore, one process model can be tailored to fit different organizations'
needs.

4.2.1 Process Model Specification

A process model is specified in terms of its modeling constructs. In DWM, there

are eight different modeling constructs including activity, connector, transition, block,

subflow, data flow, event, and data class. The syntax of a process model specification


language is shown in Figure 4.2.










The pair of brackets, "[]", indicates the clauses surrounded are optional. The

CREATED, DESCRIPTION, CLASSIFICATION, PRIORITY, time estimation and

DOCUMENTATION clauses specify the descriptive attributes of a process model.

Activity list contains a set of activities specified in a process model. Activities

are the most important components in a process model. They are used to define tasks that

need to be fulfilled for a business process. There are two special types of activities in

DWM: BeginActivity which indicates the entry point of a process model or a block, and

EndActivity which indicates the end point of a process model or a block. Each process

model or block can have only one BeginActivity and one EndActivity.


PROCESS
[CREATED ]
[DESCRIPTION ]
[CLASSIFICATION ]
[PRIORITY ]
[