在现有工作流引擎结构中加入反馈机制是否会引起混乱？

      如果我们的流程引擎是一个对流程图进行有序处理的系统，那么如果在这个系统里面加入有条件跳转的语句，在自动运行控制机制下，这种跳转行为与原有的递归算法共同作用，是否会引起整个流程运行控制机制的混乱呢？    我那天说的在程序里面增加有条件跳转 GOTO语句会大大增强程序的功能，这几天仔细想一下，如果出现类似这种情况，流程图原有的遍历次序被打破，那么是否会使得ARC对流程的控制失效？    存在这种疑问，所以我觉得需要从总体设计上重新考虑流程引擎的自动运行控制机制

      问题难就难在我们的引擎要全盘考虑整个流程的运行过程出现的每一个细节问题，好像设计一个发动机，连一颗螺丝钉的外形改变都会带来全局设计的改变(我猜的,说得不对， 请专家指正)。。。流程引擎的ARC系统也不例外。。。这个就有点考水平了。。

     那我们就让ARC遍历一次，准备递归的时候，如果遇到一次反馈行为，那么ARC对于其它节点的遍历次序是否会发生错误呢？反馈行为发生在递归之前，递归之后，或者正在递归的时候，分别会出现什么情况呢？那么我们不管这些  先在ARC里面加入一个判断条件模块  在ARC模块中嵌入jumper()，然后运行流程，测试一下看看流程运行的时候，出现反馈行为并调用jumper是否会引起ARC的控制错误，实践是检验技术的关键手段，让我们先行先试吧。。作为一个工作流技术爱好者的实验平台,JWFD就扮演着技术和理论测试的角色，行不行，好不好，试过再说。。。

     ================================================================================================================================

一个工作流系统是否能够卖个好价钱，关键就在核心系统里面。。现在市场上的流程产品越来越多，同质化也很严重，竞争是否胜出的关键还是在于核心技术方面，所以企业有必要加大在这方面的投入力度，我建议企业和大专院校和研究机构进行密切合作，避免从代码里面来再到代码里面去，没有理论上的支持，代码的设计水平难以提高，这点我很有体会。。。国内的天翔工作流就开始和研究机构进行合作，真是不错。。。期待他们的产品越做越有水平。。。。。。