反馈行为与设计动态流程引擎的一些思考

    有朋友问，你为什么要写那么多废话呢？ 

    这里我要说明的一点是，我写的这些有些的确是废话，但是如果没有这些废话，那代码也无法形成，因为代码实际上是人思想的体现，我动手写代码之前，首先要在脑海中把代码的基本架构构思出来，就好像一个作者在写小说一样，都有一个构思的过程，没有这个过程，文章或者代码都不会成形的，所以请原谅我要写那么多博文来阐述我的思想，另外，很多用开源的朋友其实并不怎么爱看开源软件的代码和文档的，基本上都是一来就引用JAR包，然后写几句调用函数，就希望很快看到应用开源软件的成果，如果没有达到效果，马上就把程序仍到硬盘的某个角落去了，所以在开发程序之前，我觉得还是有必要把自己的设计思路描述一下，让大家心里有个数，知道我在想什么，准备做什么，如果不感兴趣，就可以转身就走，免得浪费各位的时间了。。。我这些东西，一不赚钱，二不赚利，纯粹属于自娱自乐性质，嘿嘿。。。。。

     废话说完了，哈哈---------------------------------------------------------------------------------------------------------

  如果流程在运行过程中，出现因为数据处理而导致的反馈行为(也可以叫有条件的多步回退行为，但是反馈这个词汇的意义更加广泛一些)，那么流程的自动运行控制器的设计需要做一些调整，怎么调整呢？

   一个流程的某个节点有数据处理功能模块，当这个节点被激活之后，数据处理任务完成，向下一个节点输出处理结果，这个时候如果下一个节点检测到上一个节点的处理结果不符合要求，那么就会发出一个信号，让前一个节点回退到初始状态，重新进行数据处理，这个反馈过程对于处于总体控制层次的ARC(自动运行控制器)而言是需要内置处理模块的，因为如果流程的节点比较多，拓扑结构比较复杂，那么同时出现反馈行为的节点或者节点群肯定不止一个。。。如何保证流程的整体运行控制不因为几个节点的反馈行为而出现紊乱，还是一个比较麻烦的问题。。我在JWFDV0.96的SAN自动运行控制器算法中并没有考虑到这一点，但是这个问题肯定是无法回避的，因为我们做的流程管理系统肯定会面临越来越复杂的应用情况。。。

  

    一个流程图中，绝大多数情况下，，都会出现既有并行节点群，又有串行节点群的复杂拓扑结构，每种节点群类型都有自己独特的数据处理行为，并行节点群在进行数据处理的过程中，还存在一个汇聚的过程，既多个并行的节点同时进行数据处理，然后要把处理结果汇聚到某个单一节点上面去，如果这个并行节点群中某个节点路径出现反馈行为，那么汇聚节点就必须等待，那这个等待过程一出现，是否就意味着整个流程的运行速度会发生变化呢？ 这个好像有点类似于并行计算的一些问题。。。也有点像操作系统进程管理的一些问题。。。。

     那么流程引擎对于这些问题该如何处理呢？  是否需要设计一个复杂的，类似于操作系统内核的那种流程引擎呢？       难以想象一个工作流系统要用一张DVD才能够装下的情景。。。多么令人不爽啊。。。。多怀念一张1.44M软盘就可以装下全部DOS3.3系统的时代。。。。。。。。。

    流程的节点越来越多，拓扑结构越来越复杂，就好像操作系统上面装的应用软件越来越多，内存里面的进程越来越多，系统臃肿，复杂，难以管理，蓝屏的情况经常发生，然后补丁一个接一个，这难道是工作流系统的未来吗？

    该用什么方式来设计工作流的内核呢？  除了总线模型，还有什么样的结构可以很好的处理这些未来面临的困境呢？   处理器的资源是有限的，内存空间也是有限的，但是流程图的节点和连接数是可以趋近于无限的，哎。。。怎么在有限的资源环境下，实现最大限度的拓扑计算能力呢？    我们的大脑是怎么做的呢？  

     要管理数量众多的节点群，数量众多的节点间连接，还要让流程在运行过程中保证流程整体运行的协调性，不断的有反馈行为的发生，不断的有节点被丢弃，不断的有连接线被改变，这个动态的流程，真像我们的神经网络啊。。。那么我们生物是用一种什么机制来调控那么复杂的神经网络的运行的呢？   我们设计的流程引擎是否也需要一种这样的机制来调控日益复杂和动态化的流程呢？？？？