Research on products and specifications related to software life cycle process

About the software process, or the software life cycle in the field of workflow, process specifications, product research for almost half a year. The main research is open source, open, industry standards-related, a little superficial experience, outlined below:-)

For software Process support environments: ECLIPSE:EPF
Compared to the size of the formed community, there is no in-depth study. But it feels like the things underneath eclipse are basically more difficult to use, and the progress of community development is worrying. Omg:spem
Norms are norms, but also norms. The implementation of SPEM is rare, domestic research is very few, looks like the Chinese Academy of Sciences has a realization. Foreign attention is also relatively small, still stay in theory. Norms, all-inclusive ah .... Ibm:jazz
Based on Jazz concert is very valuable in product function, after all, IBM carefully built. Unfortunately, it is not open source, more closed to foreign developers, implementation details can not see. In general, the application of OSGi is always on the premise of large investment. Emforge
In the rapid development phase, based on the JBPM 3 implementation of process processing, the design is worse, to achieve code quality under. However, there is a certain reference value. In particular, Spring integration JBPM, JSPWiki, etc. have the value of reference. JIRA
Very mature, to provide free support for open source projects. The process implementation is based on Osworkflow, but JIRA modifies a very large number of engine implementations to support its application, and there are a number of areas where functionality can be referenced. Mingle
Too closed for developers (after all, purely commercial, unlike Jazz's semi-closed ...). , but there is a lot to learn about Agile team support requirements. For workflow engine, language:
JBPM 3
No good design, as the implementation of customer code, designers can appreciate the bad APIs. From the code can be seen that the designer is basically modified, in the previous version of the reference to a lot of theory, later version (3.2.3) is basically a mas things, although proposed based on the graph programming model, but I think this is without any practical significance. is not a visual process design environment and execution engine. But, to be sure, the author gives the open source community a more stable choice. JBPM 4/PVM
is still in development, design more mature, at least exposed to the client code design of the APIs more reasonable. Unfortunately, the PVM is not as good as the author, JBoss, so feasible (fully compatible BPEL), only the author has the spectrum. From the present realization, the new JPDL is still the focus of PVM .... This version of the JPDL is really very good design, versatility is good (Java, Bean shell, SQL, etc), but the more support the better .... Ws-bpel/bpmn
Or that sentence, the norm is the norm. Although BPEL is primarily for service preparation, BPEL is perfectly capable of workflow and BPM from Sub-Process extensions, Humantask, and Bpel4people. Unfortunately, the expansion is a commercial realization, to be used well, money to keep up. BPMN 2.0 seems to solve the transformation problem to BPEL and I haven't had a chance to use it yet. Some solutions in China
Primeton Rapid development platform .... Can not afford, I only saw the design of workflow aspects, product designers do have a deep foundation, theoretical solid. But similar to the current concern is fireflow. Its thought and realization dare not compliment .... The author's application of Petri nets theory is problematic, at least not based on the "strict formal definition" as the author says, and there is a lot of research that separates "business" from "engine system" abroad. Petri nets can solve the problem, but to see how to use, if it is based on Petri nets, we must pay attention to the definition of concurrency, choice and implementation. Digression:
Portal implementation
Liferay is worth looking at the source code, integration is really very authentic, foreign applications are indeed worthy of our domestic developers to study well. Google
There are a lot of people who believe in research, and the recent GAE (Google App Engine) has been a big concern for Java developers who support Java. Google's stuff is really worth seeing, especially the design of APIs that are exposed to customers.