I have studied software processes, workflows, process specifications, and products in the software life cycle field for almost half a year. The research focuses on open-source, open-source, and industry-related standards. A bit of superficial experiences are as follows :-)
For the software process support environment:
- Eclipse: EPF
The scale of relatively formed communities has not been studied in depth. However, it seems that eclipse is basically difficult to use, and the development progress of the Community is worrying.
- OMG: spem
A specification is a specification. The implementation of spem is rare, and there are few domestic studies. It seems that the Chinese Emy of Sciences has an implementation. Foreign users are still paying little attention to it. Specifications, big and complete ....
- IBM: Jazz
The Jazz-based concert is of great reference value in terms of product functions. It was finally developed by IBM. Unfortunately, it is not open-source. It is relatively closed to external developers and the implementation details are invisible. In general, osgi applications can only be implemented with a large investment.
- Emforge
In the rapid development stage, the process based on jbpm 3 is processed, and the design is poor. But it has some reference value. In particular, the integration of jbpm and jspwiki by spring is of reference value.
- JIRA
It is very mature and provides free support for open-source projects. The process implementation is based on osworkflow. However, JIRA has modified a lot of engine implementation to support its application. There are many functions to refer.
- Mingle
It is too closed for developers (after all, it is purely commercial, unlike the half-closed version of jazz...), but it is worth learning about the support needs of agile teams.
For workflow engines and languages:
- Jbpm 3
Without a good design, as the implementation of customer code, designers can understand the poor APIs. From the code, we can see that the designer basically refers to the repair, modification, and modification, and many theories are referenced in the earlier version. Later versions (3.2.3) are basically nothing like things, although I have proposed a graph-based programming model, I think this is meaningless. Isn't it a visual process design environment and execution engine? However, it is certain that the author adds a stable choice to the open-source community.
- Jbpm 4/PVM
Currently, it is still under development and the design is relatively mature. At least the APIS design that is exposed to the customer code is reasonable. Unfortunately, PVM is not as good as the author and JBoss, so feasible (fully compatible with BPEL) that only the author has a spectrum. From the current implementation point of view, the brand-new jpdl is still the focus of PVM .... jpdl of this version is indeed well designed and has good versatility (Java, bean shell, SQL, etc). However, the more support, the better ????
- WS-BPEL/BPMN
In other words, norms are norms. Although it mainly targets service compilation, from the perspective of sub-process extension, humantask, and bpel4people, it is fully qualified for workflow and BPM. Unfortunately, expansion is a commercial implementation. It's easy to use and keep up with the money. BPMN 2.0 seems to have solved the problem of the transformation to BPEL, and I have no chance to use it yet.
- Domestic solutions
Puyuan quick development platform... I can't afford it. I only read the workflow design. The product designers have a profound knowledge and solid theory. However, it is similar to fireflow, which is currently quite eye-catching. Its thoughts and implementations are not flattering .... the author's use of Petri Net theory is problematic, at least not based on "strict formal definition" as the author says ", in addition, there are many studies abroad that separate "business" from "engine systems .... petri Net can solve the problem, but it depends on how to use it. If it is based on Petri net, pay attention to the definition and implementation of concurrency and selection.
Digress:
- Portal implementation
Liferay is worth looking at the source code. Integration is indeed very authentic, and foreign applications are indeed worth learning by Chinese developers.
- Google
I believe there are a lot of researchers. Recently, Gae (Google App Engine) has attracted the attention of Java developers. What Google offers is worth looking at, especially the design of Apis exposed to customers.
