EOS工作流引擎工作原理（三）

8. EOS 引擎的精彩之处

　　EOS 引擎设计上最精彩的地方应该是基于多线程的事件调度机制，在事件处理是下层有个线程池处理事件，其中有个线程拿到了一个事件后就开始他的 事件的发布和事件的迁移。（多线程协同工作的程序设计我觉得应该是程序设计中最复杂的地方，不但要屏弃所谓“ 万物皆是对象” 的看法，可能还需要用到大量的 goto 语句来解决一个面向对象这种思想不好解决的问题，还有在JAVA 中线程的调度可能还依赖于程序所跑的操作系统和硬件环境，有很多的不可预料性的存 在。我怀疑这个线程池肯定有问题，或者单线程已经足够解决所有问题，不然EOS 引擎为什么不把多线程处理事件作为默认的处理方式而是单线程作为默认的 呢？）

  多线程调度的初始化：引擎根据配置文件（wfconfig.xml ）里的线程数（event_thread_num ）新建了那么多数量的线程。 l 并把这些线程放到已经定义好的线程组里。这些线程对象有个对象属性：EventList ，这里装载的是该线程该处理的所有事件对象。然后把这些线程都 start() ；该线程轮询EventList 里的事件对象列表，如果对象列表为空则把自己阻塞（wait() ），如果有事件对象则取第一个事件然后发布 该事件，对该事件的处理还是和单线程是一样的。

　　线程池对客户端动作的响应：客户要向引擎发布一个事件首先找到线程组的activeCount ，然后根据取得的数量在新建这么多的线程然后 enumerate （复制到线程组中）它们。引擎把这些线程对象转换成事件处理线程（EventThread ），然后遍历这些线程，然后根据“ 找到这些线 程对象中的EventList 里的事件最少的一个线程“ 这种策略，把要发布的事件对象加到找到的这个线程对象的EventList 里，同时唤醒这个线程， 完成了一次事件的发布，完成了线程自己和自己的协同工作。

9. EOS 引擎的不足

9.1.  组织机构模型

　　EOS 提供的组织机构模型无法解决按岗位或按行政级别分派工作项。但这是很常见的一种情景（安徽二期的工作流平台好象实现了按行政级别来提交工作项）。网上有一种比较流行的组织机构的模型。

　　如果能把这种组织机构模型经演化应用到引擎中去可能会解决按岗位，按行政级别，按职务来设参与人的问题，甚至可以解决一个机构只有一个流程的问 题而不是机构的下属机构拥有一套和其他下属机构一样的流程（只是参与人不同而已）。而我们的应用中只需要一套共性的流程和下属机构个性化流程的实施。由于 客户在管理可能会有不足或把依靠系统来管理，而我们希望我们系统的不足能在管理上弥补，所以能在这中间达到一种平衡需要找到这中间的平衡点。

9.2.  不能应用在分布式系统中

　　由于在引擎启动的时候引擎把流程定义XML 文解析成流程定义对象，然后加载到内存中，而发布流程的动作只能来自一台集群节点，固无法把修改后的 流程定义同步到其他的集群节点。现在的同步方法是发布流程的时候同时调用其他节点的一个远程方法来实现同步。虽然通过外挂式的解决方案解决了这个问题但没 有从根本弥补引擎的缺陷。

　　EOS 的业务字典的管理也是存在同样的缓存问题，在一个节点建了一个业务字典没办法同步到其他节点中去。

　　环节的时限也是用了缓存，一个环节的时限注册是在环节启动时如果定义了时限则向时限服务注册，并在内存中产生一个时限对象，有个后台线程在维护 它，当环节结束时取消该环节的注册，移除该环节在内存中的时限对象并删除数据库中的时限表的那条数据。 有一种极端的场景（不可能发生）：所有的用户在结束自己的环节后启动了下一个环节（假设该环节的完成时限为一个月）。这个动作是在节点A 进行的，则节点A 的内存中有了所有下个环节的时限对象。节点A 的后台线程在维护该对象，不停的判断是否超时。假设下个环节的所有用户在没有超时的情况下完成自己的工作项， 并且操作的发生在节点B ，用户操作自己的环节后结束环节并取消时限注册并删除时限表，但节点A 的时限对象并没有移除。节点A 的后台线程一直在维护着它直到 它超时才从内存中删除，造成了内存里的垃圾数据．

　　我认为引擎层还是应该有一个类似缓存同步服务（可能我说的不对），譬如在流程未发布和发布成功的状态位的迁移过程中加一个待发布的状态，当发布 流程的时候把该流程定义的发布状态定义为待发布，然后有两个线程协同工作，一个线程定时（譬如20S ）来轮询待发布的流程定义并加载到一个待发布流程列表 （该列表类似操作系统中的信号量）中，如果该列表非空则唤醒另一个流程发布线程，该线程sleep 一定的时间（该时间要大于等于轮询的时间保证所有节点都 已经把待发布的流程定义都加载到内存中）后发布该流程并把流程置为发布状态，然后将自己阻塞。

9.3.  子流程的设计

　　EOS 的子流程是作为一个主流程的环节来实现的，我觉得不应该有子流程和父流程的概念，也不应该把一个流程作为一个环节来实现。流程与流程之间 的通信可以已一定的接口定义和通信规则来实现，父子关系只是其中的一种（属于工作流协同工作的网状模型），还有链状模型，端到端的模型，并行同步模型。这 样如果有了接口的标准既解决了父子关系的流程通信，同时也解决了EOS 工作流不同实例的交叉操作，甚至解决了不同工作流产品之间的流程通信（只要遵循了接 口定义标准，该接口为WFMC 定义的接口4 ，该接口定义了一系列的互操作层次（好象是8 个），但可能并不能满足像EOS 的引擎具有中国特色（譬如自由流， 抄送…… ）工作流需求）。