Fire workflow近期开发计划

根据前期网友的意见和建议，整理了一下Fire workflow近期的开发计划。欢迎继续提意见。

1、将IOC容器作为一个服务，缺省调用spring的IOC容器
    在预览版本中，Application handler、EventListener的实例化都是RuntimeContext负责的，实现的比较简单，估计也不是很稳定。应该将这些工作委派给IOC容器，缺省采用Spring容器，业务系统可以将该容器替换成任何其他容器；或者自己创建一个简单的实现类，在该类中直接根据Application handler的类名创建实例亦可。

2、在WorkItem中增加withdraw方法，实现“取回”功能
    增加withdraw支持取回功能。当然取回是有条件的，我觉得太复杂的情况下的取回（比如、事务补偿、回滚等） 完全没有必要。Fire workflow取回遵守如下约束
     a）当前Activity和下一个Activity在同一条执行线上
     b) 下一个Activity只有Form类型的Task,没有Tool类型和Subflow类型的Task
     c) 下一个环节的所有WorkItem还没有被签收，都处于Initialized状态，
    如果在本WorkItem成功执行了jumpTo操作或者loopTo操作，只要满足上述条件，也可以成功执行withdraw。

3、WorkItem废除sign方法,用claim方法替代
    由于英文能力不咋地，“签收”一词一直找不到好的英文单词，最近在看BPEL4People时发现了一个恰当的单词“claim”。所以用claim替换sign，功能不变

4、加强异常的指向性
    EngineException和KenelException需要指明哪个流程实例，在哪个环节出了异常。

5、完善DefinitionService4DBMS

6、优化IPersistenceService接口，增加类似QBE的查询；增加对流程历史表的处理
    增强PersistenceService查询接口的灵活性，目前的接口方法定义的比较死，不能灵活扩展查询条件，会借鉴QBE的设计方案。
    历史表存储办结 的流程实例信息，以提高系统性能，同时在PersistenceService中增加对历史表的查询支持。

7、流程性能优化

8、toolTask去掉同步和异步属性，该属性没有必要。

9、增加While Activity
    增加循环类型的Activity,试图解决多级审批且审批级数不确定的流程场景。

10、将Task作为Workflow的直属子节点，方便流程重组