A model-driven workflow fragmentation framework for collaborative workflow architectures and systems

Journal of Network and Computer Applications 35 (2012) 97–110

Contents lists available at ScienceDirect

Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca

A model-driven workflow fragmentation framework for collaborative workflow architectures and systems Kwanghoon Kim  Collaboration Technology Research Lab, Department of Computer Science, Kyonggi University, South Korea

a r t i c l e i n f o

abstract

Article history: Received 3 September 2010 Received in revised form 11 January 2011 Accepted 29 March 2011 Available online 13 April 2011

This paper focuses on a workflow distribution methodology for rationally deploying workflow models onto a distributed workflow system running on cloud computing environments, and we particularly lay a stress upon that those workflow systems operable on cloud computing environments are dubbed collaborative workflow systems, which are not only built upon the collaborative workflow architectures proposed in the paper, but pursuing the so-called collaborative computing paradigm characterized by focusing collaboration over cloud computing environments. The essential idea of the workflow distribution methodology is about how to fragment a workflow model and how to allocate its fragments to each of the architectural components configuring the underlying collaborative workflow architecture and system. As a reasonable solution to realize the essential idea, the paper proposes a model-driven workflow fragmentation framework, which provides a series of fragmentation algorithms that semantically fragmentate a workflow model by considering the semantic factors – performer, role, control-flow, data-flow, etc. – of the ICN-based workflow model as fragmentation criteria. The algorithms are classified into the vertical fragmentation approach, the horizontal fragmentation approach, and the hybrid approach of both. Conclusively, this paper conceives a possible set of collaborative workflow architectures embedding the collaborative computing paradigm, and describes the detailed formalism of the framework and about how the framework works on those collaborative workflow architectures and systems. & 2011 Elsevier Ltd. All rights reserved.

Keywords: Structured ICN workflow model System-driven workflow fragmentation Model-driven workflow fragmentation Collaborative workflow architecture Workflow resource allocation Collaborative computing paradigm Cloud computing environments

1. Introduction A workflow management system (WfMS) is defined as a system that partially or fully automates the definition, creation, execution, and management of work procedures (workflows) through the use of software that is able to interpret the workflow definition, interact with workflow participants and invoke the use of IT tools, scripts and applications; and the majority of WfMS’s infrastructures (Martin et al., 2008) for deploying and enacting workflow services, so far, has been pursuing the distributed computing paradigm, which is conceptually focusing on parallelization, distribution and sharing over distributed computing environments such as server–client, clustering, grid and P2P computing environments. However, as the cloud computing environment is recently hot-issued as an emerging new and powerful computing environment, it is increasingly needed to adopt the cloud computing environment as WfMS’s infrastructure; consequently, it becomes a catalyst for the emerging concept of cloud workflow architectures and systems. More

 Tel.: þ 82 10 5231 9679; fax: þ82 31 249 8949.

E-mail address: [email protected] URL: http://ctrl.kyonggi.ac.kr 1084-8045/$ - see front matter & 2011 Elsevier Ltd. All rights reserved. doi:10.1016/j.jnca.2011.03.029

precisely speaking, in the distributed computing paradigm based on the cloud computing environment, the conceptual focus is not on parallelization, distribution and sharing but on collaboration (Liu et al., 2009), and so, the paradigm has been particularly dubbed collaborative computing paradigm,1 which is becoming a conceptual basis for the so-called collaborative workflow architectures and systems2 as well as a technological background of this paper. In configuring a distributed workflow architecture, it might be very important to determine criteria of how to fabricate its architectural components and how to deploy and allocate workflow models and workflow resources to them, as well; those works of configuring, deploying and allocating workflow models are called a workflow distribution methodology. There are two styles of workflow distribution methodologies: system-driven and model-driven. Almost all of the traditional distributed workflow architectures aiming at operable on server–client, cluster, grid or P2P computing environments are apt to take the systemlevel functional aspects of workflow systems as the architectural criteria; their primary goal is to ensure the computing power for

1

This terminology has been defined by the co-editors of this special issue. The author has defined this terminology according to the conceptual definition of collaborative computing paradigm. 2

98

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

enacting workflow models with a certain level of transparencies in parallelization, distribution and sharing of workflow resources, and so we would say that it is the style of system-driven workflow distribution methodologies (Tomaz et al., 2009), because configuring architectural components and fragmenting and deploying workflow models might be done model-independently. While on the other hand, in configuring a collaborative workflow architecture based upon cloud computing environments, the primary architectural theme is shifted into collaboration, not distribution as mentioned before, and so it is crucial to consider not only how to directly reflect the collaboration aspects on workflow models into the architectural collaborations, but also how to deploy and allocate workflow models and resources onto those collaborative architectural components. Consequently, those methodological works have to be done model-dependently, and so it is called the style of model-driven workflow distribution methodologies. Furthermore, in the style of model-driven workflow distribution methodologies, the most essential work is to devise a framework for fragmenting a workflow model and deploying its fragments onto the underlying collaborative architectural components. As the scope of this paper, we propose a model-driven workflow fragmentation framework, which provides a series of workflow fragment algorithms that fragmentates a workflow model into a group of workflow fragments and distributes them onto the architectural components of an underlying collaborative workflow architecture. Summarily, this paper focuses on the model-driven workflow distribution methodology consisting of the architectural configuration step configuring model-driven collaborative workflow architectures, and the model fragmentation step fragmenting a workflow model by one of the model-driven workflow fragmentation techniques and deploying its fragmented models to the corresponding architecture. The framework is based upon the information control net (ICN) methodology (Ellis, 1979) to represent workflow models. The ICN-based workflow modeling methodology was originally developed to describe and analyze information flows by capturing several entities within work procedures, such as activities, roles, actors, activity precedences, applications, and relevant-data/repositories. Note that it has been used within actual as well as hypothetical automated offices (1) to yield a comprehensive description of activities, (2) to test the underlying office description for certain flaws and inconsistencies, (3) to quantify certain aspects of office information flow, and (4) to suggest possible office restructuring permutations. For the sake of algorithmic simplicity, it is assumed that the ICN-based workflow model used in the paper preserves the structural properties – proper nesting and matched pairing

properties (Park and Kim, 2008) – as a structured workflow model (Liu and Kumar, 2005). Once a structured workflow model is defined by using the ICN methodology, it is fragmented and deployed over its corresponding collaborative workflow architecture according to the proposed framework. In the workflow literature, there has not been existing any types of the model-driven workflow fragmentation methods, as yet. So,the remainders of this paper describe the details of the architectural styles to be devised as the model-driven collaborative workflow architectures, and exemplify that the model-driven workflow fragmentation approaches are able to handle all of the possible fragmentation cases through the concepts of vertical and horizontal fragmentation methods. That is, the next sections present the meta-model of the structured workflow model with graphical and formal notations, formalize the model-driven workflow fragmentation framework that gives a detailed description about how to fragment a workflow model—vertical fragmentation vs. horizontal fragmentation, and illustrate those approaches and their detailed descriptions as well as related algorithms with some examples. Finally, the paper finalizes with an example through an operable architecture with the role-based fragmentation algorithm in order to show how the fragmentation approaches are feasibly applicable in realizing a certain style of collaborative workflow architecture and system.

2. ICN-based structured workflow model In this paper, basically it is assumed that the information control net methodology (Ellis, 1979) is used to represent structured workflow models (Liu and Kumar, 2005) to be deployed on the collaborative workflow architectures proposed in the paper. So, this section describes the details of the structured workflow modeling concept as a theoretical basis of the model-driven workflow distribution methodology defined in this paper. 2.1. Workflow meta-model In describing a structured workflow model, the literature has been using the basic workflow terminology—workflow procedure, activity, job, workcase, role, actor/group, and invoked application including web services. These terms become the primitive entity types to compose workflow models, and also they have appropriate relationships with each other as shown in Fig. 1. These entity types and their relationships play an important roles as the fundamental criteria for the model-driven collaborative workflow architectures and their fragmentation

Fig. 1. The workflow meta-model.

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

algorithms. The followings are the basic definitions of the primitive entity types:

 A workflow procedure is defined by a predefined or intended set





 



