D 的个人博客

但行好事莫问前程

  menu
417 文章
3446695 浏览
11 当前访客
ღゝ◡╹)ノ❤️

软件生存周期过程相关产品与规范的调研

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

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

  • 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 的设计。