1 Introduction
Currently, computer applications for enterprises or departments are not only stayed on these simple business levels such as document processing, document circulation, and information release. More and more enterprises or departments require an extension of information technology to critical services. The universal characteristics of the key business are: (1) is survived by enterprises or departments; (2) Business processes are often complicated by many business activities, business logic, and business rules; (3) The completion of business depends on many business activities The interaction between and many business people's collaboration; (4) The amount of data involved is often massive data; (5) If information technology is properly applied to these key business, it is not only possible to improve productivity. It can also reduce the possibility of error. For example, product design and manufacturing processes, bank borrowings and paper bills, and trademark application, review and registration business, etc., all of which belong to the key business of the corresponding enterprise or department. The coordination essence of workflow technology determines its important role in the informationization of critical business.
As described in [1] [2], the workflow is a computational model of the business process, so that the corresponding business logic and business rules are represented in the computer in a proper model and perform calculations. The business process is a collection of business activities, and these business activities are linked together in a certain rule to collaborate to achieve a common goal. Business activities are an actual link capable of completing a specific function, which is usually for specific application logic in the information system. In order to the development of the workflow management system, the Workflow Management Alliance (WFMC) gives a general framework of the workflow system - Workflow reference model [2]. In the workflow reference model, the workflow engine is the core of the workflow management system. The workflow engine is a set of data models and software for the workflow management system in definition while providing interpretation and executing services at runtime. According to the discussion of the workflow engine architecture in the literature [3], we believe that the workflow engine mainly includes three models of institution model, information model, and control model, and the first two is known as the data model of the workflow engine.
This paper takes a specific application project under the National Intelligent Computer Research and Development Center - the trademark registration and management information system of the National Trademark Office is an example, and the basic characteristics of key business of other different enterprises and departments are analyzed. The development needs of the business, on the basis of the traditional relationship DBMS, discussing a specific design principle and implementation method based on a relational structure-based lightweight workflow engine. It fully considers the demand for workflow functions during critical business development, and uses this workflow engine to construct a large information system with workflow characteristics [1].
Part 2 of this article discusses why the relationship structure and the lightweight two concepts are used to design a workflow engine, and Part 3 gives the relevant data model and its representation, then, the workflow engine will be described in Part 4. The control model will finally give the specific application examples.
2 Some discussions related to relationship structure and lightweight
At present, a common phenomenon of software development is the development of software products, which is increasingly developed in the direction of large and complicated, and this paper-based lightweight workflow engine emphasizes its miniaturization characteristics. . Many workflow products often have its own unique architecture from data storage to the operating environment. In addition to the basic functions of workflow, it also claims to be able to integrate third-party applications, and even embedded. Application development of the degree of application. However, developers can really need these complex features.
2.1 Workflow Design Center
The so-called workflow design center refers to who will define and develop workflow applications. So, where should the workflow design center should be? The Ronni Marshak of Patricia Seybold Group has conducted some useful discussion on this issue:
1) It is fully responsible for the definition and development of workflow applications, and some workflow products have also vigorously advocate this. Indeed, the actual business personnel are most familiar with their business rules, but they have not learned about computer technology. Therefore, this is very difficult to easily convert business logic to workflows once business logic is complicated, especially for critical traffic, and if they want to translate business logic to workflow and customize the corresponding application logic, it is very difficult. 2) Combining business personnel and professional technicians. Workflow products provide graphical interface for business personnel (or combined with professionals) to define business logic and rules, and specific application logic is completed by professional developers. The development of applications can utilize the integrated development tools provided by the workflow, and the third party's development tool can also be used. Possible problems are if the development tools integrated using the workflow product are sufficient to the development of the development apps provided; on the other hand, if you use third-party development tools, how to achieve workflow mechanisms integrated.
3) There is also a view that it is necessary to establish a true complex, flexible and scalable application system, and the development of workflows must be integrated into the development of information systems, from the perspective of the entire information system to define business rules in workflows. , Task flow and related roles. Even more extreme views believe that the business rules should be hard coded into specific applications. If the business rules are more stable, this method can get a very compact application, which is very difficult to reconstruct the system. .
We believe that for critical services, subsection (2) or subsection mode is feasible, but must have an appropriate workflow engine support, otherwise it will significantly increase the difficulty and workload of actual development.
2.2 Why is it based on a relational structure
The so-called relationship-based workflow engine refers to the data model (ie, the mechanism model and information model) in the workflow engine is expressed by the relational structure; the various program logic (ie, the control model) of the control workflow engine is also through routine The storage procedures, packages, and triggers provided in the relational database management system are implemented; at the same time, the concurrency control of the transaction is also implemented by the mechanism provided by the database system.
From a technical point of view, using a relational structure to express data models in the workflow engine to reduce technical difficulties and workloads during the development process of workflow engines. Specific performance in: (1) Various control data related to the workflow engine (state data including business activity) can be stored in the database system; (2) The integrity of data related to this can be maintained by the database management system (3) Using a relational structure, it is convenient to define various data formats and data structures in the workflow engine; (4) Easily utilize the various DML statements provided by the database management system to manipulate the various types of workflow engines. data.
From the perspective of developing application systems, providing developers with a relational workflow engine in the same database environment, and if the function provided by this workflow engine can easily embed the application's development environment, Reduce the difficulty of developing applications. This is because: (1) Application systems for critical services typically use a regular relational database system as a background support; (2) developers of application systems tend to adopt one of them familiar with and suitable for this database system The front-end development tools to develop specific applications, and these front-end development tools have a significant feature of development, but generally does not have a workflow mechanism. Therefore, it is easy to seamlessly integrate with the application's development environment based on a relational workflow engine.
2.3 Why use lightweight
The lightweight workflow engine refers to the completeness and complexity of the function of the workflow engine from sufficient, flexible, and low-cost design principles, just implementing the functional and characteristics of the workflow engine. The main consideration of the definition and interpretation of its data model is mainly considering the definition and interpretation of its data model, and the functionality of the task and the allocation and control of the task are not supported, such as a Built-IN) application development tool. Declining and integrity maintenance, perfect exception processing and long transaction control. The reason why we use "lightweight" is mainly painted by the workflow engine.
1) Many existing workflow products provide an integrated function of external tools to varying degrees, and some products also provide customization and development environments based on form-based application logic. However, the diversity and complexity of the external tool determine the integration of external tools to be seamless; and the development tools built by workflow products are not compatible with popular development tools, and their development functions are often relatively simple. Therefore, these products are suitable for simple applications (such as publication, approval of orders, etc.). However, if it is a development of key business applications (especially industry application systems), the development functions that existing workflow products can provide far less.
2) Many development tools for DBMS provide strong application development methods, but these development tools often do not have support for workflow mechanisms, and existing workflow products are difficult to develop environment due to their different development points. Organically integrated together. Therefore, developers often have to find a suitable workflow support system to develop workflow characteristics.
3) The morphology of the application with workflow characteristics is evolved, and it is often not intended to be unified in a workflow system. The application developed by this so-called flexible workflow system is not flexible in the actual operation process. Therefore, another opposite trend is that the logic of the application is still completed by a dedicated application development tool. The workflow engine only manages the relevant control data, and only the necessary association means to link it with the control data.
4) There are already many middleware products (various applications servers, TP, etc.) to provide control capabilities for application transactions including long transactions, and these products can be used.
The TAGG [4] of the New Zealand Massey University has used the term "lightweight" in the description of the workflow engine, but its focus is how to construct a "thin client". Our focus is to design a small core that fully supports workflow features, which can seamlessly embed the traditional application development environment.
In summary, the relationship-based lightweight workflow engine is such a product: it can define a workflow data model on the traditional relational database; it uses DBMS embedded programming language to implement workflow engine Control logic; it provides a series of comparison APIs, developers of applications can embed these APIs into their own application systems to implement information systems with workflow properties. The applicable object based on the relationship is not the end user of the application system, but uses a special development tool to construct a professional developer of the corresponding application system. It provides developers with support for driving workflows, thus constructing a variety of flexible application systems with workflow characteristics. The specific expression is: a set of table structures, a set of model tools and APIs for practical application calls.
3 data model
Data models of a lightweight workflow engine based on a relational structure include a mechanism model and information model. The agency model describes the organization of organizations or departments, and the information model defines the various control data used in the workflow engine. Through the data model, it is convenient to describe the characteristics of the business rules, activity dependencies, and tasks assignment of the task. They are all defined by a unified relationship structure. Figure 1 shows an ER diagram of a data model for a lightweight workflow engine based on a relational structure (limited to the core table structure).
3.1 Institutional model and mechanism model The table mainly has STAFF, Department, Team, STAFF_TEAM, ROLE, and STAFF_IN_ROLE, and the relationship between the tables has been marked in the figure through different meanings. The following will have some explanation of some of these meanings.
Department and Teams represent departments and teams respectively, the department usually represents the longitudinal administrative affiliation, and the team usually represents the horizontal partnership. The Department and Teams are associated with the corresponding super_dept_id and super_team_id, which makes a tree-shaped upper and lower relationship between the sectors and the team, respectively.
STAFF records individual information related to personnel, where logging_on indicates whether the corresponding person is currently logged in to the system, and ON_LEAVE indicates whether the person is in vacation, and the two information will be assigned as a task in the workflow engine. . The outer code DEPT_ID in STAFF indicates the department being affiliated with the person. Relationship staff_team specifies the membership relationship between the person and the team.
Department, team, personnel, and inter-agency's relationships in a mechanism model provide strong support for large-scale enterprises, especially those engaged in technology, and also provide popular management models in modern enterprises - "Matrix Management" Support. Of course, for small agencies, it can be considered to define one of the department or teams. Since Department and Team have no contacts in the ER diagram, it is deck that it does not destroy the integrity of the mechanism model.
Role further expands the modeling capacity of the institution model, and the relationship between STAFF_IN_ROLE is established between STAFF and ROLE. Introducing role in a mechanism model This concept is mainly to enhance the ability of the task assignment, and the relevant concepts in the role will be further explained in the follow-up of this paper.
Figure 1 Data Model ER
3.2 Information Model
The core of the information model is the business activity table (referred to as activity) Activity. Other related table structures mainly have business procedures Process, business rules (active flow rules) Routing_rule, dependent rules pre -_rule, task assignment rule assegn_rule, task list to_do_task_list, Completed task list Have_done_tasks. As can be seen from the figure, there is a connection between Activity and other tables.
3.2.1 Activity Type
Each business process consists of several business activities. Different business activities uniquely identified by different ACT_IDs, and ACT_TYPE indicates the type of active activity. The same business activity may have multiple instances (instance) when the workflow is run. We will call examples as tasks [2] [2], which will be called the task belonging to the same batch of tasks. Some business activities may target specific business links, ie corresponding to actual application logic at the front desk (background); some business activities are not targeted for specific business links. The activity type can be made as follows:
l Initial, initialization activities, the first activity of the business process, not for the specific business link.
l Interaction, regular interaction activities, Interaction activities correspond to the actual business link, and the actual application logic is carried out at the front desk, and the activities need to participate. In all active types, only Interaction activities need to interact with actual personnel.
l Automation, conventional automatic activity, the same correspondence corresponds to the actual business link, but the actual application logic is in the background, and the workflow engine is automatically called. Auto_executive indicates the active body of the corresponding application logic.
l And_branch, with branch activities, not for specific business links, this activity will be derived at the same time.
l And_merge, with aggregation activities, is a step activity, not for the specific business link, the task flowing through this will be synchronized with aggregation. This activity will perform the actual relying rule check for activities, and only all the relying rules are satisfied, and they can flow to the successor. l OR_MERGE, or aggregation activities, is a step-by-step activity, not for the specific business link, the tasks flowing here will be processed or aggregated. It will also perform the actual relying rules of the activity, but as long as there is a pre-reliance rule, it can flow to the successor activity. OR_MERGE_FLAG is used to specify or aggregate conditions.
l Vote_Merge, voting aggregation activities, is a conventional event, not for the specific business link, the same batch of tasks can only flow to successive events only to Num_VOTES_NEEDED.
l Dummy, dumb activities, not for specific business links, which can be used as virtual successive activities of certain activities, and it can also use it to construct more complex business rules. If there is a successful activity, it can be immediately flowed to the successor.
l Completion, end activities, indicate the end of the corresponding business process, not for the specific business link.
3.2.2 Expiration of Business Rule
In the workflow engine, the business rules can decompose to the active definition rules and active regulations. The active definition rule indicates the start condition of the corresponding activity, and the startup condition is expressed by the corresponding active directive activity and the corresponding status flag, the pre-reliance rule contains the order, aggregation, or convergence and voting aggregation. The post-acting forwarding rule refers to what successive activity is started after the task corresponding to the current activity, and the forwarding rule contains three rules of order, or branch and branch. The pre_rule table, the routing_rule table, and the ACT_TYPE and Rule_APPLIED and other fields in the Activity table are jointly representative of the active rules and post forwarding rules.
Since we extract all kinds of aggregation activities, you can express the pre-dependent and post forwarding rules of the activity with a very simple relationship structure. First, the Rule_Applied field in the Activity table indicates what rule judgment guidelines should be used in the corresponding activity, which can have four values: default, user_defined_pre_rule, user_defined_post_routing_rule and user_defined_both_rule. Default means that the workflow engine automatically checks the rule check according to the pre_rule table and the routing_rule table. Considering the diversity of business rules, this paper provides custom methods to express special business rules that cannot be represented by default rules, and EX_PRE_RULE_FUNC and EX_POST_RULE_FUNC in the Activity table specify a custom call interface of the front-dependent and post forwarding rules, respectively. The behavior of custom business rules is completely determined by the corresponding program. Under normal circumstances, most business rules can be expressed directly through the default mode. Next, the representation of the rules and post forwarding rules before the default method will be discussed.
The post-acting rules are mainly expressed by table routing_rule, and the post-forwarding rules can be used as the following four yuan to express:
Post_ROUTING_RULE = (pre_act_id, curr_act_id, completion_flag, next_act_id_list)
The meaning is: in the case where the current active ACT_ID is curr_act_id, if the current active active act_ID is pre_act_id, the current active end is marked as completion_flag, the workflow will flow to the successive active indicated by Next_ACT_ID_LIST.
Former dependency rules need to be combined with pre_rule, routing_rule, and activity, the front-dependent rule can be expressed in a three-way group, namely: pre_dependency_rule = (pre_act_id, curr_act_id, pre_Depnt_set)
Pre_Depnt_set is the front-dependent activity set, and each element can be represented by another three-way group:
ELEMENT_PRE_DEPNT_SET = (DEPNT_ID, DEPNT_ACT_ID, DEPNT_ACT_STATUS)
The meaning of pre_Dependency_rule is: whether the current activity CURR_ACT_ID that is turned over before the active pre_id_ID can start depends on whether the activities contained in the pre-dependent activity set pre_DEPNT_SET have reached the end status of each of the respective reaches DEPNT_ACT_STATUS. It can be seen that only those controversial activities in the previously rely on activities can be jointly constituting the constraint relationship to the current activity. If a pre-dependency rule is a vacant set, it indicates that the current flow is The flow of current activities has no relationship with other foresight activities, and the corresponding current activity can be started immediately.
3.2.3 Task queue and completed task queue
One activity can have multiple instances, ie tasks, which may be a batch, or may belong to different batches, and the water number serial_no is used to identify the batch belonging to the task. All the tasks belonging to the same batch have The same water number; between different tasks, the identity is performed by the unique task_id.
The lightweight workflow engine discussed herein does not involve the management of specific applications logic and application data, however, a means must provide a means to associate with the application entity in the workflow engine, otherwise, separate The task will not have any practical meaning. The entity identification entity_ID played this bridge effect, and the true meaning of the value is completely interpreted by the application logic, for example it can be a number, or the name of a file. Entity_ID is set when the business is initialized, and its value can also be changed at any time during service flow.
Task queues to_do_task_list is used to record those tasks that have been created but have not completed. The tasks in the task queue have four states: (1) Pending, task is in the "and convergence" synchronization status, that is, waiting for other related tasks The end; (2) Waiting, the task is ready, is in the state of "waiting processing"; (3) Processing, the task is in the state "positive processing"; (4) Pausing, the task is in the "pause" state.
The task queue HAVE_DONE_TASKS has been completed is used to record the tasks that have ended normally, and the completion_flag indicates the end tag of the corresponding task.
Staff_id means that the actual person who executes this task, if the grantor_id is empty, the execution process of this task is authorized, and Grantor_ID indicates the corresponding authorized personnel.
3.3 Task Assignment
The task assignment refers to what criteria to assign tasks to specific personnel. Only regular interactions involves the issue of task assignment; other activities either do not have actual application logic in the front desk, or automatically call the workflow engine, there is no relationship with the task assignment.
Many tables and fields in the aircraft model and information model have been mentioned above, and the task assignment of the workflow engine is combined. The core table structure is ASSGN_RULE, and each regular interaction activity corresponds to a record in the assgn_rule table. Based_on indicates a basemark of the task assignment, it can take one of the following four: (1) dept_based, based on the department for task assignment, DEPT_ID is used to specify a department that performs this activity; (2) Team_based, based on the team, TEAM_ID A team that specifies this activity; (3) Role_based, based on the role, Role_ID is used to specify the role of this activity; (4) user_defined, performing a task assignment based on a custom, EX_FUNC indicates the corresponding custom execution program. The benchmark for the task assignment determines the group that can perform the corresponding task, which actual personnel may also depend on the task assignment method Method, and Method can take the following value:
l ALL, the task will be assigned to all the people in the group specified by the based_on.
l Least Working List, the task will be assigned to the minimum number of workloads in the specified group, and how much workload can be obtained by the statistics of TO_DO_TASK_LIST.
l FCFA, first allocate (First Coming First Assigning), the first task to create in the task queue is assigned to the corresponding group first to perform the individual requesting the task request, the task creation time is indicated by the Date_created.
l Priority, based on the priority allocation, only suitable for the role_based task assignment baseline. There is a field priority_num in the table staff_in_role to specify the priority of the corresponding person, and this method will assign tasks to the most priority person.
l Round Robin, rotation method, only suitable for role_based task assignment benchmarks. Round_robin_token is a wheel transfer, and the task will be assigned to a person with a wheel transfer.
4 Workflow Engine control model
The control model is organically combined with the mechanism model and the information model, which controls and coordinates the traffic of various business activities in the business process based on the business rules defined. The control model is the control center of the workflow engine.
4.1 Application Framework
Figure 2 shows the frame structure of the application system using the workflow engine proposed herein.
Visualize
Modeling tool
Process
logic
application
logic
Process
logic
application
logic
Process
logic
application
logic
Database interface (Database Communication Protocol)
D b M s
mechanism
model
information
model
Log
information
application
data
engine
Controller
C / C interface
Java interface
Figure 2 Application framework
As shown in FIG. 2, "Visual Modeling Tool" is to describe the business process, then convert it, such as a mechanism model and information model, and then converted to the relationship structure described in the mechanism model and information model. Thereby the data model of the workflow engine is created. Therefore, "Visual Modeling Tool" is the definition center of the workflow engine, and the "engine controller" is the workflow engine in the runtime control center, which is responsible for coordination, scheduling, and control function. Depending on the development environment of the specific application, the workflow engine provides different interfaces in the application framework, such as the C / C interface, Java interface, and direct database communication protocols, thus applications for different types of applications. It provides convenient to interaction with the workflow engine. Application Data in the Application Framework is managed by specific application logic, and the workflow engine does not care about the data format of this part. task
queue
completed
Task queue
Log
information
Dispatch
center
Mission management
Task assignment
Forward control
Dependency check
Start control
information
model
mechanism
model
External interface
Figure 3 Engine Controller Structure Diagram
4.2 Engine Controller
The engine controller is a control center at which the workflow engine is running, and FIG. 3 shows the control structure diagram of the engine controller.
l Scheduling Center
The scheduling center accepts a request from the external interface (such as business initialization, acquisition task, and end task, etc.), and then call the corresponding processing module to complete the operation related to this request according to different request types and return the result. Since the control model of the workflow engine is implemented inside the DBMS, there is a data structure such as request queue and other forms, such as request queue, etc. Therefore, in fact, the scheduling center can be seen as a multi-threaded concurrent server that provides concurrent services to multiple external requests. During the processing of external requests, it will definitely involve reading and writing and changing operations in the internal data structure (ie, the data model of the workflow engine). The integrity and mutex operation of these data can be provided through DBMS. The locking mechanism is achieved, thereby achieving independence between multiple external requests.
l Task management
Task Management is mainly based on the maintenance of transitions such as task creation, task status according to the instructions of the dispatch center, and maintenance of related data. Each "End Task" external request will trigger the scheduling center to create a new instance for afterward activity (if present), its status is "pending"; at the same time, other different external requests will also trigger "task" Manage "Switching of the Task Status. The task status conversion map is shown in Figure 4.
Initiality
Pending
Waiting
PROCESSING
PAUSING
Final state
Create tasks
Synchronize
Get task
End task
Hang
Reset
Aggregation synchronization
Figure 4 Task status conversion diagram
l Task assignment
Task assignment is only for conventional interaction activities, in general, in the task status, the assignment of the task is completed by "Peiting" to "Waiting", that is, the task in the ready state determines its executor in the usual case ( Except for FCFA). The task assignment process first determines the group personnel that can perform this task according to the task assignment benchmark, usually this is a collection of multiple people; then determines which individuals in this group will perform tasks based on the task assignment method to perform tasks, perform tasks The individual identity is recorded in the STAFF_ID field recorded in the corresponding task. The task assignment method has been explained in Section 3.4. There are two points to emphasize:
1) If the task assignment method is "all", the current task record will be copied, ie, the individual that performs the task has a corresponding record in TO_DO_TASK_LIST;
2) If the task assignment method is "FCFA", in fact, the task assignment phase does not do anything, that is, the STAFF_ID field recorded in the corresponding task is empty. At this point, the task assignment work is automatically implicit in the request of the task, that is, who will automatically assign this type of task to anyone first. l depending on the inspection
Relying on the inspection refers to the inspection of the actual dependency rule, the scheduling center checks the pre-dependent rule check before switching the task to the ready state, and only the task that satisfies the inspection criteria can be switched. The foregoing has been described with reference to the pre-reliance in the data model, which mainly discusses how the control model is processed for various prior relying rules.
For the order-dependent rules, it is clear that from the previous event stream is transferred to the current activity, the pre -Depnt_set is empty set. There is no other constraint for the current activity. The corresponding task can be converted immediately by "pending" state. " Waiting "status.
For other foregoing rules, PRE_DEPNT_SET indicate all other contextual activities, only all relevant pro-activities arrived to each specified end state DEPNT_ACT_STATUS, the current active party can start.
For the aggregate relying rule, pre_Depnt_set is empty set. This rule checks the ORGE_FLAG in the Activity table, or_merge_flag's value can be one of the end tags of all related pre-active or a special tag "Any ". If the value of or_merge_flag is not "any", the end tag "of the corresponding pre-active end tag" If the same, start the current activity, if the same, no processing; otherwise, if the value of or_merge_flag is " ", First ended, the pre-event will start the current activity, and the ended activity will be discarded.
For voting aggregation activities, pre_DEPNT_SET is also empty set, and the current activity should wait until the number of Num_VOTES_NEEDEDs belonging to the same batch task can be started. The number of tasks belonging to the same batch can be gadked by acting to TO_DO_TASK_LIST in accordance with ACT_ID and SERIAL_NO.
l forward control
When the application issues an external request of "End Task", the request will trigger the dispatch center to "forward control". The forwarding control is based on the post-forwarding rules defined in the workflow data model, and the post-forwarding rules define the relationship between the current activities and the successive activities. The process of forwarding control is the "task end tag" carried in the "End Task" request and the corresponding pre-active and current active identifier match the record in the ROUTING_RULE table, resulting in the corresponding subsequent active list next_act_id_list; then The Scheduling Center launches "Task Management" to create a new task for the corresponding subsequent activity based on the subsequent activity list.
For sequential forwarding and or branch forwarding rules, next_act_id_list contains only one activity; for the branch forwarding rule, multiple activities will be included in next_act_id_list.
l Start control
Start control is responsible for the launch of the corresponding automatic executive that is automatically active and monitors its activities.
5 application example
The relational lightweight workflow engine based on the relational structure discussed herein has a specific application object, namely the trademark registration and management information system of the State Trademark Office. This is a large information system, which involves approximately 18 trademark processing business at all business offices of the Trademark Office, such as the new application for business, trademark changes business, and trademark transfer business, all of which belong to the key business of the Trademark Office; At the same time, this is also a information system with massive data. Before implementing our project, the Trademark Office has an early system store all registered trademark information, with a total of about 1 million trademarks, more than 10G bytes historical data. In the future, with the development of the trademark business and the electronic components of other trademark business, the data volume will also increase a quantitude. In all trademark services, most business processes are more complicated, such as new applications for trademarks, and more than 15 main business activities, these business activities have both order relationships, and parallel relations, most of them include reciprocating relationships. And the dependence between each other is more complicated. Through the survey, we found that existing workflow products are difficult to meet the needs of the system in process control, data processing, and application development. This forces us to design and implement a workflow engine as described herein. We use Oracle's developer / 2000 development logic for trademark services, and then embedded in the application logic to implement the control of the workflow engine. At present, the system has been fully developed and testing, and immediately put it officially run. The actual application instance shows that because we have a support of a relational workflow engine, we can focus on the development of application logic. The lightweight workflow engine based on the relational structure reflects its value during the development of critical business.
references
[1] Hollingsworth D. Workflow Management Coalition: The Workflow Reference Model. Document Number WFMC-TC00-1003, Brussels, 1994
[2] WFMC. Workflow Management Coalition Specification: Terminology & Glossary. Document Number WFMC-TC-1011, Brussels, 1996
[3] Karl R.P.H. Leung et al The Liaision Workflow Engine Architecture In:.. Proc of the 32nd Hawaii Int'l Conf on System Sciences, Hawaii, Jan. 1999, http://www.computer.org/proceedings/Hiccs2/
[4] R. Tagg Et.al. Preliminary Design of a Lightweight Workflow Server. In: 8th Australasian Conf on Information Systems, Australia, 1997, http://business.unisa.edu.au/acis97/
Modified number: 991111-1080
About the Author:
He Qingfa, male, born in 1970, doctoral student, research direction for content-based information retrieval, graphics and image processing, information systems and databases.
Li Guojie, male, 1943 born, academician, doctoral tutor, research direction for parallel processing, artificial intelligence and high performance algorithm design.
Jiao Li Mei, female, born in 1971, master, engineer, research direction for object-oriented database, knowledge base and a thrust machine.
Liu Li Li, male, born in 1974, master's degree, research direction is information system and database technology. [1] [1] If there is no particular explanation, the concepts, application systems, and information systems described herein are for critical business.
[2] [2] For the convenience of the narrative, we may sometimes do not strictly distinguish between activities, activities, and the three concepts of the task. In some cases, the activity refers to the active examples, which can be distinguished from the context. .
