jBPM 4.4发布日期暂定于2010年6月4日

jbpm官方终于传来好消息，jBPM 4.4可能在下月初发布。以下是当前project leader的声明：

引用

We are down to 9 unresolved issues left before releasing 4.4. Given the current progress, it should be possible to release jBPM 4.4 on June 4th; the date is of course tentative and subject to change. Right now the only blocker issue is JBPM-2872: fix hudson db job. All others are deferrable if not completed on time.

If you feel like there is an issue that should not be left out, the time to bring it up is now. Visit the developers forum if you want to do so.

声明地址：http://community.jboss.org/thread/152282?tstart=0

简单来说，就是还剩下9个未处理事务，按当前进度应该可以在6月4日发布jBPM 4.4，其中最重要的问题是修正hudson下的db任务。最后向社区征集意见，如果谁感觉有啥issue应该在jbpm 4.4里解决的话，就赶快提出来撒。

jBPM 4.4的详细发布信息可以参考这里https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=10052&version=12314183，一共是75个issue，目前已解决66个。这个版本主要是进行bug fix，也提供了几个重量级的新功能。

1.解决嵌套fork/join每次嵌套会出现多余execution的问题。
2.任务超时或者手工执行signal后，自动删除过期task。
3.让sub-process的id和key都支持表达式。
4.支持在xml中声明变量。（还在讨论中）
5.在fork中使用assignmentHandler会抛出NullPointerException。

另外还有for-each动态fork分支这个功能，还在研究是不是要放在jbpm-4.4里，感兴趣的同志可以来官方论坛提出意见。
http://community.jboss.org/thread/152243?tstart=0

评论

26 楼 ffychina 2010-05-30  

对jbpm我是拿来主义的心态,更支持fireworkflow,支持nychen2000,支持国货,要有自己的优势,在核心技术上,不能被别人牵着鼻子走.

25 楼 stulance 2010-05-26  

很久没弄jbpm了，都忘了差不多了。那就从这个版本重新开始。

24 楼 evaspring 2010-05-26  

好敏感的日子啊 ~

23 楼 xyz20003 2010-05-25  

nychen2000 写道

关键看这个平台是否是松耦合，是否易于维护和扩展，是否足够开放。我们很多“平台”诸如普元的EOS，金蝶的bos，思维加速的产品都犯了上述毛病。这些产品的功能很多，但是就是没有人喜欢。

其实，我还觉得这些产品反映了我们的心态：就是封闭，自私，孤芳自赏，把所谓的“核心技术”当宝贝。如果真的有好的解决方案，只要Open一点，使大家都接受该方案，并成为事实的标准，那么还愁卖不出去吗？

恐怕没办法一次达到这种高度，以目前的形势，能基于开源引擎制作一套满足现实应用需求，再稍微灵活一些，容易配置的平台就不错了。

andrawu 写道

国内的流程的确是需要以上所的这些，如果拿现在的JBPM来用于国内的流程，所需要的工作还非常多，如果是本人要用JBPM的话，只会用他的引擎部分，在它的基础上进行扩展，单独在JBPM上进行应用很难达到客户的需求。

目前基本所有选择jbpm的公司都是使用引擎部分，然后自行扩展。从这点就可以看出来：1。jbpm的引擎很不错了。2。jbpm的外围做的太烂了。

nychen2000 写道

JBPM只是个工作流引擎（顶多加上流程建模），不是一个“平台”，如果jbpm做成了平台，那么这个产品早就死掉了，活不到现在。

jbpm目前虽然只有引擎做的最好，但是它的野心也不只是做一个引擎。red hat提供的soa解决方案就包含了jbpm。jbpm5的预期架构我就不再帖了，从那个图里大家也可以看出官方是什么意思。

22 楼 nychen2000 2010-05-25  

andrawu 写道

xyz20003 写道

comsci 写道

"
如果是这样的话，JBPM5对于一个国内的一般的应用性的小软件开发公司来讲是否太复杂了，开发成本和学习成本是否会变得越来越高？ 这就无形的增加了企业的成本？ 使得企业进入流程产品领域的门槛变高了？

从我接洽的客户来看，没有公司觉得流程方面功能太多了。反而，几乎所有的客户都希望流程不要只是一个引擎，他们还需要表单设计器，还需要用户管理和组织机构，还需要消息提醒，还需要报表统计。

