[更新]总线模式与工作流引擎扩展思路

 

我们设计用户自定义工作流引擎的时候，往往面临这样的问题，即：流程图的设计权在用户那里，而我们后台的引擎代码却是系统开发人员是先写好的，这种情况导致-无限复杂的流程图与处理功能相对有限的流程引擎模块之间的矛盾，这个矛盾就是用户自定义工作流的主要矛盾，如何在现有技术水平下妥善解决这个矛盾就成为我们的主要任务

  前几天在装一台二手服务器的时候，看见PCI插槽，突然想到。。是否我们的自定义流程引擎的核心运行控制算法可以采用总线式与插件这种模型来实现呢？

  其实现有的自定义流程引擎的运行控制器是一个很死板的固定算法，通过递归模式，IF-ELSE，循环来实现流程图的遍历及其处理，这种处理方式对于用户自定义流程图的识别和处理能力很有限，对于那些拓扑结构异常复杂的流程图，这样的算法模型的处理能力非常低下。。

  如果采用总线式模型，那么通过开发扩展插件，并集成到核心控制器上面，那么引擎的处理能力将实现一个从量到质的变化。。。。。。。

  但是，如何把一个相对固定的代码模块转换为总线式的模型，还需要我们搞开源工作流的朋友努力。。。。

 2013.4.4清明节  最新更新：这几天正在开发这个总线模块，尝试一下新方法，把旧的SAN算法模块的核心代码抽取出来，构成一个相当精炼的BUSCODE模块，然后在这个模块的某些关键位置嵌入虚拟控制器，这个虚拟控制器在系统未启动时，是一个空的函数，当前端拓扑扫描器把流程图的拓扑和数据参数传递回来的时候，这些虚拟控制器就会出现具体的流程运行控制代码，这样一来，每个复杂的流程图都会对应一个为其特别构造的运行控制器模块。。。。。这只初步的设计。。估计还会遇到很多问题，但是。。。坚决向这个方向前进，一定要实现一种自适应的流程运行控制器。。。

 我在ITEYE和CSDN我的资源上面都上传了JWFD V0.97.000的设计文档，工程代码包未最终完成，暂时不公布，如果有朋友需要，给我发邮件和站内信息，我给你们发过来

 2013.4.8  在开发具体的算法构造器代码的时候，感觉还有很多关键点的认识很模糊，没有深入到细节问题上，还需要进一步的写文档，把思维细化下去，比如说虚拟函数的结构，拓扑扫描器的返回参数包括哪些内容？