转自：http://www.guodanpi.com/zblog/post/23.html
继续工作流的学习和开发工作。
继续研究Powerstone，继续思考，继续做一些自己的数据库设计。越深入一点Powerstone的设计，越觉得他确实设计得非常不错，考虑到了很多东西，也实现得不错，今天再度请教了作者daquan关于节点中为什么要bind数据的问题，答案让我一下茅塞顿开，非常感谢！但是个人还是觉得是否有必要，所以当前的设计暂时没有加入这方面的考虑。
初步的设计可以看这里(pdm文档没法下载，呵呵，jpg查看)。图片如下所示：
大致的定义流程如下：
1． 首先定义工作流（只是名称、是否发布等简单属性，主要是获取一个id）
2． 设置该工作流存在的状态
1) （设定参与者，这里打算直接通过Group:32;Role:98等这种方式处理，详细的处理将交给用户角色模块，可返回参与者的user集合）
2) 设定前驱进入规则：主要是通过定义的“工作流规则”，将“聚合、顺序、and、xor、or、投票”等一系列的规则放入工作流规则中统一处理（处理工作流规则将是一项艰巨的工作，所以感觉表[工作流规则]的设计还需要考虑。
3) 是结束状态：个人觉得结束状态是比较特殊的状态，应该不需要每个工作流都需要定义，可以公用，但是暂时还是每个工作流都定义这样的状态好处理（还没想到更好的办法）
4) 是否开始状态：开始状态同样很特殊，实际上在将事件放入到工作流时就已经开始，这时候主要需要的可能就是能够使该事件进入工作流的参与者的定义。
3． 设定个状态间的路由：也就是各状态间的连线
1) 指定[从状态]和[到状态]，
2) 指定[从状态]到[到状态]的使用规则：比如说明在一个从状态存在多个后续状态时，是否选择该路由的规则。
3) 定义业务是否可主动选择参与者的具体用户：由于参与者存在多个用户的情况，所以存在两种需要考虑的状况a.参与者中某个具体的[人]主动请求任务，b.在定义业务可主动选择参与者的情况下，可以让业务指定参与者中的具体的[人]。
感觉工作流引擎纯粹的定义好像就是这么简单（当然现在我仍然在是否需要在状态中绑定数据上犹豫，虽然在状态中绑定数据是wfmc已经说明了的），但是我现在的考虑在下面将会提到。
对应与纯粹的工作流定义，需要“事件”的参与，这里面定义为“工作流实体”
4． 设定工作流实体：指定实体id，实体类别，选取的工作流，当前在工作流中的状态信息
5． [实体在工作流中状态]将由工作流引擎驱动并生成数据
6． 用户驱动生成[用户参与记录]，或由业务驱动主动生成[用户参与记录]
到现在为止，关于数据和工作流的关联关系已经建立，业务端可以完全可以通过上面的工作流引擎提供的接口来对“实体”进行操作，但是我觉得powerstone中采用url来驱动的设计非常好，引用之，呵呵
7． 定义外部业务web应用
8． 定义web具体的url
9． 定义url与工作流每一步状态的关系，从而可以从当前状态获取需要交互的url信息。
大致上的数据库如此，需要继续研究和讨论，做个记号先！
