AgileFlow的业务persistence设计

经过总结以前的开发教训和经验,在实际环境中测试后,准备把agileflow的持久层设计如下:
<agile>
   <流程定义号1>
          <流程实例号>
             <字段1>""</字段1>
             <字段2>""</字段2>
             <字段3>""</字段3>
             <字段4>""</字段4>
          </流程实例号>
          <流程实例号>
             <字段1>""</字段1>
             <字段2>""</字段2>
             <字段3>""</字段3>
             <字段4>""</字段4>
          </流程实例号>
   <流程定义号1>
   <流程定义号2>
          <流程实例号>
             <字段1>""</字段1>
             <字段2>""</字段2>
             <字段3>""</字段3>
             <字段4>""</字段4>
          </流程实例号>
          <流程实例号>
             <字段1>""</字段1>
             <字段2>""</字段2>
             <字段3>""</字段3>
             <字段4>""</字段4>
          </流程实例号>
   <流程定义号2>  
</agile>
说明如下:
1)这样的设计可以保证业务流程的热升级特性,伴随工作流引擎的热升级,用户的应用系统也
就可以热升级了
2)这样的设计可以保证快速开发应用系统
3)结合agileflow 0.9版的common组件集中的SelectionHelper组件,用户不用考虑应用系统的
流程运转部分的数据库设计问题;当然,查询和报表部分还是建议采用数据库作为持久层
4)我考虑过把字段的element改为attribute,但发现那样更加占内存空间
5)这里是考虑一个流程一个表的模式,当然,一个活动一个表也是可以的,但在权衡后,发现没有
一个流程一个表的模式好
6)一个字段一个表的模式可以考虑在采用数据库方式时使用,但用文件方式肯定不会采用它
7)为了方便处理,在定义字段时,还是应该按活动分开,可以考虑在流程定义的Node定义中定义
业务数据,这样在完成活动时方便处理
8)这样的设计,可以使得AgileFlow转变为一个BPM系统
9)AgileFlow的未来,不仅仅是个工作流引擎,它还是个工作流应用系统和bpm系统的开发框架,它
的目标是方便用户的快速开发,并且保证架构的灵活,可扩展,易测试
10)工作流引擎在AgileFlow中将是可插拔的,Agile是可选的一个工作流引擎,还可以选择Shark,
osworkflow,jbpm等其它的工作流引擎,用户不需要修改任何的代码就可以切换工作流引擎