论工作流——没有权限的概念

　　工作流，在其存在的价值上主要是应对各种任务之间的信息传递，尤其是流程的各种启动、完成等信息。考虑到这一个问题上，一个很显而易见的是工作流没有权限的概念，所谓的权限，只是在业务处理上出现的信息控制而已。

　　看到各位网友徘徊于研究工作流组织和权限问题，感到不得不说，希望让一些刚对工作流入门的同行少走弯路。国内懂得这个的朋友都闭帚自珍，不太愿意开班授徒，学术风气之闭塞，实在令人感叹。那也只好让我这个水平不怎么样的，来一个抛砖引玉。

1. 纵横交错

　　国内所谓的工作流权限模型，一般是参考 RBAC，或者是树状的组织结构与角色的结合。

　　所谓的 RBAC，这个标准注意其设计的初衷是 security administration。注意这些权限标准，一般后面都带有这个 AC（Access Control），这种描述说明其设计的理念所在。这种模型一般用在网络操作系统上面，看到网上一些文章，把这种模型引入到工作流系统中，大概也是受了操作系统的影响。

　　还有就是一些文章，则采用了直接影射现实中的组织结构。这就形成了一种说法组织模型和权限结合的说法。但是这种组织结构呈现树状，那如果是横向的结构怎么办？一般就按照直观的概念，引入了"岗位"或者"角色"的概念。对于这种做法我不想多说，系统设计的个中高手，很快就能对这种结构下一个结论：抄袭需求，没有分析，直接实现。

2. 为何没有权限？

　　工作流，是一个主动发送的概念。就是一个工作任务，系统需要寻找到一个人，通知他去响应工作，是一个主动的概念。而基于角色或者组织结构的，一般是一种被动的概念，就是某人能够做一件事情，而另外一些人又不能做。

　　这样就有一个十分显然的差别：工作流中，是某人一定要做这件事情，而且这个人在工作的过程中系统不会再将这个工作分发给其他人，其他人也不可能在系统没有分配的情况下"抢"（这个"抢"，实际上就是 RBAC 中的 Access 的概念）到正在工作的任务。因此工作流没有权限问题，只有分发任务的目标问题。

3. 分发任务的一种设计

　　现在很显然，一切权限的问题，只是一个分发任务的问题。而分发任务只是一个瞬间动作，所以分发的目标，这一部分是可以很简单的完全独立于工作流引擎本身（如果在用 jbpm 或者 osworkflow 的，也应该能体会到这种设计）。这一点上和权限系统完全不同，权限必须渗透到系统的每一个可能的细节，很难完全独立出来。

　　那么分发任务，应该怎么找到目标呢？我们实践的答案是网状结构。这个网状结构的设计数学上可以表示为集合。如部门 Department 1 是一个可作为分发的目标，而分发需要通过这个 Department 1 找到其下属人员，那么我们可以说下属人员和这个 Department 1 有关联，记作 Department 1 = { 张三，李四，王五 }。有可能工作流分发中可能要找 Department 1 的主任，那怎么办？可以记作 Manager = { 张三，陈六，丁一 }，这样就有了集合 Department 1 ∩ Manager = { 张三 }，就找到了目标。

　　如果上下级的关系那怎么找呢？可以记作：销售部 = { 电话销售部，营业网点，网络直销部 }，实际上，如果在配置这些集合的时候，强制约定了每个部门只能重属于一个部门（数学上说法，就是任意两个部门的交集为空集），那么就是所谓的树型组织结构了。寻找上级部门，实际上就是寻找其所属的集合，而寻找下级部门，实际上就是寻找集合中的一个元素。

　　如果工作流的定义中，不存在一个关系的引用，那么就不需要建立集合。譬如说，网络直销部虽然和销售部的是上下级部门的关系，但是如果实际业务流程中，网络直销部不需要向上汇报的流程，销售部也没有下达命令的流程，那么分发目标的集合中，不需要反映两者之间的关系。

　　如果抛开实际的语言意义，在形而上的角度去观察，可以看出组织结构上的部门、执行操作的角色、工作任务上的岗位，实际上都是集合。在没有形而上的抽象分析，那么当这些不同的集合交集不为空集的时候，就会引出许多复杂的而且容易产生冲突的细节，在具体直观模型这个的这个层次上还要仔细推敲才能正确使用（通常是各种条件判断的代码充斥着开发人员的屏幕）。所以我们看到了一些实用这种方式描述系统的复杂性（就是纵向用树状表示组织结构，横向用角色表示 Access 权力的结构）。可以看出这种设计只能算是软件分析断层的产物而已（究竟是人才断层，还是意识断层，还是成本导致断层？这个又是一个值得反思的问题）。

　　至于集合方式的代码实现，就比较简单，我这里不再铺展。

4. 总结

　　可以看到，基于集合的表示，把工作流目标的分发高度抽象，能用最简单的概念解决几乎所有分发需求。软件的分析设计作用，就在这里显出了其威力。我们做技术出身的，需要注意不要被编码蒙蔽了眼睛：直观模型，只能应付特定需求；只有经过分析抽象的逻辑或者数学模型，才能使我们的代码拥有10年甚至更强的生命力。