大家讨论一下jbpm的功能还有哪些有待于封装，使的二次开发人员可以更加快速方便的应用。我先把我想到的功能都写出来。
1.扩展组织引擎，支持用户自定义组织关系。
2.提供强大的分派策略，让流程的任务分派更加灵活。(比如任务审批人和申请人是同一人时需要跳过还是默认通过还是执行该节点，若两个审批人都时同一人的话在什么条件下需要跳过，什么条件下为必须再次审批)。
3.流程监控功能强化，需要在流程图中可以看出申请节点，审批节点，当前节点，跳过节点，取消节点等等状态。
4.后继路由边transition支持变量判断  

5.如何与应用更好的关联而尽量提高效率问题。
6.关于会签时通过人数或百分比选择节点的出边选择问题。
7.邮件功能在什么时候添加最合适。
8.首节点是否自动执行问题。（我们测试时一般首节点都需要手动执行，因为要设置流程变量，而当工作流嵌入到其他系统时首节点时自动执行的，如何通过配置而不是写代码的方式使程序更加具有java的继承优点）。
9.对于任务代理人以及其表现方式。(属于组织引擎范畴，但是比较特殊)
我能想到的和解决的也就这些，大家都说说，把jbpm的功能封的更加强大一下。

                                                                                                                                      W.P.A

第二点的范围很大.还包括退回到前面经过的节点,申请人主动撤回等.

jpdl是一个很灵活的语言,符合老外喜欢DIY的风格.但是设计工具的支持太弱了.

这些策略其实在jbpm中都可以实现,但是都要自己写代码.如果在jpdl designer中选一选,配置一下就搞定就理想了,因为国内的项目开发不允许每个人都把jbpm研究的那么明白.

第二点通过jbpm设计工具配置好像不是很方便啊，这些功能可以做成统一的接口，图形化之后就可以了，象youngliuus说的退回功能，可以把前面已经执行过的节点都列出来，然后让客户自己选择把任务驳回到哪个任务节点（这个只考虑了简单的任务，如果存在并行任务等复杂情况时就比较麻烦了）。申请人主动撤回这个功能就是申请人取消流程。

岂止是"不是很方便",简直是"很不方便",呵呵.
 
  像分配策略这样的东西,我认为是"设计时"可以决定的. 所以我认为理想的方式是将这些策略作为流程定义或任务节点的扩展属性记录在流程定义中.
  定义TaskNode的子类(我更喜欢使用自定义的event handler,因为这符合AOP的思想),在创建taskInstance时或某个任务完成时,根据流程定义中的"策略",决定如何处理.
 
   而像我说的退回和撤回,这样外部干涉性的操作,的确需要定义一套api来操作. 而且也可能会需要在流程定义中有策略的支持. 比如哪些任务节点可以做退回操作,这更应该是设计时决定的.