[原创]工作流自适应引擎的设计思想(初步)
最近一段时间都在思考这样一个问题：如果我们想让一个工作流引擎能够妥善的处理由用户通过流程设计器设计出来的任意复杂(简单)的流程图，那么对这个工作流引擎的结构设计就必须很灵活，因为如果仅仅依靠一个有限规模的类与方法集合体，我们不太容易很好的处理所有可能遇到的流程图，但是经过我在JWFDv0.94-v0.96这几个版本的流程引擎设计过程中，我发现了一个潜在的，有可能比较好的解决上述问题的方法，现在我就描述一下这个方法的思想，请大家来讨论
首先我简单的描述下JWFD的引擎设计的思路，
v0.94 的引擎是这样的结构：
流程数据结构的SQL操作集合+自定义广度优先遍历控制器
v0.96 的引擎是这样的结构：
流程数据结构的SQL操作集合(增强)+流程图拓扑结构算法(初级)+自定义图遍历控制器
我解释下为什么v0.94版本要用广度优先的图遍历控制器,因为广度优先对于流程图的遍历来讲可以先把并行的分支遍历完之后，再继续往深度方向上面遍历，这样有利于对具有并行分支结构的流程图进行遍历，但是在实际的应用中，对于需要同步处理的并行流程图的并行分支的遍历仅仅靠广度优先算法是不够的，经过朋友们的反馈和我在工作实践中遇到的情况，在v0.96版本中我把遍历控制器部分进行完全的重写。
由于v0.96版本引入了基于antlr的嵌入式的计算公式模块，导致流程引擎中出现了动态的K值问题(请参考博客文章 [原创]JWFD工作流引擎设计----节点匹配搜索算法 (用于初步解决条件异步汇聚问题) 补充 http://comsci.iteye.com/blog/502102),为解决这个问题，我设计了匹配节点搜索算法,这个算法就是v0.96版本引擎的流程图拓扑结构算法的来历,但是拓扑结构算法并不仅仅只包括匹配节点搜索这一种算法,我的想法是流程引擎中用于处理图的拓扑结构的算法类是一个算法集合体，我们可以根据具体的应用和设计来对这个算法集合体进行灵活的增加和修改......
同样具有这样的灵活的特征的是在v0.94版本中出现的流程数据结构的SQL操作集合,由于流程图的数据库结构是变化的,我们随时会因为产品和应用的需求不同而修改流程的数据结构，那么这个SQL操作集合也会同步的增加，修改。所以比较起v0.94版本，v0.96版本的这个SQL操作集合类就增加了不少方法,(请参考 JWFD v0.96 工作流开发包 for eclipse org.jwfd.workflowDesigner.UItools.Database.mysql.FlowsSqlControlModule 下载地址 www.xcomsci.cn)
这样一来我们看到流程引擎的结构大至就分为三个模块,其中前两个模块(sql操作集合,拓扑算法集合)是模块化的，灵活的，可变动的(通过人工来添加，修改，删除),但是第三个部分,也是最核心的部分-遍历控制器却是静态的,是非结构化的，我在v0.96的SAN算法中曾经尝试尽可能的把这个遍历算法模块化，通过划分为若干个小的模块并且对这些模块进行组合来实现遍历算法模块的整体结构，但是这个尝试并不是很成功，因为我当时并没有找到一个对遍历控制器可以完全模块化的办法，仅仅只是对遍历控制器中部分方法进行了封装，当然这也使遍历控制器的代码结构变得相对的简单和明了些
后来经过一段时间的思考,我发现一个方法，对于用户自定义的流程图的拓扑结构这一灵活的结构数据，我们是否可以采用被我称为"遍历识别流程图-自动代码生成"的技术来让系统自动生成这个遍历控制器，这个技术的核心思路就是来自于上一段我描述的遍历控制器的整体结构的静态编程性与自定义流程图拓扑结构的动态灵活性之间的矛盾，这个控制器是我们程序员通过键盘手工编写的，是静态的，非自动化的，而我们需要的是一种动态的，能够自适应用户自定义流程拓扑的这样一个软控制器,这个软控制器如果能够由系统根据用户定义的流程图的拓扑结构来自动生成的话，那么困扰我们的流程运行控制的关键问题(当时这只是流程运行控制的一个问题)就能够得到一定程度的解决,这个设想现在还处于非常初级的阶段，很多地方都不明确，也不具有立即可实现性，但是却是我认为解决灵活的流程图运行控制问题的一个方向。。。。。
。。。。。。。。。。。。。。路漫漫其修远兮,吾将上下而求索
1 楼 comsci 2009-12-11 实际上，如果我们把引擎对流程图的解析和处理看做是解方程，那么对于节点数大于一定得数量，拓扑结构复杂到一定程度的流程图的处理方式就不能够仅仅通过SQL操作和算法集合来得到解决，就好像在解5次以下方程可以通过手工计算来获得解，而5次和5次以上的方程的解就必须依靠其它的数学工具，比如说伽罗瓦群论来处理了。。。。。。
