引擎对工作流图拓扑结构的识别能力很重要

   要工作流引擎要自动处理一个流程，正确的按照预设的路径和次序访问流程的各个节点，首先要让流程引擎能够正确的识别流程图的拓扑结构，由于嵌套分支和并行选择拓扑结构的出现，使用者应用流程设计器设计出的流程图必然充满着各种各样的复杂拓扑结构，对于这个问题，我在开发jwfdv0.96版本的流程自动运行控制器的时候就感到有点困惑，当时仍然是沿用v0.94版本中的自动运行控制器的模式，通过增加for循环来同步处理并行节点，但是直到现在，这种模式始终没有跳出遇到复杂拓扑结构就增加一段代码的方法，如果流程图再复杂，自动运行控制器的代码就会更加复杂，而且自动运行控制器无法分解，导致最后形成代码量巨大的大函数，结构比较混乱，二次开发者不容易读懂，更加不易扩展的若干困境。。。

  这就是为什么我要坚持寻找新的方法来设计工作流引擎，这里我要说明一点的是，无论国外，还是国内，对于工作流引擎都没有一个标准的定义，并不是说非得要按照某个标准开发出来的工作流引擎才叫工作流引擎，不按照这种标准来设计代码，就不能够叫工作流引擎，我在jwfd开源工作流系统中把workflowEngines.Algorithm.TopologyAnalysis.java类中的SAN函数所表示的工作流自动运行控制器模块称为工作流引擎，是出于我对工作流自动控制的一种爱好，和国外的开源和商业软件对于工作流引擎的观点并不一样，所以这里需要澄清一下，免得某些马甲同志一看到我设计的工作流引擎就像看到牛肉汉堡里面有马肉似的。。。。

  回到主题来，在前面的文章中，我提出应用硬件的总线模式来设计工作流引擎，其目的就是为了解决上面出现的问题，那么要深入下去，我们还得从最基本的对工作流拓扑结构的识别和遍历入手，来找出解决问题的办法。。。。

  如果仅仅从节点和节点连接线这两点来识别流程拓扑结构，会失去对流程图整体结构的识别能力，甚至可以这样说，一个实际流程的第N个节点与第N+M个节点无论是否直接连接，都存在一定的互动关系，要能够正确识别工作流图，除了在节点和连接线这个层次做到识别正确之外，还需要在整体上能够识别出这些虽然不直接连接，但是却存在互动关系的节点(节点群)，那么我们也许就需要分几个层次和几个角度对流程图进行识别。。。。

  第一个层次，也是最基本的层次，既流程图有多少个节点，每个节点的直接前驱点和直接后续点，流程图的起始节点和结束节点
 
  第二次层次：要能够正确的识别出成对的流程节点及其拓扑关系，比如说哪个分支点与哪个汇聚点成对出现，哪几路分支是并行的，哪几组节点连接线源自同一节点等拓扑匹配关系

  第三个层次：由于节点与连接线中嵌入有代码和公式，使得不直接连接的节点之间通过流程公有变量和其它业务数据互相产生了关系，对于这些由于数据而发生联系的节点，也要正确的识别出。。。而且这种关系是动态的，会因为数据和运算结果的变化而发生变化，所以这个层次的识别难度就比较大。。。

  另外，还有其他一些在数据流与控制流之间出现的动态匹配关系也需要引擎能够识别出来。。。这个方面还值得我们大家多多思考。。。

  网络论坛是个开放的地方，所谓开放就是指一切可能的语言都会出现。相信大家能够分辨出什么人是真正在讨论技术问题。。。。