说点我个人看法哈，一家之言，不一定准确，欢迎批评。
这个调度，我的理解还是根据一定的权限规则，以及流程定义，把工作流的报文按顺序传递给相关人员审阅，并兼顾异常事件查询等工作。
我觉得简单来说，就是根本不设计，系统不够大的时候，流程很简单的，数据库中一个顺序表就好了，server检索表，将文档按顺序走一遍就好了。
不过复杂来说，系统够大，流程够多，还是需要一点设计的，不过，这个设计，从开发角度上讲，最多是提供用户二次修改流程的手段而已，因为程序员永远没有办法替用户规定流程的。因此，还是不要设计，仅仅是把系统做活点，让用户可以自己规定流程就好了，比如前例，将表的修改权发放给某个管理员，或者做个界面，让管理员可以修改流程就好了。
当然，如果流程较为复杂，状态够多，仅仅利用表保存信令实现数据驱动，可能不好处理。另外，出于某些商业考虑，可能不希望用户自行掌握流程的制造方法，那就变成一次生意了，呵呵。
那也简单，server端规定一套流程录入的api，规定以某个脚本语言（如php）来书写流程模块，任何时候改流程，则请程序员按照api重新写一套流程代码就好了。
当然，出于降低维护成本起见，这个修订最好可以是远程的，这就用到npi了，就是规定一套网络接口，可以远程把流程模块登录到server上，server下次业务自动启用。
我想，只要能做到这几部，其实流程具体怎么规定，让用户去挠头吧，我们不要管，也管不好。
嗯，至于说到调度算法，可能有时候还有个效率考量，这个问题，我认为根本不是问题，server基于apache+mysql开发，使用脚本语言驱动，一般几千人的公司，都使用ie访问，应该不慢的。没必要为这个点单独做优化，实在要优化，也不要做程序优化，mysql里面建立几个事务，做几个index，可能效果更好。
有点类似游戏界里面的游戏控制脚本。
先做什么，满足什么条件，然后哪个场景上出现什么情况。
也可以乱序，场景仅仅检查n个条件是否满足，不关心满足顺序，这在RPG中比较常见。
这个调度，我的理解还是根据一定的权限规则，以及流程定义，把工作流的报文按顺序传递给相关人员审阅，并兼顾异常事件查询等工作。
我觉得简单来说，就是根本不设计，系统不够大的时候，流程很简单的，数据库中一个顺序表就好了，server检索表，将文档按顺序走一遍就好了。
不过复杂来说，系统够大，流程够多，还是需要一点设计的，不过，这个设计，从开发角度上讲，最多是提供用户二次修改流程的手段而已，因为程序员永远没有办法替用户规定流程的。因此，还是不要设计，仅仅是把系统做活点，让用户可以自己规定流程就好了，比如前例，将表的修改权发放给某个管理员，或者做个界面，让管理员可以修改流程就好了。
当然，如果流程较为复杂，状态够多，仅仅利用表保存信令实现数据驱动，可能不好处理。另外，出于某些商业考虑，可能不希望用户自行掌握流程的制造方法，那就变成一次生意了，呵呵。
那也简单，server端规定一套流程录入的api，规定以某个脚本语言（如php）来书写流程模块，任何时候改流程，则请程序员按照api重新写一套流程代码就好了。
当然，出于降低维护成本起见，这个修订最好可以是远程的，这就用到npi了，就是规定一套网络接口，可以远程把流程模块登录到server上，server下次业务自动启用。
我想，只要能做到这几部，其实流程具体怎么规定，让用户去挠头吧，我们不要管，也管不好。
嗯，至于说到调度算法，可能有时候还有个效率考量，这个问题，我认为根本不是问题，server基于apache+mysql开发，使用脚本语言驱动，一般几千人的公司，都使用ie访问，应该不慢的。没必要为这个点单独做优化，实在要优化，也不要做程序优化，mysql里面建立几个事务，做几个index，可能效果更好。
有点类似游戏界里面的游戏控制脚本。
先做什么，满足什么条件，然后哪个场景上出现什么情况。
也可以乱序，场景仅仅检查n个条件是否满足，不关心满足顺序，这在RPG中比较常见。
用脚本语言是个不错的选择。
本文转自 tonyxiaohome 51CTO博客，原文链接： http://blog.51cto.com/tonyxiaohome/198466，如需转载请自行联系原作者