of tasks or steps, called activities, and their temporal ordering of executions. A workflow management system eventually helps to organize, control, and execute such defined workflow procedures. Theoretically, a workflow procedure can be formalized by a temporal order of the associated activities through the combinations of sequential logics, conjunctive logics (after activity A, do activities B and C) and disjunctive logics (after activity A, do activity B or C). A activity is a conceptual entity of the basic unit of work (task or step), and the activities in a workflow procedure have precedence relationships, each other, in terms of their execution sequences. Also, the activity can be precisely specified by one of the three entity types—compound activity, elementary activity and gateway activity. The compound activity represents an activity containing another workflow procedure, which is called subworkflow. The elementary activity is an activity that can be realized by a computer program, such as application program, transaction, script, or web service. And the gateway activity implies an activity that is used to controlling execution sequences of elementary/compound activities. The types of gateway activities consist of conjunctive gateway (after activity A, do activities B and C), disjunctive gateway (after activity A, do activity B or C), and loop gateway. Particularly, both the disjunctive gateway and the loop gateway need to be set some specific transition-conditions in order to select one of the possible transition pathes during the execution time. The transition-condition itself can be defined by using the input/output relevant-data on the repository. Additionally, each activity has to be associated with a real performer, such as organizational staff (role, participant) and system, who possesses all ownerships over that activity. A role, as a logical unit of the organizational structure, is a named designator for one or more participants, which conveniently acts as the basis for participating works, skills, access controls, execution controls, authority, and responsibility over the associated activity. An actor is a person, program, or entity that can fulfill roles to execute, to be responsible for, or to be associated in some way with activities and workflow procedures. Multiple instances of a workflow procedure may be in various stages of execution. Thus, the workflow procedure can be considered as a class (in object oriented terminology), and each execution, called a workcase, can be considered an instance. A workcase is thus defined as the locus of control for a particular execution of a workflow procedure. An invoked application program that automatically performs the associated activity, or provides automated assistance



99

within hybrid activities are called scripts. If an activity is executed in automatic or hybrid mode, this means that whole/part-of the invoked application program associated with the activity is automatically launched by a workflow enactment service. Finally, a repository is a set of input and output relevant-data of an activity. Eventually, the repository provides a communication channel between the workflow enactment domain and the invoked application programs domain. That is, the input and the output repositories are used to realizing the input parameters and the output parameters of the associated invoked application program, respectively.

