ایجاد موتور گردش کار قابل استفاده مجدد

Every time a workflow solution is conceived there is a large amount of functionality that is eventually reinvented and redeveloped from scratch. Workflow management systems from academia to the commercial arena exhibit a myriad of approaches having as much in common as in contrast with each other. Efforts in standardizing a workflow reference model and the gradual endorsement of those standards have also not precluded developers from designing workflow systems tailored to specific user needs. This article is written in the belief that an appropriate set of common workflow functionality can be abstracted and reused in forthcoming systems or embedded in applications intended to become workflow-enabled. Specific requirements and a prototype implementation of such functionality, named Workflow Kernel, are discussed.

Every time a workflow solution is conceived there is a large amount of functionality that is eventually reinvented and redeveloped from scratch. Workflow management systems from academia to the commercial arena exhibit a myriad of approaches having as much in The workflow reference model proposed by the workflow management coalition [17] defines a framework for relating workflow management systems and their capabilities. Within this framework, supporting tools, execution services, client applications and external applications interact according to a set of interfaces. At the heart of this framework is the workflow enactment service, an execution service comprising one or more workflow engines. According to the reference model, a workflow engine is “a software service that provides the run time execution environment for a process instance” [17]. In this sense every workflow product, prototype or approach entails a workflow engine in one way or another. Interpreting a process definition, creating process instances from those definitions, and managing the execution of those instances are essential chores of every workflow management system. These capabilities represent functionality that is coded and embedded in every workflow solution. Notwithstanding, workflow systems are usually portrayed by supporting tools such as process editors or audit trail viewers. The important workflow functionality, however, is the one creating and managing the execution of process instances by iterating through individual tasks and triggering the appropriate actions. Up to now, this functionality has been typically implemented over and over again as each workflow management system is developed. Existing standards or common views such as the ones proposed by the WfMC could lay down the guidelines for implementing workflow engines. And, to some extent, they do. But, as pointed out by [15], existing standards focus on the syntax of the reference model interfaces without clearly specifying the respective semantics and usage. Therefore, when confronted with specific user needs, developers often make use of standards according to their own interpretation. The previous authors go even further and compare the present situation with the early days of database management when, in the absence of the relational and entity-relationship models, an incongruous set of database solutions coexisted. In this respect, this article argues, as other authors have done, that Petri net theory could become to workflow management what the relational model became to database management. It is also argued that a reasonable amount of common workflow functionality can be abstracted from existing approaches, and that from this abstraction it is possible to develop a Workflow Kernel that can be reused and embedded in workflow-enabled systems and applications, so as to prevent repeated and discordant implementations of general workflow features.

Instead of developing every workflow management system from the ground up, it should be possible to come up with a generic and reusable set of functionality that provides the basic capabilities of a workflow engine. This paper has focused on the development of such a reusable workflow engine. To ensure that the workflow engine is independent of any particular workflow system architecture, the system makes use of Petri nets and extends them with the concepts of Actions and Events. On one hand, Petri nets provide a solid foundation, formal semantics and pave the way for process analysis and verification. On the other hand, the concepts of Actions and Events insulate the system from particular mechanisms of resource invocation. By means of a set of external and callback interfaces, it is possible to develop components that augment the functionality of the Workflow Kernel, until the result is a system that covers the entire functionality of a workflow management system.