• IE interfaces
• /
• v.17 no.2
• /
• pp.190-199
• /
• 2004

Recently, many enterprises are introducing a workflow management system for the successful implementation of BPR(Business Process Reengineering). Proposed in this study is the workflow management system which has a light-weight component structure and an XPDL(XML Process Definition Language) file interpretation facility. The XPDL is the standard process definition exchange format developed by WfMC(Workflow Management Coalition). The major causes of inefficiency at current implementations of workflow management systems are the centralized workflow engine structure and the use of proprietary workflow definition format among most solutions. The proposed light-weight component structure in this study is the intermediate structure that takes the strength of both centralized and distributed workflow engines. And a prototype workflow system which uses an XPDL process definition file as input is developed through the thorough analysis of functional requirements.

• Journal of Internet Computing and Services
• /
• v.17 no.5
• /
• pp.131-139
• /
• 2016

This paper presents a workflow validation method for data-intensive graphical workflow models using real-time workflow tracing mode on data-intensive workflow designer. In order to model and validate workflows, we try to divide as modes have editable mode and tracing mode on data-intensive workflow designer. We could design data-intensive workflow using drag and drop in editable-mode, otherwise we could not design but view and trace workflow model in tracing mode. We would like to focus on tracing-mode for workflow validation, and describe how to use workflow tracing on data-intensive workflow model designer. Especially, it is support data centered operation about control logics and exchange variables on workflow runtime for workflow tracing.

• Korean Management Science Review
• /
• v.16 no.1
• /
• pp.187-201
• /
• 1999

In this paper, we propose a multi-layered architecture of workflow management systems based on CORBA (Common Object Request Broker Architecture). The system aims to support product development processes in distributed environment. Many companies have started to adopt workflow management systems to manage and support their business processes. However, there are many problems in direct application of those systems to product development environments. These mainly resulted from the dynamic features of product development processes. It is strongly required to support dynamic processes as well as static and procedural ones in an integrated and consistent manner. To meet these requirements, a basic workflow management system has been developed as the core component of the integrated architecture. This performs the basic functions of workflow management system. Second, a dynamic workflow management system based on a bidding mechanism has been developed to manage processes that cannot be easily defined or are likely to be modified, Finally, an SGML workflow management system, which is the third layer in the architecture, has been developed to manage documents processing workflows by integration SGML documents contents and process information into the structured SGML document.

• The Journal of Information Technology and Database
• /
• v.5 no.1
• /
• pp.97-108
• /
• 1998

This paper proposes a conceptual taxonomy of architectures for workflow management systems. The systematic classification work is based on a framework for workflow architectures. The framework, consisting of generic-level, conceptual-level and implementation-level architectures, provides common architectural principles for designing a workflow management system. We define the taxonomy by considering the possibilities for centralization or distribution of data, control, and execution. That is, we take into account three criteria. How are the major components of a workflow model and system, like activities, roles, actors, and workcases, concretized in workflow architecture. Which of the components is represented as software modules of the workflow architecture\ulcorner And how are they configured and operating in the architecture\ulcorner The workflow components might be embodied, as active (processes or threads) modules or as passive (data) modules, in the software architecture of a workflow management system. One or combinations of the components might become software modules in the software architecture. Finally, they might be centralized or distributed. The distribution of the components should be broken into three: Vertically, Horizontally and Fully distributed. Through the combination of these aspects, we can conceptually generate about 64 software Architectures for a workflow management system. That is, it should be possible to comprehend and characterize all kinds of software architectures for workflow management systems including the current existing systems as well as future systems. We believe that this taxonomy is a significant contribution because it adds clarity, completeness, and global perspective to workflow architectural discussions. The vocabulary suggested here includes workflow levels and aspects, allowing very different architectures to be discussed, compared, and contrasted. Added clarity is obtained because similar architectures from different vendors that used different terminology and techniques can now be seen to be identical at the higher level. Much of the complexity can be removed by thinking of workflow systems. Therefore, it is used to categorize existing workflow architectures and suggest a plethora of new workflow architectures. Finally, the taxonomy can be used for sorting out gems and stones amongst the architectures possibly generated. Thus, it might be a guideline not only for characterizing the existing workflow management systems, but also for solving the long-term and short-term architectural research issues, such as dynamic changes in workflow, transactional workflow, dynamically evolving workflow, large-scale workflow, etc., that have been proposed in the literature.

• Proceedings of the CALSEC Conference
• /
• 2003.09a
• /
• pp.230-235
• /
• 2003

A Workflow Management System is one which provides procedural automation of a business process by management of the sequence of work activities. The existing workflow management systems have limitation of interaction among application systems. In this paper, we propose a new workflow management system that can be adapted in dynamically changed paradigm of distributed computing by using Web Service. System Architecture and prototyping execution model of the system is described in BPEL4WS.

• Journal of KIISE:Databases
• /
• v.28 no.3
• /
• pp.395-405
• /
• 2001

In this paper, we analyze workflow management system in programming language aspects. Many workflow characteristics such as workflow relevant data, workflow control structures, and workflow application invocations are studied and compared with those of distributed parallel programs. Although there exist minor differences between them, we found that there exist surprisingly many analogies between them. Based on this observation, we suggest to view workflow management system as distributed parallel program development platform. This new view on workflow management system provides users consistent view on workflow and workflow management system and with this view workflow management system designer can cope with arbitrary requests from the users keeping design consistency. Moreover the analogy between workflow and program provides a basis to apply program analysis techniques to the analysis of workflow.

