• Journal of Internet Computing and Services
• /
• v.9 no.6
• /
• pp.89-97
• /
• 2008

Recently, many organizations such as companies or institutions have demanded induction of very large-scale workflow management system in order to process a large number of business-instances. Workflow-related vendors have focused on physical extension of workflow engines based on device-level clustering, so as to provide very large-scale workflow services. Performance improvement of workflow engine by simple physical-connection among computer systems which don't consider logical-level software architecture lead to wastes of time and cost for construction of very large-scale workflow service environment. In this paper, we propose methodology for performance improvement based on logical software architectures of workflow engine. We also evaluate scalable performance between workflow engines using the activity instance based architecture and workcase based architecture, our proposed architecture. Through analysis of this test's result, we can observe that software architectures to be applied on a workflow engine have an effect on scalable performance.

• 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.

• Journal of Internet Computing and Services
• /
• v.10 no.6
• /
• pp.205-217
• /
• 2009

Recently, many organizations such as companies or institutions have demanded induction of very large-scale workflow management system in order to process a large number of business-instances. Workflow vendors have focused on physical extension of workflow engines based on device-level clustering, so as to provide very large-scale workflow services. Performance improvement of workflow engine by simple physical-connection among computer systems which don't consider logical-level software architecture leads to wastes of time or cost for construction of very large-scale workflow service environment. In this paper, we propose workcase-based workflow architecture and implement a very large-scale workflow management system based on the architecture. We prove that software architectures to be applied on a workflow engine have an effect on scalability and performance through workcase response-time evaluation of our proposed system.

• The KIPS Transactions:PartD
• /
• v.13D no.1 s.104
• /
• pp.139-146
• /
• 2006

This paper describes the design and implementation details of a distributed transactional workflow monitoring system. There have been prevalent research and development trends in the workflow literature - workflow systems tend to be completely distributed architectures to support very large-scale workflow applications on object-oriented and internet-based infrastructures. That is, the active (object), distributed (architecture), system-oriented (transaction), and large-scale (application) workflow systems are the key targets in terms of the research and development aspects. While the passive, centralized, human-oriented, and small/medium scale workflow systems are the typical instances of the traditional workflow systems. Unlike in the traditional (the client-server architecture) workflow systems, the workflow monitoring features should not be easily supported in the recent (the fully distributed architecture) workflow systems. At the same time, they need a set of additional monitoring features, such as gathering and displaying statistical (or overload status) information of the workflow architectural components dispersed on the internet. We, in this paper, introduce the additional workflow monitoring features that are necessarily required for the recent workflow systems, and show how to embed those features into a web-based distributed workflow system.

• 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.

• 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.

• Journal of KIISE:Information Networking
• /
• v.27 no.2
• /
• pp.226-236
• /
• 2000

The best-fit workflow management system architecture for the workflows in the internet is dependent on the workflow types that should be processed in the workflow system. Since a workflow management system should accommodate various kinds of workflows requiring different workflow system architectures respectively as their best-fit workflow system architectures, it is ideal that a workflow system covers various workflow system architectures and changes its architecture according to the input workflow types. In this paper we propose a workflow system architecture that covers various workflow architectures within a single workflow system. The system changes its architecture by creating an execution object for a task in the form of an object instance and placing the created object instance to anywhere the system wants to. Performance test has been performed on the early versions of the system changing its architectures, and the results are illustrated. The results show that the distributed multiple workflow servers in the internet can contribute to not only reliable control of the distributed tasks but also enhancing total throughput of a workflow system.

• 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.

• KIEAE Journal
• /
• v.16 no.5
• /
• pp.21-28
• /
• 2016

Purpose: The Objective of this study is to explore the capabilities of an integrated modelling and simulation workflow when applied to an experiment-based research process, aimed at deriving daylight optimization strategies specific to tall buildings. Methods: Two methods were devised to apply this workflow with the help of DIVA and Rhino/Grasshopper. The first method is a multiple variant analysis by setting up an appropriate base case and analysing its daylight and energy performance, forming the basis of comparison for subsequent cases for design variants. The second method involved setting up the base case within a site context and conducting a solar irradiation study. An architectural variables such as overhang and shading device, were then defined as inputs in the parametric definition in Grasshopper to control the selected variable. Results: While the first method took advantage of the speed and efficiency of the integrated workflow, the second method was derived based on the ability to directly process simulation data within the integrated, single-software platform of the proposed workflow. Through these methods, different architectural strategies were explored, both to increase daylight penetration and to reduce radiant heat gain. The focus is on methods by which this workflow can be applied to facilitate the experimental derivation of daylight optimization strategies that are specific to tall building design.

• Journal of the Society of Naval Architects of Korea
• /
• v.44 no.3 s.153
• /
• pp.332-339
• /
• 2007

Integration of engineering information through the IT (Information Technology) is very important key during the collaboration design process. How can we realize the data efficiently in real-time at the early design stage? How can we manage to integrate the separate information made by each designer or department effectively in real time? IT global trend is the unique way of handling these complicated problems from the information inundation. This paper suggests the design process management system deduced from the analytical results considering BPM (Business Process Management) solution workflow. Workflow based design process management system can help user share and integrate the needed information at the right time through Internet. It is found that the proposed tool works well for a beam design case, and this framework can be thus further expanded for an engineering design environment smoothly.