基于状态驱动的反应流程引擎的设计又有新的发现

基于状态驱动的反馈流程引擎的设计又有新的发现


   刚刚思考到一个问题：关于JWFDv0.97反馈工作流引擎的设计问题

   我们如果设计反馈工作流系统，在状态驱动的引擎ARC算法里面如果加入跳转语句，那么这个运行过程中的流程就会出现一个奇异的现象

   当ARC算法工作的,节点运行到递归模块的时候,如果这个时候突然遇到一个有条件跳转语句,当递归算法与跳转算法同时出现，那么在系统内存里面就会出现两个相同的节点,好像是一个人被复制成两个人一样,但是哪一个节点才是我们需要的节点呢？  物理学里面有一个悖论-薛定谔猫，一只猫同时是死的，也是活的,那么这个悖论在我们设计工作流引擎的时候也遇到了，我想一下，应该给出一个推论性的结果：一个节点可以同时处在不同的状态中，并都具有在系统中存在的可能性,但是这些由同一个节点复制出来的节点可能会产生某种协同效果。。这个就需要我们进一步的思考了，由于递归和跳转而复制出来的同一个节点的不同拷贝是否具有竞争和合作的关系，那么设计出一套处理节点竞争和合作的关系的算法是否是我们处理反馈工作流引擎的关键

   在递归和反馈算法同时出现的时候，我们必须启动一套单一源多拷贝节点的竞争与合作的管理程序...哪个节点最终获得系统的资源,可能还需要一个比较复杂的计算过程...

  但是，竞争和合作的关系是肯定存在在这个设计思路中的....