• Proceedings of the Korea Database Society Conference
• /
• 1998.09a
• /
• pp.525-543
• /
• 1998

This paper proposes a conceptual taxonomy of architectures far workflow management systems. The systematic classification work is based on a framework for workflow architectures. The framework, consisting of generic-level, conceptual-level and implementation-level architectures, provides common architectural principles for designing a workflow management system. We define the taxonomy by considering the possibilities for centralization or distribution of data, control, and execution. That is, we take into account three criteria. How are the major components of a workflow model and system, like activities, roles, actors, and workcases, concretized in workflow architecture？ Which of the components is represented as software modules of the workflow architecture？ And how are they configured and operating in the architecture？ The workflow components might be embodied, as active (processes or threads) modules or as passive (data) modules, in the software architecture of a workflow management system. One or combinations of the components might become software modules in the software architecture. Finally, they might be centralized or distributed. The distribution of the components should be broken into three: Vertically, Horizontally and Fully distributed. Through the combination of these aspects, we can conceptually generate about 64 software Architectures for a workflow management system. That is, it should be possible to comprehend and characterize all kinds of software architectures for workflow management systems including the current existing systems as well as future systems. We believe that this taxonomy is a significant contribution because it adds clarity, completeness, and "global perspective" to workflow architectural discussions. The vocabulary suggested here includes workflow levels and aspects, allowing very different architectures to be discussed, compared, and contrasted. Added clarity is obtained because similar architectures from different vendors that used different terminology and techniques can now be seen to be identical at the higher level. Much of the complexity can be removed by thinking of workflow systems. Therefore, it is used to categorize existing workflow architectures and suggest a plethora of new workflow architectures. Finally, the taxonomy can be used for sorting out gems and stones amongst the architectures possibly generated. Thus, it might be a guideline not only for characterizing the existing workflow management systems, but also for solving the long-term and short-term architectural research issues, such as dynamic changes in workflow, transactional workflow, dynamically evolving workflow, large-scale workflow, etc., that have been proposed in the literature.

• Proceedings of the Safety Management and Science Conference
• /
• 2006.11a
• /
• pp.415-426
• /
• 2006

Many technical and nontechnical issues hinder enterprise wide workflow management. The most significant technical issue is the inability to deal with the heterogeneity among users, workflow types, and WFMSs. Not all users demand the same workflow functionality, so user interfaces of different levels of sophistication are required. Because workflow types cannot always be fully predefined, they often need to be adjusted or extended during execution. Unlike relational database management systems, however, each WFMS often has differing workflow metamodels. This leads to incompatibility between WFMSs, making integration into an environment comprising many heterogeneous WFMSs a troublesome and sometimes impossible task. Current Workflow system consists mainly of Database system. It contains some problems like that the integration relationship among system processes cant be expressed properly. This research has been focused on two phases that should be considered in the Workflow system. First of all, the first phase is the analysis phase; one of its role is to figure out independent execution task unit(Workflow component). The second phase is design phase that provides with the framework to execute these task units actively. The Workflow component extraction method in the analysis phase uses a analysis method called C-C Net and, in the design phase, the architecture that makes the these Workflow component executed actively is provided. Through this research, each process is divided into a task unit and more effective Workflow system could be formed by executing these units actively. Current system layer calls task units, on the other hand, the Workflow system this research implemented provides with the architecture that places a layer between them that controls task units actively.

• Korean Management Science Review
• /
• v.20 no.2
• /
• pp.17-31
• /
• 2003

A workflow management system is a software system to support accurate execution, control and management of business processes. It has been known that the system automatically executes complex processes and effectively manages them to improve the productivities. However though existing systems assure the automatic execution of an individual process, there is a room for enhancement from the view of efficient execution of all the processes. In this paper, we propose a method of executing business processes efficiently by introducing the PERT/CPM techniques in the workflow management systems. We first consider the differences between workflow process models and PERT/CPM models, and then develop a method of calculating the critical path and slack time in workflow processes. This leads us to develop a dispatching rule that can guide task performers to prioritize their tasks to increase the efficiency of ail the processes. We have carried out a set of simulation experiments and analyzed the results to demonstrate the effectiveness of the proposed method.

• Journal of Internet Computing and Services
• /
• v.20 no.3
• /
• pp.77-84
• /
• 2019

Workflow management system is a system that manages the workflow model which defines the process of work in reality. We can define the workflow process by sequencing jobs which is performed by the performers. Using the workflow management system, we can also analyze the flow of the process and revise it more efficiently. Many researches are focused on how to make the workflow process model more efficiently and manage it more easily. Recently, many researches use the workflow log files which are the execution history of the workflow process model performed by the workflow management system. Ourresearch group has many interests in making useful knowledge from the workflow event logs. In this paper we use XES log files because there are many data using this format. This papersuggests what are the cardinalities of the temporal workcases and how to get them from the workflow event logs. Cardinalities of the temporal workcases are the occurrence pattern of critical elements in the workflow process. We discover instance cardinalities, activity cardinalities and organizational resource cardinalities from several XES-based workflow event logs and visualize them. The instance cardinality defines the occurrence of the workflow process instances, the activity cardinality defines the occurrence of the activities and the organizational cardinality defines the occurrence of the organizational resources. From them, we expect to get many useful knowledge such as a patterns of the control flow of the process, frequently executed events, frequently working performer and etc. In further, we even expect to predict the original process model by only using the workflow event logs.