对比一下，一个没有技术积累的小型公司，给它一个流程引擎好呢？还是给它一个业务平台好呢？

国内的流程的确是需要以上所的这些，如果拿现在的JBPM来用于国内的流程，所需要的工作还非常多，如果是本人要用JBPM的话，只会用他的引擎部分，在它的基础上进行扩展，单独在JBPM上进行应用很难达到客户的需求。

JBPM只是个工作流引擎（顶多加上流程建模），不是一个“平台”，如果jbpm做成了平台，那么这个产品早就死掉了，活不到现在。

21 楼 andrawu 2010-05-25  

xyz20003 写道

comsci 写道

"
如果是这样的话，JBPM5对于一个国内的一般的应用性的小软件开发公司来讲是否太复杂了，开发成本和学习成本是否会变得越来越高？ 这就无形的增加了企业的成本？ 使得企业进入流程产品领域的门槛变高了？

从我接洽的客户来看，没有公司觉得流程方面功能太多了。反而，几乎所有的客户都希望流程不要只是一个引擎，他们还需要表单设计器，还需要用户管理和组织机构，还需要消息提醒，还需要报表统计。

对比一下，一个没有技术积累的小型公司，给它一个流程引擎好呢？还是给它一个业务平台好呢？

国内的流程的确是需要以上所的这些，如果拿现在的JBPM来用于国内的流程，所需要的工作还非常多，如果是本人要用JBPM的话，只会用他的引擎部分，在它的基础上进行扩展，单独在JBPM上进行应用很难达到客户的需求。

20 楼 nychen2000 2010-05-25  

xyz20003 写道

comsci 写道

"
如果是这样的话，JBPM5对于一个国内的一般的应用性的小软件开发公司来讲是否太复杂了，开发成本和学习成本是否会变得越来越高？ 这就无形的增加了企业的成本？ 使得企业进入流程产品领域的门槛变高了？

从我接洽的客户来看，没有公司觉得流程方面功能太多了。反而，几乎所有的客户都希望流程不要只是一个引擎，他们还需要表单设计器，还需要用户管理和组织机构，还需要消息提醒，还需要报表统计。

对比一下，一个没有技术积累的小型公司，给它一个流程引擎好呢？还是给它一个业务平台好呢？

关键看这个平台是否是松耦合，是否易于维护和扩展，是否足够开放。我们很多“平台”诸如普元的EOS，金蝶的bos，思维加速的产品都犯了上述毛病。这些产品的功能很多，但是就是没有人喜欢。

其实，我还觉得这些产品反映了我们的心态：就是封闭，自私，孤芳自赏，把所谓的“核心技术”当宝贝。如果真的有好的解决方案，只要Open一点，使大家都接受该方案，并成为事实的标准，那么还愁卖不出去吗？

19 楼 xyz20003 2010-05-24  

haison 写道

    Tom Baeyens 和 Joram Barrez 新搞了个开源的Activiti,支持bpmn2.0,楼主怎么看bpmn2.0和bpel的未来的竞争？

http://www.iteye.com/topic/670385

这个帖子是聊activiti的，我感觉activiti最大的特点就是把hibernate换成了ibatis。

bpmn和bpel没有竞争关系，相反，600多页的bpmn-2.0规范里有相当大的一部分内容是介绍如何将bpmn-2.0转换为bpel。BPMN原意只是定义一套标准图形对流程进行定义，而BPEL则完全是以编程语言为基础设置的，bpmn处于设计阶段，bpel属于运行阶段。两者是互补的关系，虽然转换上肯定还会遇到诸多险阻，但是两者确实谈不上竞争。

反正我个人还是看好jbpm4的pvm，以后说不定有机会在pvm上把bpmn-2.0和bpel都实现出来，这样一架马车三匹骏马，爽啊。

18 楼 haison 2010-05-24  

    Tom Baeyens 和 Joram Barrez 新搞了个开源的Activiti,支持bpmn2.0,楼主怎么看bpmn2.0和bpel的未来的竞争？

17 楼 skzr.org 2010-05-24  

mlw2000 写道

严重建议避开6月4号

哈哈，和谐社会，社会和谐

16 楼 supercwg 2010-05-24  