2.2. Structured information control net We focus on the activities and their related information flows by defining the ICN-based structured workflow model (Kim and Ellis, 2009), which is the target workflow model of the model-driven workflow fragmentation framework proposed in the paper, through a set of graphical constructs and their formal representation. Graphical representation: As shown in Fig. 2, a structured workflow model (Liu and Kumar, 2005) consists of a set of activities connected by temporal orderings called activity transitions. In other word, it is a predefined set of work steps, called activities, with a partial ordering (or control flow) by combining sequential transition types, disjunctive transition types (after activity aA , do activity aB or aC , alternatively) with predicates attached, and conjunctive transition types (after activity aA , do activities aB and aC concurrently). Particularly, the disjunctive and conjunctive transition types must keep the structured properties of proper nesting and matched pairing in defining workflow models. An activity may be either a compound activity containing another subprocess, or a basic unit of work, which is called a work activity. The work activity is executed in one of three modes: manual, automatic, or hybrid, and is mapped to a role that takes charge of enacting the corresponding one, as shown in the lefthand side of Fig. 2. Fig. 3 is a simple example of the structured workflow model with three roles and five participants. Note that the AND-Control nodes (AND-split and AND-join that are presented by solid dots ðÞÞ, and the OR-Control nodes (OR-split and OR-join that are represented by hollow dots ð3ÞÞ, in a model must be properly nested and matched paired in order to build a structured workflow model. Formal representation: The structured workflow model needs to be represented by a formal notation that provides a means to eventually specify the model in textual language or in database, and both. The following definition is the formal representation of the structured workflow model: structured workflow model (SWM). A basic structured workflow model is formally defined through 4-tuple G ¼ ðd, e, p, k,I,OÞ over an activity set A, a

Fig. 2. Graphical notation of the structured ICN primitives.

100

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

general,

do ðaÞ ¼ f fb11 , b12 , . . . , b1mð1Þ g, fb21 , b22 , . . . , b2mð2Þ g, ..., fbn1 , bn2 , . . . , bnmðnÞ g g

Fig. 3. A simple structured workflow model.

role set R, a participant set P, and a transition-condition set T, where

 I is a finite set of initial input repositories, assumed to be  







loaded with information by some external workflows before execution of the model; O is a finite set of final output repositories, which is containing information used by some external workflows after execution of the model; d ¼ di [ do , where, do : A!YðAÞ is a multi-valued mapping function of an activity to its set of (immediate) successors, and di : A!YðAÞ is a multi-valued mapping function of an activity to its set of (immediate) predecessors; e ¼ ea [ er where er : A!YðRÞ is a single-valued function mapping an activity to a role, and ea : R!YðAÞ is a multivalued function mapping a role to its sets of associated activities; p ¼ pr [ pp where, pp : R!YðPÞ is a multi-valued function mapping a role to its sets of associated participants (actors), and pr : P!YðRÞ is a multi-valued function mapping a participant to its sets of associated roles; k ¼ ki [ ko , where ki : A!YðTÞ is a multi-valued mapping function of an activity to its incoming transition-conditions ð A TÞ on each arc, ðdi ðaÞ, aÞ; and ko : A!YðTÞ is a multi-valued mapping function of an activity to its outgoing transitionconditions ð A TÞ on each arc, ða, do ðaÞÞ.

Starting and terminating nodes: Additionally, the execution of a workflow model commences by a single l transition-condition. So, we always assume without loss of generality that there is a single starting node ðaI Þ. At the commencement, it is assumed that all input repositories in the set I have been initialized with data by the external system: (aI A Ajdi ðaI Þ ¼ |4ko ðaI Þ ¼ fflgg: The execution is terminated with any one l output transitioncondition. Also we assume without loss of generality that there is a single terminating node ðaF Þ. The set of output repositories O is data holders that may be used after termination by the external system: (aF A Ajdo ðaF Þ ¼ |4ki ðaF Þ ¼ fflgg: Implication: structured modeling methodology preserving the proper nesting and the matched pairing properties: Given a formal definition, the structured ordering of a workflow model can be interpreted as follows: For any activity a ðd ¼ di [ do Þ, in

means that upon completion of activity a, either a set of transitions that simultaneously initiates all of the activities bi1 through bimðiÞ occurs, or a transition that only one value of bi1 ið1 ri rnÞ is selected as the result of a decision made within activity a occurs, or both. In general, if n ¼ 1, then no decision is needed and a is not a decision node. If also m(i) ¼ 1 for all i, then no parallel processing is initiated by completion of a. (Note that bij A f8a,f|gg, ð1 r ir nÞ,ð1 r j r mÞ.) In the SWM graphical notation, the former, that an activity has a conjunctive (or parallel) outgoing transition, is represented by a solid dot – AND-split, and the latter, that an activity has a disjunctive (or decision) outgoing transition, is represented by a hollow dot – OR-split. And also,

di ðaÞ ¼ f fb11 , b12 , . . . , b1mð1Þ g, fb21 , b22 , . . . , b2mð2Þ g, ..., fbn1 , bn2 , . . . , bnmðnÞ g g means that upon commencement of activity a, either all the activities, bi1 through bimðiÞ , simultaneously completes, or only one transition bi1 out of the activities b11 through bn1 ,ið1 ri r nÞ completes, or both. In general, if m(i) ¼ 1 for all i, then no parallel processing is completed before the commencement of a. In the SWM graphical notation, the former, that an activity has a conjunctive (or parallel) incoming transition, is represented by a solid dot – AND-join, and the latter, that an activity has a disjunctive (or decision) incoming transition, is represented by a hollow dot – OR-join. Summarily, the following is to formally specify the basic transition types depicted in Fig. 2:  Sequential transition: incoming-di ðaB Þ ¼ ffaA gg; outgoing-do ðaB Þ ¼ ffaC gg;  OR transition:OR-split-do ðaA Þ ¼ ffaB g,faC gg; OR-join-di ðaD Þ ¼ ffaB g,faC gg;  AND transition:AND-split-do ðaA Þ ¼ ffaB , aC gg; AND-join-di ðaD Þ ¼ ffaB , aC gg. 3. Model-driven collaborative workflow architectures As the emerging cloud computing environments have been actively adopted as an infrastructure for collaborative workflow systems, the necessity of the model-driven collaborative workflow architectural style has been increased with expecting the higher-level of architectural efficiency for collaborative workflow systems, as we can see those research results, (Muth, 1998; Tan and Fan, 2007; Vanhatalo et al., 2007; Khalaf and Leymann, 2006; Montagut and Molva, 2005; Kim, 2007; Reijers et al., 2009; Kim and Oh, 2010), in the literature. Nonetheless, the architectural frameworks are becoming a much more complicated work due to rapidly scaling up the complexities of workflow models in structure, size and workload. Accordingly, the higher degree of complexities in workflow procedures requires a higher-level of architectural renovations to realize collaborative workflow systems. As a consequence of this atmosphere, we need to be concerned about a variety of advanced workflow architectures

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

reflecting the collaborative aspects embedded in workflow models. 3.1. Model-driven collaborative complexity In characterizing the collaborative aspects in workflow models, it is necessary to analyze the influential factors that may effect the complexity of collaborations among architectural components, which is called the model-driven collaborative complexity. Accordingly, the collaborative workflow architectures can be characterized by the degree of collaborative complexity, and the influential factors of which might be the following three perspectives (or dimensions): workflow engagement, workflow structure and workflow instantiation. We describe the meanings of them as the followings:

 Workflow engagement: This dimension of the collaborative





complexity has to do with the sizes of workflow’s physical components that are served and engaged for a collaborative workflow system. The physical components are directly related with the components of workflow models, such as actors, roles, activities, workflow procedures, business processes, and organizations. So, the degree of workflow commitment can be decided by the sizes of these components, and it also becomes an essential criterion that is able to characterize the system’s scalability and performance—How well the workflow and business process system handles, commits, and serves for a huge number of requests coming out of a large number of actors, procedures and organizational compartments, which are involved in one or even more organizations. Workflow structure: This dimension of the collaborative complexity has something to do with interactional complexities between activities within a workflow procedure and between collaborative activities that are involved in interactions between workflow procedures in collaboration. In a large scale workflow procedure, several hundreds of activities might be co-associated with each other in diverse types of complex relationships, such as subworkflow, conjunctive, disjunctive, massively parallel, and cooperative relationships. Also, the recent e-Commerce, e-Logistics and e-Government marketplaces require more complicated relationships for supporting the inter-organizational workflow services like collaborative workflows, choreographical workflows, orchestrated workflows, and chained workflows. So, these structural complexity ought to be a critical criterion for deciding the degree of collaborative complexity. Workflow instantiation: This dimension of the collaborative complexity has directly related with measurement of the system’s performance. In a large scale workflow application domain, the number of workcases instantiated from a workflow procedure may be from several hundred-thousands of workcases to several millions of workcases. Also, the large number of workflow procedures can be managed and maintained in a workflow management system. Specially, this dimension is inflicting heavy effect on the fundamental infrastructures of the workflow management systems. That is, the systems can be extensively deployed on collaborative computing environments like cloud computing environments, in order to handle those large scale workcases without any further performance degradation. So, this dimension should be the most influential criterion in the scalability degree of collaborative complexity.

In devising model-driven collaborative workflow architectures, it is surely assumed to consider supporting the highest levels of services in all these of the three dimensions. For instance,

101

if we are able to accomplish the highest levels of services in both workflow engagement dimension and workflow structure dimension simultaneously, it is possible for the prospective collaborative workflow architecture to be completely renovated from the fundamental and philosophical reformations, whereas the highest level of workflow instantiation can be renovated only through the software architectural reformations. We would expect that satisfying the higher levels of collaborative complexity ought to be the theoretical basis for the architectural renovations like those collaborative workflow architectures to be presented in the next section. 3.2. Generic collaborative workflow architectures By considering the model-driven collaborative complexity, it is possible to contrive an architectural framework to systematically characterize each of the generic collaborative workflow architectures. For forbidding to stray from the paper’s main topic, this section just summarizes concisely about the fundamental idea of the architectural framework and the simple descriptions of the generic collaborative workflow architectures possibly spawned from the framework. Architectural framework: In general, the workflow architectural framework (Kim, 2007) consists of three phases of contemplation: generic phase, conceptual phase and implementation phase. However, it is unnecessary to contemplate the generic phase and platform phase in conceiving a collaborative workflow architectural framework, because the framework is aiming at the cloud computing paradigm, the architectural properties of which is already fixed as dispersed (the generic property) execution and cloud computing platform (the implementation property). Therefore, the framework might be able to characterize a series of collaborative workflow architectures only through the conceptual phase’s consideration. That is, the conceptual phase’s contemplation of the framework might be enough to elucidate the diversity of collaborative workflow architectures, because it is able to use the conceptual entity types (or concepts), such as activities, roles, actors and workcases, to build conceptual architectures. As a consequence of the conceptual phase’s thoughts, the architectural framework has clearly defined the decisive factors – concept embodiment, relationships among concepts, concept communication and conceptual responsibility distribution – to characterize possible model-driven collaborative workflow architectures.

 Concept embodiment: The notion of workflow concept embodi-



ment is related to the recent notions of software architectures that argue that careful choices concerning implementation of active entities as processes, threads, or active agents has tremendous influence upon performance of a system. The recent literature has proclaimed that these software choices are equally as important for performance as hardware choices. All of the possible collaborative workflow architectures and systems must keep the workflow models’ data representing those concepts such as activities and actors; however, it is important to implement these concepts as active processes rather than as passive data. From embodying those concepts, like activities, roles, actors and workcases, as active processes, it is surely possible to explore plenty of collaborative workflow architectures. Relationships among concepts: There are numerous relationships between those concepts; the precedence relationship exists among activities; the performer relation exists between roles and activities; the part-of relationship exists between activities and procedures; and so on. Some of these relationships can be specified at system creation time; others may be

102



K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

fixed at the time of workcase creation; still others need to be changed in various dynamic time-frames. In a collaborative workflow architecture, these relationships are implemented by the concept of binding. For instance, if an actor is bound to an activity on runtime, then it is called dynamic late binding; it depends upon who is available, who is best qualified, who dealt with this application in the past, and other factors as well. And we may also consider special types of binding like periodic binding, opportunistic binding, up to last minute dynamic binding and others. Responsibility distribution: There exist numerous options and decisions about placement and movement of data, scripts, and control information; many of these options remain unexplored in the contemporary workflow systems, yet. In configuring a collaborative workflow architecture, we have to decide an architectural component that is responsible for answering to the following questions: ‘‘What activity should be executed next?’’, ‘‘When should this application data be moved to an another site?’’ and ‘‘Where is the most efficient site to execute this script?’’ Note that in almost all of the conventional workflow systems, the common answer to these questions might be ‘‘at the workflow server.’’ However, in the collaborative workflow architectures and systems running on cloud computing environments, this answer should be inappropriate. Therefore, the collaborative workflow architectures may be differentiated according to that how to distribute the responsibility of control functionality.



Generic architectures: Based upon the collaborative workflow architectural framework, it is reasonable to contrive four styles of generic collaborative workflow architectures: workcase-driven, activity-driven, role-driven and actor-driven generic collaborative workflow architectures. By making a strong and reasonable combinations of the generic architectures, we are also able to build much more effective as well as efficient collaborative workflow architectures. The followings are the simple descriptions of these generic architectures:

 Workcase-driven collaborative workflow architectures: The



workcase-driven implies that an architecture can be built and operated by a group of workcase-based architectural components and their collaboration. In other words, a workcase, which is an instance of a workflow model, is not simply represented as data but embodied as an executable computing process (e.g. object) that actively guides the workcase from activity to activity helping to find and select actors, roles and relevant-data for each activity. Therefore, each of the workcase-based architectural components in this generic collaborative workflow architecture becomes a workcase computing process or a workcase object, when the architecture is implemented to a system. There are two types of workcase-driven architectures: class-active and instance-active. In the classactive workcase-driven architecture, each workflow model is embodied with a single workcase computing process that supervises all of the workcases instantiated from the corresponding workflow model. While on the other hand, the instance-active workcase-driven architecture embodies each of the workcase instances to a workcase computing process. As a natural consequence, the model-driven workflow distribution mechanism and the collaborative supports on a cloud computing environment are based upon these embodied workcase computing processes. Activity-driven collaborative workflow architectures: The activity-driven implies, as you easily imagine from the previous architectural description, that all of the activities associated with a workflow model become the architectural components



of the corresponding activity-driven collaborative workflow architecture. With the same way of concept embodiment, each of the activity-based architectural components is embodied to an activity computing process (e.g. activity object). Likewise, it is possible to be built two types – class-active and instanceactive – of activity-driven collaborative workflow architectures from this style of generic architecture. In the class-active activity-driven collaborative architecture, each of the associated activities of a workflow model is embodied to an activity computing process that takes charge of enacting all instances of the corresponding activity, while all instances of an associated activity of the workflow model are embodied to activity computing processes in the instance-active activitydriven collaborative architecture. As a natural consequence, the model-driven workflow distribution mechanism and the collaborative supports on a cloud computing environment are based upon these embodied activity computing processes. Role-driven collaborative workflow architectures: The role-driven implies, as you expected, that all of the roles associated with a workflow model become the architectural components of the corresponding role-driven collaborative workflow architecture. With the same way of concept embodiment, each of the role-based architectural components is embodied to a role computing process (e.g. role object). Likewise, it is possible to be built two types – class-active and instance-active – of roledriven collaborative workflow architectures from this style of generic architecture. In the class-active role-driven collaborative architecture, each of the associated roles of a workflowdriven organization is embodied to a role computing process that takes charge of enacting all instances of the corresponding workflow models, while all roles associated with an instance of a workflow model are embodied to role computing processes in the instance-active role-driven collaborative workflow architecture. As a natural consequence, the model-driven workflow distribution mechanism and the collaborative supports on a cloud computing environment are based upon these embodied role computing processes. Additionally, this generic architecture might be fitted very well to handle the security issues – role-based access control – in the domain of collaborative workflow architectures and systems. Actor-driven collaborative workflow architectures: Of course as you expected, the generic principle of actor-driven collaborative workflow architectures is similar to the role-driven’s except that the architectural components are conceptually associated with actors driven from the workflow models, and physically embodied to actor computing processes. Likewise, it is possible to be built two types – class-active and instanceactive – of actor-driven collaborative workflow architectures from this style of generic architecture. In the class-active actor-driven collaborative architecture, each of the associated actors of a workflow-driven organization is embodied to an actor computing process that takes charge of enacting all instances of the corresponding workflow models, while on the other all actors associated with an instance of a workflow model are embodied to actor computing processes in the instance-active actor-driven collaborative workflow architecture. As a natural consequence, the model-driven workflow distribution mechanism and the collaborative supports on a cloud computing environment are based upon these embodied actor computing processes.

Summarily speaking, the ICN-based structured workflow modeling methodology and the model-driven collaborative workflow architectures become the technological backgrounds for the model-driven workflow fragmentation framework proposed in this paper. That is, the modeling methodology is the analytical

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

basis of the model-driven workflow fragmentation framework, while on the other hand, the collaborative workflow architectures is the operational basis of the framework. In the next section we describe the detailed approaches of the model-driven workflow fragmentation framework.

4. Model-driven workflow fragmentation framework Based upon the ICN-based structured workflow model and four generic types of collaborative workflow architectures described in the previous section, this section newly defines the basic principles of the model-driven workflow fragmentation framework and exemplifies its approaches along with detailed algorithms.



4.1. Workflow fragmentation criteria Conceptually speaking, the primary goal of the workflow fragmentation framework is to provide a systematic way of breaking a workflow model into several fragments and allocating the fragments over the architectural computing processes of the underlying collaborative workflow architecture and system running on enterprise cloud computing environment (Kim, 2007). In other words, in order to enact a workflow model in a collaborative workflow system, a group of the architectural computing processes takes charge of collaboratively enacting the fragmented workflow models broken by an approach of the framework. At this moment, the most important thing is to figure out how to fragment the workflow model by which criteria. Accordingly, the core of the framework is on the fragmentation criteria that must be mirroring the underlying collaborative workflow architectures explored in the previous section. Fig. 4 proclaims a possible set of model-driven workflow fragmentation criteria that systematically break a workflow model vertically, horizontally or in hybrid with keeping the properties of the model-driven generic collaborative workflow architectures. In a sense of model-driven terminologies, the vertical fragmentation implies semantic-driven distribution purporting the collaborative enactment of the fragments, while the horizontal fragmentation works for syntactic-driven distribution mainly focusing on the syntactic decomposition of the corresponding workflow model. Conclusively, three analytical aspects of the model-driven workflow fragmentation criteria illustrated in Fig. 4 can be summarized as followings:

 Model semantic aspect: The semantic factors of an ICN-based structured workflow model are based upon the workflow concepts, such as activities, roles, actors, and workcases, previously defined. Therefore, from the model semantic aspect,

Fig. 4. The model-driven workflow fragmentation framework: vertical vs. horizontal.



103

we can generate the model-driven workflow fragmentation criteria based upon four relevant concepts of workcase, activity, role and actor. Eventually, these workflow concepts become the fragmentation criteria, because they are able to be not only naturally mirroring the generic model-driven collaborative workflow architectures, but rationally allocating the fragmented workflow models done by the criteria to the nodes of the architectures and systems. This aspect of the fragmentation criteria goes by the alias of the vertical workflow fragmentation criteria. Model syntactic aspect: The syntactical factors of an ICN-based structured workflow model consist of those constructs that are used to defining a workflow model, like control-flow constructs (sequential, disjunctive-OR and conjunctive-AND), data-flow constructs (defining relevant-data and using relevant-data), compound constructs (packages, subprocesses, groups and loop-blocks) and organizational constructs (swimlanes with multiple organizations and inter-organizations). Therefore, we can choose some constructs out of the model syntactical aspect as the model-driven workflow fragmentation criteria, and fragment a workflow model according to the chosen constructs. However, it ought to be hard to say that this aspect of the fragmentation criteria is perfectly matching with all of the generic model-driven collaborative workflow architectures. That is, only the activity-driven collaborative workflow architecture should be naturally fitted well for the criteria of this model syntactic aspect. This aspect of the fragmentation criteria goes by the alias of the horizontal workflow fragmentation criteria. Model embodiment aspect: This aspect is related with the embodiment timing of the workflow fragments produced by a fragmentation behavior. In other words, the term, static, implies ‘‘fragmenting before the workflow model’s execution begins’’, while the term, dynamic, means ‘‘fragmenting during the execution of the workflow model’’. As described in the previous section, the generic architectures are classified into two types: class-active and instance-active, and which implies that the static fragmentation is naturally fitted well into the class-active collaborative workflow architectures, and that the dynamic fragmentation is well applicable to the instanceactive collaborative workflow architectures.

Summarily, the essential idea of the model-driven workflow fragmentation framework proposed in this paper is on the fragmentation criteria that are driven from the workflow model itself. Particularly, the framework might be valuable in terms of its perfect-applicability to the generic model-driven collaborative workflow architectures. In the next subsections, the details of the framework are precisely described and exemplified with its related algorithms. In the vertical fragmentation approaches subsection, the role-driven fragmentation criterion and actordriven fragmentation criterion are applied to the ICN-based structured workflow model shown in Fig. 3, and we can see how the model is vertically fragmented into a role-based semantical groups of activity fragments as well as an actor-based semantical groups of activity fragments, and how each group finally can be allocated into each node of the corresponding collaborative workflow computing environment. Of course, the vertical fragmentation can be done by random grouping method, and it, however, ought not to be a reasonable approach, because it’s hard to estimate its operational performance, as we know. In the horizontal fragmentation subsection, we introduce a special syntactical fragmentation approach, which is called a controlpath driven workflow fragmentation algorithm, and describe how much the approach is reasonable and applicable to the activitydriven collaborative workflow architectures and systems.

104

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

Fig. 5. The role-based vertical fragmentation result.

4.2. Vertical fragmentation approaches The vertical workflow fragmentation approaches based on the model semantic aspect’s criteria consist of four different types of model-driven workflow fragmentation approaches to make activity-groups based upon the semantic components—workcase, activity, role and actor. This subsection gives the details of two model-driven workflow fragmentation approaches – role-based workflow fragmentation and actor-based workflow fragmentation – with exemplifying their algorithms. The remainder approaches, workcase-based and activity-based workflow fragmentation approaches, are not presented in this paper, because of the page limitation as well as their algorithmic simplicity. Role-based workflow fragmentation: As an example, we present one of the model semantic aspect’s approaches, which is called the role-based workflow fragmentation method that is made up of the role-based workflow fragment model and its automatic generation algorithm. The fundamental idea of the method is that the activities to be performed by a same role are distributed to its corresponding role computing process running on a role-based cloud computing node. We apply the method to the structured workflow process model presented in the previous figure, Fig. 3, and its vertical fragmentation result is illustrated in Fig. 5. The left-hand side of the figure is the graphical representation of the role-based workflow fragment model, and the right-hand side is the final activity fragments and the distribution status to the associated computing processes or nodes. The formal definition of the role-based workflow fragment model is described in Definition 1, and its graphical primitives are oval (node), directed arc with label (activity), solid dot (: parallel) and hollow dot (3: decision) as shown in Fig. 5. The model represents two types of information – node flows and fragmented activities – through which we are able to get precedence (predecessor/successor) relationships among role nodes as well as distributed activities of each role node. For an instance, the activities, aA , aD , aE , on the incoming directed arcs of the role node, ZRX , are the assigned activities to the corresponding role node. Definition 1. Role-based workflow fragment model. A role-based workflow fragment model is formally defined as R ¼ ðx, W,S,EÞ, over a set R of roles and a set A of activities, where,

 S is a finite set of the initial nodes;  E is a finite set of the final nodes;  x ¼ xi [ xo /* Node flow: successors and predecessors */ where, xo : R!YðRÞ is a multi-valued function mapping a node to its sets of (immediate) successors, and xi : R!YðRÞ is a multi-



valued function mapping a node to its sets of (immediate) predecessors; W ¼ Wi [ Wo /* Fragments and Neighbor Fragments */ where, Wi : A!YðRÞ is a multi-valued function mapping a set of fragmented activities into the role node, Z; and Wo : A!YðRÞ is a multi-valued function mapping a set of neighbor fragments’ activities to the role node, Z;

Table 1 The result of the role-based workflow fragmentation algorithm. The Role-based Workflow Fragment Model A ¼ fastart , aA , aB , aC , aD , aE , aF , aend g Activities R ¼ fZstart , ZRX , ZRY , ZRZ , Zend g Roles Initial Nodes S¼| Final Nodes E¼| R ¼ ðx, W,S,EÞ over A, R

x ¼ xi [ xo xi :Predecessors xo :Successors xo ðZstart Þ ¼ ffZRX gg xi ðZstart Þ ¼ | xi ðZRX Þ ¼ ffZstart g,fZRY g,fZRZ gg xo ðZRX Þ ¼ ffZRY g,fZend gg xo ðZRY Þ ¼ fffZRX g,fZRZ gg,fZend gg xi ðZRY Þ ¼ ffZRX g,fZRZ gg xo ðZRZ Þ ¼ fffZRX , ZRY gg,fZend gg xi ðZRZ Þ ¼ ffZRY gg xi ðZend Þ ¼ ffZRX g,fZRY g,fZRZ gg xo ðZend Þ ¼ | W ¼ Wi [ Wo Wi : Fragments Wi ðZstart Þ ¼ ffastart gg Wi ðZRX Þ ¼ ffaA g,faD g,faE gg Wi ðZRY Þ ¼ ffaB g,faF gg Wi ðZRZ Þ ¼ ffaC gg Wi ðZend Þ ¼ ffaend gg

Wo : NeighborFragments Wo ðZstart Þ ¼ ffaA gg Wo ðZRX Þ ¼ ffaB g,faend gg Wo ðZRY Þ ¼ fffaC g,faD gg,faend gg Wo ðZRZ Þ ¼ fffaE , aF gg,faend gg Wo ðZend Þ ¼ |

In terms of fragmenting of a workflow model, it is definitely required to automatically construct a role-based workflow fragment model. In other words, it is very important to provide an automatic methodology for implementing the model semantic aspect’s role-driven approach. Therefore, we conceive an algorithm for automatically constructing the role-based workflow fragment model from an ICN-based structured workflow model. The following is the algorithm that is called the role-based workflow fragmentation algorithm. The time complexity of the vertical fragmentation algorithm is O(n), where n is the number of activities in the structured workflow model, because the function has a single for-loop with repeating as many as the number of activities. Therefore, the overall time complexity is O(n). Procedure Role-based Workflow Fragmentation Algorithm. Input A Structured Information Control Net, G ¼ ðd, r, l, e, p, k,I,OÞ; Output A Role-based Workflow Fragmentation Model, R ¼ ðx, W,S,EÞ; BEGIN FOR ð8a A AÞ DO /* x ¼ xi [ xo */ Add er ðaÞ To xi ðer ðall members of do ðaÞÞÞ; Add er ðall members of do ðaÞÞ To xo ðer ðaÞÞ; /* W ¼ Wi [ Wo */ Add a To Wi ðer ðaÞÞ; Add do ðaÞ To Wo ðer ðaÞÞ; END-FOR END-PROCEDURE

As result, we give the formal representation of the role-based workflow fragment model of the structured workflow model in

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

Table 1, which is automatically generated by applying the algorithm. As you can see, the table shows the node flow information and each node’s fragmented activities based upon three nodes and six elementary activities. Actor-based workflow fragmentation: In this subsection, we introduce the basic concept and definition of actor-based workflow fragmentation method as the second one out of the vertical workflow fragmentation approaches. This approach aims particularly for the actor-driven collaborative workflow architectures and systems, and consists of the actor-based workflow fragment model and the fragmentation algorithm for automatically producing a group of actor-based workflow fragment models from an ICN-based structured workflow model. Basically, the actor-based workflow fragment model represents the behaviors of acquisitioning activities among actors associated in a workflow model. The formal definition of the actor-based workflow fragment model is given in Definition 2, and its graphical representation is illustrated in Fig. 6 as an example, which is built from the simple ICN-based structured workflow model, Fig. 3. The behaviors of the fragment model are revealed through incoming and outgoing directed arcs labeled with activities associated with each of actors. The directed arcs imply two kinds of behaviors – actor flows

105

and acquisition activities of actors – through which we are able to get precedence (candidate-predecessor/candidate–successor) relationships among actors as well as acquisition activities of each actor in a workflow model. In terms of defining actor’s predecessors and successors, we would use the prepositional word, ‘‘candidate’’, because, unlike in the role-based workflow fragment model, in actor-based workflow fragment model, a role-actor mapping is an one-to-many relationship, and the actor selection mechanism will choose one actor out of the assigned actors mapped to the corresponding role during the workflow model’s runtime. The formal definition of the actor-based workflow fragment model is described in Definition 2, and its graphical primitives are roundedBox (actor node), directed arc with label (activity), solid dot (: parallel) and hollow dot (3: decision) as shown in Fig. 6. Particularly, the smallBox (&) graphical primitive represents a group of actors who are involved in a same role. Conclusively, the actor-based workflow fragment model represents two types of information – actor-node flows and fragmented activities – through which we are able to get precedence (predecessor/ successor) relationships among actor nodes as well as distributed activities of each actor node. For an instance, the activities,

Fig. 6. The actor-based vertical fragmentation result.

Table 2 The result of the actor-based workflow fragmentation algorithm. R ¼ ðs, c,S,EÞ over A, R A ¼ fastart , aA , aB , aC , aD , aE , aF , aend g P¼{ostart, ojoe, olisa, ojack, oshawn, omattew, oend} S¼| E¼|

The Actor-based workflow fragment model Activities Actors Initial Nodes Final Nodes

s ¼ si [ so

si :Predecessors si ðostart Þ ¼ | si ðojoe Þ ¼ ffostart g,foshawn g,fomatthew gg si ðolisa Þ ¼ ffostart g,foshawn g,fomatthew gg si ðojack Þ ¼ ffostart g,foshawn g,fomatthew gg si ðoshawn Þ ¼ ffomatthew gg si ðomatthew Þ ¼ ffoshawn gg si ðoend Þ ¼ ffojoe g,folisa g,fojack g,foshawn gg

so :Successors so ðostart Þ ¼ f½ojoe ,olisa ,ojack g si ðojoe Þ ¼ ffoshawn g,foend gg si ðolisa Þ ¼ ffoshawn g,foend gg si ðojack Þ ¼ ffoshawn g,foend gg si ðoshawn Þ ¼ fff½ojoe ,olisa ,ojack g,fomatthew gg,foend gg si ðomatthew Þ ¼ ff½ojoe ,olisa ,ojack ,oshawn gg so ðoend Þ ¼ |

c ¼ ci [ co

ci :Fragments ci ðostart Þ ¼ ffastart gg ci ðojoe Þ ¼ ffaA g,faD g,faE gg ci ðolisa Þ ¼ ffaA g,faD g,faE gg ci ðojack Þ ¼ ffaA g,faD g,faE gg ci ðoshawn Þ ¼ ffaB g,faF gg ci ðomatthew Þ ¼ ffaC gg ci ðoend Þ ¼ ffaend gg

co :NeighborFragments co ðostart Þ ¼ ffaA gg co ðojoe Þ ¼ ffaB g,faend gg co ðolisa Þ ¼ ffaB g,faend gg co ðojack Þ ¼ ffaB g,faend gg co ðoshawn Þ ¼ fffaC g,faD gg,faend gg co ðomatthew Þ ¼ ffaE , aF g,faend gg co ðoend Þ ¼ |

106

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

aA , aD , aE , on the incoming directed arcs of the actor node, ojoe, are the fragmented activities and allocated to the corresponding actor node. Definition 2. Actor-based Workflow Fragment Model. An actorbased workflow fragment model is formally defined as L ¼ ðs, c,S,EÞ, over a set P of actors, and a set A of activities, where

 S is a finite set of coordinators or coordinator-groups con 



nected from some external actor-based workflow fragment models; E is a finite set of coordinators or coordinator-groups connected to some external actor-based workflow fragment models; s ¼ si [ so /* Actor Flow: successors and predecessors */ where, so : P!Yðo A PÞ is a multi-valued function mapping an actor to its sets of (immediate) candidate-successors, and si : P!Yðo A PÞ is a multi-valued function mapping an actor to its sets of (immediate) candidate-predecessors; c ¼ ci [ co /* Fragments and Neighbor Fragments */ where, ci : A!YðPÞ is a multi-valued function mapping a set of fragmented activities into the actor node, o; and Wo : A!YðPÞ is a multi-valued function mapping a set of neighbor fragments’ activities to the actor node, o;

Likewise, in terms of fragmenting a workflow model, it is definitely required to automatically construct an actor-based workflow fragment model. In other words, it is very important to provide an automatic methodology for implementing the model semantic aspect’s actor-driven approach. Therefore, the paper derives an algorithm for automatically producing the actor-based workflow fragment model from an ICN-based structured workflow model. The following is the algorithm that is called the actor-based workflow fragmentation algorithm. The time complexity of the vertical fragmentation algorithm is O(n), where n is the number of activities in the structured workflow model, because the function has a single for-loop with repeating as many as the number of activities. Therefore, the overall time complexity is O(n). As a result, we give the formal representation of the actor-based workflow fragment model of the structured workflow model in Table 2, which is automatically generated by applying the algorithm. As you can see, the table shows the actor-node flow information and each node’s fragmented activities based upon five nodes and six elementary activities. The construction algorithm for the actor-based workflow fragment model: An actor-based workflow fragment model is constructed from an ICN-based workflow model through the following algorithm. Input An ICN, G ¼ ðd, r, l, e, p, k,I,OÞ; Output An Actor-based Workflow Fragment Model, L ¼ ðs, c,S,EÞ; BEGIN FOR ð8a A AÞ Do BEGIN /* s ¼ si [ so */

Add all members of pc ðep ðaÞÞ To si ðeach member of pc ðep ðdo ðaÞÞÞÞ; Add all members of pc ðep ðdo ðaÞÞÞ To so ðeach member of pc ðep ðaÞÞÞ; /* c ¼ ci [ co */ Add a To ci ðeach member of pp ðer ðaÞÞÞ; Add do ðaÞ To co ðeach member of pp ðer ðaÞÞÞ; END- FOR END-PROCEDURE

4.3. Horizontal fragmentation On the other hand, the conceptual meaning of horizontal fragmentation of a workflow model implies syntactical grouping of activities. In other words, as introduced in the previous fragmentation criteria descriptions, the syntactical factors of an ICN-based structured workflow model consist of control-flow constructs (sequential, disjunctive-OR and conjunctive-AND), data-flow constructs (defining relevant-data and using relevant-data), compound constructs (packages, subprocesses, groups and loop-blocks) and organizational constructs (swimlanes with multiple organizations and inter-organizations). In this subsection, as a typical horizontal workflow fragmentation approach, we define a control-path driven workflow fragment model and exemplify its algorithm using the concept of reachable control-path constructs. In the typical horizontal approach, the syntactic components of the structured workflow model, such as OR-nodes and AND-nodes, becomes the criteria for grouping the activities. Conclusively, the reachable controlpathes (Kim and Ellis, 2006) of a structured workflow model become the horizontal fragments that are distributed into the computing nodes, as shown in Fig. 7. The left-hand side of the figure represents the reachable control-pathes of the ICN-based structured workflow model introduced in the previous section, and the right-hand side shows the horizontal fragments, each of which can be distributed into one of the computing nodes, CP-X and CP-Y. As you see, in this horizontal fragmentation approach some activities like aA , aB may be duplicately grouped into different computing nodes. Definition 3. Control-path driven workflow fragment model of an ICN-based structured workflow model. Let W be a CpFN, a control-path workflow fragment net, that is formally defined as CpFN ¼ ðR, k,I,OÞ over a set of activities, Acp, and a set of transition-conditions, Tcp, where

 R ¼ Ri [ Ro where Ro : Acp !Yða A Acp Þ is a multi-valued map-



ping of an activity to its set of (immediate) successors, and Ri : Acp !Yða A Acp Þ is a single-valued mapping of a multivalued mapping function of an activity to its set of (immediate) predecessors; b ¼ bi [ bo where bi ðaÞ is a set of control transition conditions, t A Tcp , on each arc, ðbi ðaÞ, aÞ; and bo ðaÞ is a set of control transition-conditions, t A Tcp , on each arc, ða, bo ðaÞÞ, where a A Acp ;

Fig. 7. The horizontal fragmentation result.

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

 I is a finite set of initial input repositories of the corresponding 

structured workflow model; O is a finite set of final output repositories of the corresponding structured workflow model.

PROCEDURE Control-path Driven Workflow Fragmentation Algorithm Input A Structured Workflow Process Model,

107

fragments an ICN-based structured workflow model, as an input, into several control-path driven workflow fragment models. The time complexity of the horizontal fragmentation algorithm is O(n), where n is the number of activities in the structured workflow model, because the function, H-FRAGMENTATION(), is recursively traversing each activity in only once. Therefore, the overall time complexity is O(n). 4.4. Hybrid of the approaches

G ¼ ðd, g, l, e, p, k,I,OÞ; Output A Set of Controlpath-based Fragment Models (CpFNs), 8W ¼ ðR, k,I,OÞ; Initialize CpN’f|g; /* The empty net of CpFN. */ PROCEDURE H-FRAGMENTATION(In s’faI g, CpFN) /* Recursive Function */ BEGIN v’s; CpFN:Acp ’CpFN:Acp [ fvg; WHILE ððu’do ðsÞ; Þ a faF gÞ SWITCH (What type of the activity, u, is?) DO Case ‘serial-type activity’: w’u; CpFN:Acp ’CpFN:Acp [ fwg; CpFN:Ro ðvÞ’w; CpFN:Ri ðwÞ’v; CpFN:bo ðvÞ’ko ðsÞ; CpFN:bi ðvÞ’ki ðsÞ; break; Case ‘conjunctive- type (AND-split) activity’: w’u; CpFN:Acp ’CpFN:Acp [ fwg; CpFN:Ro ðvÞ’w; CpFN:Ri ðwÞ’v; CpFN:bo ðvÞ’ko ðsÞ; CpFN:bi ðvÞ’ki ðsÞ; FOR ðeachof 8a A do ðuÞÞ DO x’a; CpFN:Acp ’CpFN:Acp [ fxg; CpFN:Ro ðwÞ’x; CpFN:Ri ðxÞ’w; CpFN:bo ðwÞ’ko ðuÞ; CpFN:bi ðwÞ’ki ðuÞ; END-FOR FOR ðeach of 8a A do ðuÞÞ DO Call PROCEDURE H-FRAG(In s’a, CpFN); END- FOR exit(); Case ‘disjunctive-type (OR-split) activity’: w’u; CpFN:Acp ’CpFN:Acp [ fwg; CpFN:Ro ðvÞ’w; CpFN:Ri ðwÞ’v; CpFN:bo ðvÞ’ko ðsÞ; CpFN:bi ðvÞ’ki ðsÞ; FOR ðeach of 8a A do ðuÞÞ DO Call PROCEDURE H-FRAG(In s’a, CpFN); END-FOR exit(); Default: /* OR-join activity or AND-join activity */ w’u; CpFN:Acp ’CpFN:Acp [ fwg; CpFN:Ro ðvÞ’w; CpFN:Ri ðwÞ’v; CpFN:bo ðvÞ’ko ðsÞ; CpFN:bi ðvÞ’ki ðsÞ; break; END- SWITCH s’u; v’w; END-WHILE w’u; CpFN:Acp ’CpFN:Acp [ fwg; /* u is equal to aF . */ CpFN:Ro ðvÞ’w; CpFN:Ri ðwÞ’v; CpFN:bo ðvÞ’ko ðsÞ; CpFN:bi ðvÞ’ki ðsÞ; PRINTOUT CpFNs END-PROCEDURE

In order to formally define the horizontal fragmentation approach, it is necessary to define the control-path driven workflow fragment model and its generation algorithm. The definition of the control-path-based fragment model is given in Definition 3, and the horizontal fragmentation algorithm described in the followings

Additionally, it might be possible to make a hybrid fragmentation approach by combining both the vertical approach and the horizontal approach, as we can expect. That is, as an example, a control-path driven workflow fragment model generated through the corresponding algorithm also can be vertically fragmented by applying one of the vertical workflow fragmentation methods. For instance, assume that we apply the role-based workflow fragmentation approach to each of the control-path driven workflow fragment models. Then, as the result of the hybrid method, a set of the role-based re-fragment models can be generated from the applied control-path fragment model, and the re-fragmented models are disseminated onto the nodes of a collaborative workflow computing environment. This hybrid approach might be fitted very well into the very large scale workflow models, which are largely built and characterized in the recent modernized and computerized organizations. Because of the page limitation, we would not describe the details of the hybrid approach.

5. An operable architecture and its fragmentation approach So far, in the previous two sections, we simply introduced a possible set of generic collaborative workflow architectures and conceived a series of workflow fragmentation approaches. Consequently, we know that how to fragmentate a workflow model and disseminate its fragments into runtime components of the underlying collaborative workflow system. At this moment, it is necessary to describe also how these collaborative workflow architectures are related with the fragmentation approaches, each other. In this section, we try to configure an operable collaborative workflow architecture with one of those fragmentation approaches, as an example, in order to show how feasible the proposed approaches are in realizing collaborative workflow architectures and systems on cloud computing environments. Before we proceed the realizing work, we need to refine the architectural framework for reflecting the details of the fragmentation approaches. Fig. 8 illustrates a refined architectural framework giving a taxonomy for collaborative workflow architectures and their matched fragmentation approaches. The decisive factors for classifying collaborative workflow architectures become more sophisticated in the refined framework, like fragment embodiment, fragment distribution and fragment binding. In the fragment embodiment aspect, it can be decided how to implement each of the concepts – workcase, role, activity and actor – with its fragments in the corresponding collaborative workflow architectures. So, each of the concepts can be embodied as a sort of active object components in a collaborative workflow architecture and system. There ought to be three types of active object components—instances (instance-active object), managers (class-active object) dedicated to enacting its all of instances and hybrid (dual-active object). Finally, in terms of the fragment binding and coupling aspect, we have to decide not only whether these three types of active object components conducting the collaborative workflow enactment functionality can operate in a fashion of dynamic binding, or not (static binding), but also whether those active object components can be created,

108

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

Fig. 8. An architectural taxonomy and its associated fragmentation approaches.

Fig. 9. A snapshot of a possible role-driven collaborative workflow system.

manipulated, and destroyed in a fashion of dynamic coupling/ decoupling, or not (static coupling/decoupling). Summarily, each box of Fig. 8 represents a style of collaborative workflow architectures characterized by the refined decisive factors and their fragmentation approaches. Particularly, the workflow fragmentation approaches are directly related with the fragment distribution and responsibility aspect. That is, the workcase-driven collaborative workflow architectural style works with the control-path based fragmentation approach, while on the other hand the role-driven, actor-driven and activity-driven collaborative workflow architectural styles operate with those role-based, actor-based and activity-based fragmentation approaches, respectively. Remind that we would not describe the details of the activity-based fragmentation approach, as you know, because it ought to be done by the traditional fragmentation approaches. In order to explain the feasibility of the proposed fragmentation approaches, we try to design a possible collaborative workflow architecture by the refined architectural framework, which is belonging to the role-driven collaborative workflow architectural style that is the colored box of Fig. 8 and characterized by rolebased fragmentation and distribution, class-active object

embodiment and dynamic binding and coupling properties. With preserving the architectural properties, it is possible to implement a role-driven collaborative workflow system, and a runtime snapshot (Kim, 2009) of the conceived system is presented in Fig. 9, where the simple ICN-based structured workflow model introduced in Fig. 3 is fragmented by the role-based fragmentation approach, and its role-based fragments, ðaA , aD , aE Þ, ðaB , aF Þ and ðaC Þ, as shown in Fig. 5, are scattered into three role-driven class-active objects, such as RoleR-X, RoleR-Y and RoleR-Z Enactment Managers, resided on each of the cloud computing nodes. As illustrated in Fig. 9, all of assigned activities and their related data of the role-based fragments are transferred from the workflow manager to each of the role enactment managers through the cloud node coordinators. Eventually, all instances of the ICN-based structured workflow model are controlled and enacted through the collaborations among the role enactment managers.

6. Related works Traditionally, the goal of a workflow management system was to orchestrate the enactment of workflow procedures ultimately

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

being responsible for the control of either a single application domain’s activities or a single organization’s activities. However, recently it has been changing and scaling up in terms of the complexities in organizational structure, size and workload, according for the workflow and business process technology to be flourishing in the almost all types of industries as well as in the almost all types of new process-driven enterprise and scientific models (Martin et al., 2008; Kim, 2007; Kim and Ellis, 2009), such as process portals, POD (process-on-demand), process choreography and orchestration, process collaboration, scientific workflow models, and inter-organizational workflow and business process models, which need to coordinate a huge number of instances from a variety of workflow procedures and a huge amount of data from scientific processes. That is, what we see happening now in the workflow literature is that the workflows’ complexity is in the stage of a rapid scaling up and the workflows’ applicability is just at the point of transition from the end of the pilot test stage to the beginning of the cold reality stage that is gaining practical benefits. Therefore, in the near future, we are going to be faced with the world of massively parallel and very large scale enterprise and scientific workflows, and these considerations of massively parallel and large scale properties will certainly be the leading topic of the future generation workflow models and systems. As a consequence of this atmosphere, we need to be concerned about the massively parallel and very large scale enterprise and scientific workflow management systems as future generation workflow systems. Accordingly, Grid, Peer-to-Per (P2P) and cloud technology (Congiusta et al., 2005; Dheepak et al., 2005; Zhuge, 2002, 2004a, 2004b; Zhuge et al., 2005) ought to be the impeccable solution as an underlining infrastructure for maximally parallel and very large scale workflow management systems (Kim, 2007). As a future generation computing infrastructure, the Grid/P2P/Cloud middleware provides the fundamental communication services to share knowledge and resources among the computing nodes organizing the Grid/P2P/Cloud network. Therefore, in order to deploy maximally parallel and very large scale enterprise and scientific workflow knowledge and enactment services on Grid/P2P/Cloud computing infrastructures, we need a certain type of domain-specific workflow models and their fragmentation approaches to be efficiently deployed over collaborative executable components running on top of the middleware resided in the nodes of the underlining Grid/P2P/Cloud computing environments. Based on these considerations, this paper proposes a series of workflow fragmentation approaches that becomes theoretical principles for domain-specific node configuration frameworks, which eventually derive a set of generic collaborative workflow architectures and systems. In realizing the massively parallel and very large scale enterprise and scientific workflow deployment and enactment services over Grid/P2P/Cloud computing environments, one of the most interesting and important research topics ought to be the workflow models’ fragmentation issues, as already addressed in the workflow related literature. As a typical related work, we would introduce the Tan & Fan’s approach (Tan and Fan, 2007). They proposed a dynamic workflow fragmentation algorithm based on the well-known Petri net formalism unlike our approach using the ICN-based structured workflow modeling formalism, which tries to partition a centralized workflow model into fragments step by step while the workflow is executed, and the created fragments can be migrated to the proper workflow servers. The approach also solve the scalability enhancing issue as well as the flexibility increasing issue. However, it is hard to say for the approach to have enough fragmentation criteria, because it transfers fragments by just judging their preconditions. In the web services and BPEL literature, there were also several tries for the workflow or process decomposition issues

109

(van der Aalst et al., 2000) and the distributed enactment issues. Khalaf and Leymann (2006) addressed a role-based decomposition mechanism for BPEL-based business process model. Unlike our approach, their approach concerned about the process-based web service issue, and the primary goal was to disconnect the partitioning work from the design of the business process in order to just simplify the reassignment of activities to difference entities. Also, Martin et al. (2008) proposed an alternative approach to enacting BPEL-based business processes’ control flow in a distributed, decentralized manner. However, unlike our approach, the approach was concerned about web service orchestration over decentralized workflow engines. Conclusively speaking, unlike those conventional approaches proposed in the literature, our approach takes into account not only all of the workflow’s semantical aspects, such as roles, actors, and activity-dependencies or data-dependencies, but all possible syntactical aspects of workflow models, in order to partition a workflow model into a series of fragments. Also, it is surely believed that the paper should be a pioneering result in this research topic.

7. Conclusions This paper proposed a model-driven workflow fragmentation framework consisting of the vertical, horizontal and hybrid approaches that can be applied into the very large scale workflow models and their enactment systems, as well as particularly to the so-called collaborative workflow architectures and systems based on the emerging computing environment, Cloud computing environments and paradigm. The approaches are based on the ICN-based structured workflow model and are implemented by a set of model-driven workflow fragmentation techniques, such as role-based fragmentation method and actor-based fragmentation method of the vertical fragmentation approach, and control-path driven workflow fragmentation method of the horizontal fragmentation approach, and the hybrid approach. Finally, this paper exemplified that the approaches’ algorithms are able to properly handle the workflow fragmentation and distribution of a workflow model as examples. In a consequence, as the advanced distributed enterprise computing environments like enterprise grid or enterprise cloud computing environments are now hot-issued in the literature, those maximally parallel and very large scale collaborative workflow enactment architectures and systems are rapidly growing and coping with a wide diversity of domains in terms of their applications and working environments. So, the literature might be surely requiring various, advanced, and specialized workflow fragmentation techniques and architectures. Moreover, it is strongly believed that this work might be one of those impeccable attempts and pioneering contributions for improving and advancing the collaborative workflow fragmentation and enactment computing technologies. Finally, as one of the future works to be proceeded right after this paper, it is very important to verify the proposed fragmentation approaches through a certain type of performance evaluation methodologies. Indeed, the research group of the author has been preparing a performance evaluation methodology that is based upon the layered queuing models analytically analyzed by the method of layer (MOL).

Acknowledgments This research was supported by the National Research Foundation’s Basic Research Grant no. 2009-0075651, and this is the partial result of the collaborative works with the contents

110

K. Kim / Journal of Network and Computer Applications 35 (2012) 97–110

convergence software research center funded by the Gyeonggi Province, South Korea. References Congiusta A, et al. A data mining-based framework for grid workflow management. In: Proceedings of the international workshop on grid and peer-to-peer based workflows, Melbourne, Australia; 2005. Dheepak RA, et al., Scalable enterprise level workflow manager for the grid. In: Proceedings of the international workshop on grid and peer-to-peer based workflows, Melbourne, Australia; 2005. Ellis CA. Information control nets: a mathematical model of information flow. In: ACM proc. conf. on simulation modeling and measurement of computer systems; 1979. p. 225–40. Khalaf R, Leymann F. Role-based decomposition of business processes using BPEL. In: The proceedings of international conference on web services. Springer; 2006. Kim K-H. A layered workflow knowledge grid/P2P architecture and its models for future generation workflow systems. Future Generation Computer Systems 2007;23:304–16. Kim K-H. Mining workflow processes from XML-based distributed workflow event logs. In: IEEE proceedings of international workshop on distributed XML processing theory and practice; 2009. Kim K-H, Ellis CA. Workflow reduction for reachable-path rediscovery in workflow mining. Series of studies in computational intelligence: foundations and novel approaches in data mining, vol. 9, 2006. p. 289–310. Kim K-H, Ellis CA. An ICN-based workflow model and its advances, Handbook of research on BP modeling, IGI Global, ISR; 2009. p. 142–72. Kim K-H, Oh SM. A workflow fragmentation framework for enterprise grid workflow systems. In: IEEE proceedings of the sixth international symposium on frontiers of information systems and network applications, Perth, Australia; April 2010. p. 79–84. Liu X, Kumar A. An analysis and taxonomy of unstructured workflows. Lecture Notes in Computer Science 2005;3649:268–84.

Liu C, et al. Challenges and opportunities in collaborative business process management: overview of recent advances and introduction to the special issue. Journal of Information Systems Frontiers 2009;11:201–9. Martin D, et al. A novel approach to decentralized workflow enactment. In: The IEEE proceedings of international conference on enterprise distributed object computing, Munich, Germany, September; 2008. Montagut M, Frederic F, Molva M, Refik R. Enabling pervasive execution of workflows. In: IEEE proceedings of international conference on collaborative computing: networking applications and worksharing; 2005. p. 1–10. Muth P, et al. From centralized workflow specification to distributed workflow execution. Journal of Intelligent Information Systems 1998;10(2):5. Park M-J, Kim K-H. Control-path oriented workflow intelligence analyses. Journal of Information Science and Engineering 2008;24(2):343–59. Reijers HA, et al. Analysis of a collaborative workflow process with distributed actors. Journal of Information Systems Frontiers 2009;11:307–22. Tan W, Fan Y. Dynamic workflow model fragmentation for distributed execution. Computers in Industry 2007;58(5):381–91. Tomaz LFC, et al. Collaborative process modeling and reuse evaluation. In: IEEE proceedings of international conference on collaborative computing: networking applications and worksharing; 2009. p. 1–9. van der Aalst WMP, Barros AP, ter Hofstede AHM, Kiepuszewski B. Advanced workflow patterns. In: The proceedings of conference on cooperative information systems, Lecture Notes in Computer Sciences, vol. 19; 2000. Vanhatalo J, Voelzer H, Leymann F. Faster and more focused control-flow analysis for business process models through SESE decomposition. In: The proceedings of ICSOC2007, Lecture Notes in Computer Sciences, vol. 4749. Springer; 2007. p. 43–55. Zhuge H. A knowledge flow model for peer-to-peer team knowledge sharing and management. Expert Systems with Applications 2002;23:23–30. Zhuge H. China’s e-Science knowledge grid environment. IEEE Intelligent Systems 2004a;19(1):13–7. Zhuge H. Semantics, resource and grid. Future Generation Computer Systems 2004b;20(1):1–5. Zhuge H, et al. A scalable P2P platform for the knowledge grid. IEEE Transactions on Knowledge and Data Engineering 2005;17(12):1721–36.