D 的个人博客

关于软件过程、或者是软件生存周期领域内的工作流、过程规范、产品研究了差不多半年时间了。研究的主要是开源、开放、业界标准相关，有点肤浅的心得，概要如下 :-)　

对软件过程支持环境而言：

• Eclipse: EPF
  比较成型的社区规模，没有深入研究。不过感觉 eclipse 下面的东西基本是比较难用的，而且社区开发进度令人担忧。
• OMG: SPEM
  规范就是规范，也只是规范。SPEM 的实现比较罕见，国内研究非常少，貌似中科院有个实现。国外关注也比较少，仍停留在理论上。规范，大而全啊....
• IBM: Jazz
  基于 Jazz 的 Concert 在产品功能上非常有参考价值，终归是 IBM 精心打造的。可惜的是不是开源的，对外来开发者比较封闭，实现细节看不到。总的说OSGi 的应用目前总是在大投入的前提下才能做的。
• EmForge
  处于快速开发阶段，基于 jBPM 3 实现的流程处理，设计比较糟糕，实现代码质量底下。不过有一定的参考价值。特别是 Spring 整合 jBPM、JSPWiki 等有借鉴的价值。
• JIRA
  非常成熟了，对开源项目提供免费支持。流程实现基于 OSWorkflow，不过 JIRA 修改了非常多的引擎实现，以支持其应用，在功能有很多可以参考的地方。
• mingle
  对于开发人员来说过于封闭（毕竟是纯商业性质，不像 Jazz 的半封闭....），不过对于敏捷团队支持需求有非常值得学习的地方。

• jBPM 3
  没有好的设计，作为客户代码的实现、设计者可以体会到其 APIs 的糟糕。从代码上可以看出设计者基本是修修改改，在前期版本上参考了非常多的理论，后期版本（3.2.3）基本是个四不象的东西，虽然提出了基于图的编程模型，但我认为这个是没有任何实际意义的。不就是个可视化流程设计环境与执行引擎么？但是，可以肯定的是作者让开源社区多了一种稳定的选择。
• jBPM 4 / PVM
  目前还在开发中，设计上比较成熟了，至少暴露给客户代码的 APIs 设计上比较合理了。可惜，PVM 是不是像作者、JBoss 吹得那样好，那样可行（全面兼容 BPEL），只有作者才有谱。从目前的实现上看，全新的 jPDL 仍然是 PVM 的重点.... 这个版本的 jPDL 确实设计非常优秀，通用性很好（Java、Bean shell、SQL、etc），但是，支持越多越好？？？？
• WS-BPEL / BPMN
  还是那句话，规范就是规范。虽然 BPEL 主要针对的是服务编制，但从 sub-process 扩展、HumanTask、BPEL4People 上看，BPEL 是完全可以胜任工作流、BPM 的。可惜，扩展都是商业实现，要用得爽，钱跟上。BPMN 2.0 貌似是解决了到 BPEL 的变换问题，我还没有机会使用。
• 国内的一些解决方案
  普元快速开发平台....买不起，我只看了工作流方面的设计，产品设计者确实功底深厚，理论扎实。不过类似目前比较惹人关注的是 fireflow 。其思想与实现不敢恭维....作者对 Petri 网理论的运用是有问题的，至少不是像作者说的那样基于“严格的形式化定义”，而且国外类似将“业务”与“引擎系统”分开的研究很多....Petri 网是可以解决问题，但要看怎么用了，如果是基于 Petri 网，一定要注意并发、选择的定义与实现。

• 门户实现
  Liferay 是值得看看源代码的，整合确实非常正宗，国外的应用确实值得我们国内开发者好好学习。
• Google
  相信研究的人不少，最近的 GAE（Google App Engine）对支持 Java 更是引起了我们这些 Java 开发人员对它的关注。Google 下的东西确实是值得看看，特别是暴露给客户的 APIs 的设计。