注重每一小步，4.4，welcome！

15 楼 xyz20003 2010-05-24  

comsci 写道

"
如果是这样的话，JBPM5对于一个国内的一般的应用性的小软件开发公司来讲是否太复杂了，开发成本和学习成本是否会变得越来越高？ 这就无形的增加了企业的成本？ 使得企业进入流程产品领域的门槛变高了？

从我接洽的客户来看，没有公司觉得流程方面功能太多了。反而，几乎所有的客户都希望流程不要只是一个引擎，他们还需要表单设计器，还需要用户管理和组织机构，还需要消息提醒，还需要报表统计。

对比一下，一个没有技术积累的小型公司，给它一个流程引擎好呢？还是给它一个业务平台好呢？

14 楼 george_space 2010-05-24  

mlw2000 写道

严重建议避开6月4号

现在年轻人都不记得6月4号是什么日子了，所以无关紧要。

13 楼 comsci 2010-05-24  

"还有一点就是jbpm的附属设施太少了，单纯一个流程引擎是玩不大的，所以jbpm5才希望将WS-HumanTask，Report，BAM等巨型概念引入，估计是想搭上soa这趟车。但是我觉得太难了，从jbpm5里的规划看，随便拿出一块来就够做个一年半载的。 "

如果是这样的话，JBPM5对于一个国内的一般的应用性的小软件开发公司来讲是否太复杂了，开发成本和学习成本是否会变得越来越高？ 这就无形的增加了企业的成本？ 使得企业进入流程产品领域的门槛变高了？

12 楼 mlw2000 2010-05-24  

严重建议避开6月4号

11 楼 xyz20003 2010-05-24  

comsci 写道

另外一个感觉，JBPM走的路线和微软的WWF好像有点类似了，都是出一个大平台，然后让用户在这个平台里面做二次或者三次开发。。。。。不知道这个感觉对不对。。。

是的，pvm的野心很大，原本是希望通过pvm一举吃掉bpmn。可是根据前段时间在pvm上实现bpel的经验，感觉pvm还是太稚嫩，要想实现吞掉一切流程语言的目标，还有很长一段路需要走。

还有一点就是jbpm的附属设施太少了，单纯一个流程引擎是玩不大的，所以jbpm5才希望将WS-HumanTask，Report，BAM等巨型概念引入，估计是想搭上soa这趟车。但是我觉得太难了，从jbpm5里的规划看，随便拿出一块来就够做个一年半载的。

再贴一下jbpm5架构图

10 楼 comsci 2010-05-24  

另外一个感觉，JBPM走的路线和微软的WWF好像有点类似了，都是出一个大平台，然后让用户在这个平台里面做二次或者三次开发。。。。。不知道这个感觉对不对。。。

9 楼 xyz20003 2010-05-24  

whaosoft 写道

我估计差异又会很大...

版本升级需要注意两个地方。
1.org.jbpm.pvm.internal.model.Activity和Transition两个接口移动到org.jbpm.api.model包下。
2.jpdl中所有可以使用expr的属性，都从String类型变成了新的Expression类型。

8 楼 whaosoft 2010-05-24  

我估计差异又会很大...

7 楼 xyz20003 2010-05-24  

不太清楚呢，我一直认为开源是开发方式，与商业绝缘。

开源搞得再好，也只能把软件做得更好，一分钱也赚不到。想通过开源赚钱，那是商人去考虑的问题，已经通过开源社区创造出极具价值的产品，再考虑怎么把这个产品卖掉。只有在商业打算依靠开源赚钱的时候，开源和商业才会有融合点。凭兴趣搞开源的也不会去想赚钱，玩玩而已。咱们没必要硬把两者扭在一起。

所以，国外搞开源的才比较多，因为生存压力没有这么大。

说道开源软件卖钱，我还是认为便宜是它最大的优点。顺延下来的第二大优点就是代码开放，购买方不会有被胁迫的感觉，他会认为自己已经拥有了所有源代码，想改的时候，随便找个人来改改就行了（先不考虑是否能实现）。不会像闭源产品那样，有什么问题就一定要去找供应商。

因此，搞开源的，还是把技术和商业分开讨论比较好。聊技术就埋头搞技术。弄商业就专心想点子。混起来说就不明不白了。