Discussion on applicability of jbpm and projects
Reprinted by the author:
By: 88250
Blog: http:/blog.csdn.net/dl88250
MSN & Gmail & QQ: DL88250@gmail.com
This article discusses the applicability of jbpm (for the sake of conciseness, without special instructions, jbpm is dedicated to jbpm 3) in the beyondtrack project, this also raises some questions about workflow engine selection .... i. why jbpm was selected
- Because beyondtrack projects are special, a flexible workflow engine is required for underlying support, allowing users to deploy, modify, customize processes, activities, and tasks at runtime. The variables mechanism provided by jbpm, coupled with powerful hibernate Orm, meets the needs of the project.
- Jbpm is an open-source (lgpl) workflow engine with good reputation in the industry. Open source, which means thatCodeI learned a lot of knowledge and canModify its codeComplete to meet application development needs.
Ii. Reasons Why jbpm is abandoned
- the API design of jbpm is not very reasonable. The underlying implementation is exposed. The most typical example is the token design. Token is one of the most important concepts in jbpm
, but it is also one of the most important underlying APIs of jbpm
. Exposing this concept to users will only increase the complexity of user development. When the complexity of the user's business logic is high, it is costly to use token to control the execution of the process. I think, the most fundamental reason is that the uniformity of the abstract layers of interfaces is not considered in jbpm design. .
- jbpm performance is also an important issue. This is also a design issue. jbpm has a 'repeat' problem in the design of many classes, which leads to the ing of database table fields with redundancy, when you want to obtain certain objects in the object model, the underlying database has too many accesses. once the data volume comes up, the problem is obvious. .
- jbpm is an open-source product. It was chosen because it is open-source. It is also the same reason to abandon it. It is not because of the license issue, but because open-source products may change a lot. Design changes, project activity changes, and other factors. Not long ago, jbpm 4 alpha1 was just released. jbpm 4 has been completely rewritten, and the original model has been completely abandoned, bringing PVM (Process Virtual Machine ), and a series of new services APIs . from the examples of the band, jbpm 4 has been designed very well, but does beyondtrack really need PVM, do you even need a basic workflow engine?
Iii. Considerations before selecting the Workflow Engine 1. Are project applications in the typical "workflow" format? A typical "workflow" application generally includes the following features: Business Process execution needs to be controlled; You need to manage the assignment of Business Process tasks, including concurrent tasks, inter-process redirection, and lock/recovery. . For details, refer to "workflow reference mode". 2. The complexity of project development generally involves two situations:
A. The project scale is large, and the relationship between domain objects is complex. The basic and most of the business processes to be implemented are complex.
B. The project scale is small, the relationship between the domain objects is simple, and the basic and most of the business processes are relatively simple, but a small part of the business logic is more complex. I think, B is a typical scenario where ready-made workflow engines can be considered. Unlike the application framework Applications tend to rely on frameworks in a simple and one-way, And the dependencies between applications and workflow engines are close and bidirectional. And is complex. Even if the workflow engine provides a well-designed extension mechanism and user interfaces, its development complexity cannot be ignored. The biggest problem is that Conversion between domain objects in project applications and workflow engine domain objects . Root lookup, this The contradiction is that it is difficult to separate the business process logic from the precise control required by logical calculation. . Therefore, I think it can be done smoothly Based on the workflow engine. 3. The flexibility of project applications is more specifically the flexibility of user customization in applications. This is actually the most fundamental problem. In fact, in any project, the flexibility of applications and the complexity of development are the eternal opposition. To provide the most flexibility, the development complexity is not average. The biggest difficulty is the selection of the development complexity caused by the flexibility required by the application and the extended mechanism provided by the selected workflow engine. Selection and trade-offs.
Iv. beyondtrack adjustment in "workflow" Implementation 1. "workflow" should be changed to "Software Process"
Beyondtrack aims to provide a team collaboration platform with project management as the core. Therefore, it is more appropriate and professional to define this part of content from the perspective of software processes. See ISO/IEC 12207 (Software life cycle PRocesses) to define the position of this part in the entire project, andConstantly adjust.
2. Specific implementation scheme
Beyondtrack has been using jbpm in the early stage, which is divided into three major logical parts: the underlying data structure, the definition model, and the execution model. While Bt (BeyondtrackThe definition model and execution model are also designed, and the synchronization between the Bt and jbpm definition models and execution models is maintained. Now decideImplement the execution part and underlying data structure in the project, and implement a process engine in the project, Based on Petri Nets Theory. ISO/IEC 15090 (Software and system engineering-
High-level Petri Nets) Can provide some reference (this specification seems to have stopped --!).
