关于博友comsci的工作流分支聚合逻辑处理的一点看法

最近因工作需要，开始着手研究工作流方面的技术，在网上也搜集了一大把工作流方面的技术框架资料。根据自己以前改写xiorkflow工作流的体会心得，觉得工作流在处理分支汇聚节点方面的逻辑比较复杂，目前各个工作流框架对于这个逻辑的处理方式也是各有不同，前段时间看了comsci写的这篇文章：[url=http://comsci.iteye.com/blog/339756]带条件选择的并行汇聚路由问题[/url]。让我想起以前改写xiorkflow工作流逻辑时遇到的一些问题，不过当时关于汇聚节点的逆向递归处理逻辑是另外一个同事做的，感觉挺复杂的。不过最近参考了一些工作流技术框架关于分支聚合逻辑的处理方式，慢慢有了点心得，觉得对于分支聚合逻辑的处理是不是可以简化一下？下面是我的一点思路，可能在逻辑上有不够周全的地方，先写出来，希望有兴趣的同仁过来讨论一下。本人qq：371319819。

首先，引用一下comsci在探讨分支聚合逻辑时提出的一些观点和图片，来作为本人观点的一个参照：
问题的描述：在一个流程图中，存在N个分支点和M个汇聚点，所有的汇聚点和分支点的关系有规则对称和不规则对称两种（图中的A2的拓扑是规则对称，A1,A3是不规则对称），每一个分支点的运行路径数S和它的实际分支路径数W有可能不相同,即S<>W和S==W的情况同时存在，问题是:在不规则对称的拓扑情况下（A1,A3），已知分支点的运行路径数值S，求图中任意一个汇聚点的实际访问(实际汇聚)数值 。
[img]http://dl.iteye.com/upload/attachment/212402/86c60558-9572-38e8-8122-1dab37518577.jpg[/img]


至于他说的：汇聚点和分支点的关系有规则对称 的情况我就暂时不讨论了。我谈谈对于非队称情况的处理。
例如我们遇到的情况是A3情况下的分支聚合节点，假如当前的业务需求是：分支出来的三个路径中，任意一个路径跑通了，就可以完成节点的成功汇聚。那么我们不用管分支出来的三个路径是如何在后面的运行中分化出来了七条路径的情况，我们只在汇聚节点里统计到达的路径，如果路径数目为一，则立即汇聚成功并往下面的节点走，下面的节点初始化后，立即通过程序处理，强制将前面尚未complete的节点的状态设置为cancle。

假如当前的业务需求是：分支出来的三个路径，任意两个跑通了，则可以完成节点的成功汇聚。那么分支出来的三条路径上携带有条件判断逻辑，逻辑为true的会往下跑，为false的则停止。这时，我在设计工作流模型图的时候就要做特殊处理了，画出来的图形会和comsci给出来的A3的图形不一样。我的画法是：分支节点分出了三条路径没错，上面那个路径通过分支节点，又分出了三条路径，我要求新分出来的三条路径要有一个汇聚节点，那么输出的就会是一条路径。中间分支路径的处理情况也是一样。这样，A3中的最终汇聚节点到达的仍然只是三条路径。如图：

[img]http://dl.iteye.com/upload/attachment/252203/35c59460-9cc3-3ab0-ba65-9b242b1ed04b.jpg[/img]

该汇聚节点统计到达路径数目，数目为2则向下流转。这样处理的好处是：我不必在最终汇聚节点那里进行路径的逆向递归处理。如果按照comsci以前的画图方式，在最终汇聚节点那里到达了两条路径，这两条路径很可能是原始分支节点出来的第一条路径经过继续分支，而产生的其中两条路径，那么在这种情况下，就无法满足我当前的业务需求：分支出来的三条路径，需要任意两条跑通。

加入当前的业务需求是：分支出来的三条路径，有如下的跑通规则，才能成功汇聚。（仍然拿A3分支来说事，A3中分支出来的三条路径分别为A31，A32，A33）
1.A3中A31能跑通，则A32务必要跑通。
2.A3中的A32能跑通，则A33务必要跑通。
3.A3中的A33能跑通，则A31和A32都需要跑通。
上面三条规则中的任意一条能跑通，则可以成功汇聚。

按照上面的需求，comsci关于A3情况的画图也需要改造，需要分成三个小的分支聚合块。
第一个块是A31和A32分支按照“与”模式跑通并汇聚子块。
第二个块是A32和A33分支按照“与”模式跑通并汇聚子块。
第三个块是A31，A32，A33分支按照“与”模式跑通并汇聚子块。

然后在上面的三个分支汇聚子块外包围着一个大的分支聚合模块，这个大的分支聚合模块的逻辑是，里面分出来的三条路径中，任意一条路径跑通，则成功汇聚。
这个逻辑的图示我就不画了，画法太繁琐，相信仔细看过我的文字描述的同仁应该可以在脑海中勾勒出具体图形。

好了。上面是我全部的处理逻辑，总结起来就是：要求流程图设计人员在设计流程时，每个分支出来的路径，都要有一个汇聚节点。
这样做可能会导致设计上的冗余，可能还会有一些因动态逻辑需求产生的逻辑不灵活的情况。但是优点是处理逻辑上比较清晰，不需要复杂的递归处理。希望大家根据更复杂的业务需求，提出指正意见。谢谢！


上面的论述告一段落，中午我吃饭时细细思量自己的言论，发现自己的逻辑仍有不够周全的地方，现在补充一下：
按照上面的说法，在通过流程设计器进行流程模板设计时，需要设计人员发挥主观能动性，主动在A3的分支路径上细分出来的分支路径后添加聚合节点，否则，我以上的逻辑就会有很多的漏洞。但是要求流程设计人员发挥主观能动性这个要求会不会显得我的工作流逻辑不够智能呢？如果我希望我的流程设计器智能一些，能够主动识别流程设计人员设计出来的流程模板不复合我上面的分支聚合逻辑语法。可能最终还是要用到comsci的逆向递归算法，通过该算法来检测我的分支聚合节点是否复合规范。不过，我并非浪得虚名，对于这一点，我还是能想出些招数来应对的，我的目的，就是“坚决避免递归回溯算法”！为了达到这个目标，我们还可以创造出新的逻辑来应对。我个人的感觉是：工作流就是一个圆通的系统，在这个系统内，它能够解决所有可能出现的需求，没有遗漏的缺口，有遗漏的系统是不圆通的也是没有应用价值的。所谓“圆通”，就好比“圆谎”，例如一个设计了某个天衣无缝的局的人，通过一系列的谎言，营造出了一个可被被操控的“真实的”情景，假如该谎言仅有一个漏洞，那就是他说广州今天在下雨，但是广州今天没下雨，而那个被欺骗的人今天要来广州，怎么办？这个局有个漏洞了，很可能会导致整个局的破灭。难道没办法了吗？我认为，理论上肯定是有办法的，例如：花钱请相关部门，在今天，在广州，来一场人工降雨！总之，没有的东西，我们就算是从新创造也要把它给弄出来，总要让我们的“局”能够圆通地运行。至于在现实中代价是不是太大，成本会不会太高。这个是之后再考虑的东西。要先有各种可选的解决方案，才能在此基础上筛选衡量。所谓遇山开路逢水搭桥。如果自己的系统中有确实无法解决的东西，我们也不能让它成为漏洞，可以抛出一个异常嘛，这也是一种弥补漏洞的方式。就像 一除以零 ，现在我们的处理方式是抛出异常，无解。那是因为现在的数学理论尚未达到那样的高度，也许在未来的某一天，一除以零就能得到一个很有意义的数据。但是现在，“抛出异常”就是一个很好的解决办法，在这个圆通的数学领域，我们就能解决所有的数学问题，解决不出来的都“被抛出异常了”。从这个角度来说，现在的数学领域也是圆通的。
以上是我在考虑工作流模型思路时的一个体会，可能有些人会觉得有些偏题是废话。好了，废话不多说了，下面说我的方案。

我不想用复杂的递归回溯逻辑，怎么办？我可以为每个“节点对象”（包括普通任务节点，分支节点，聚合节点，结束节点，开始节点），添加“所属分支节点编号”这个属性，默认值为空，但是分支节点在该属性上的值为自身编号值；为“节点之间的连线对象”添加“所属分支编号”属性，该属性值默认为空，每次从一个分支节点连线到一个任务节点时就初始化该属性值，其值为前一个分支节点的编号，该连线指向的下一个节点的“所属分支节点编号”属性值被初始化，再往下跑，如果没有遇到新的分支节点，则该值不变，遇到新的分支节点，则该值同理改变。遇到一个聚集节点以后，该值重新清空，同时该聚合节点的“所属分支节点编号”属性值被初始化。在进行工作流模板语法检验的时候，每遇到聚集节点，都会统计到达连线的数目和通过连线对象中包含的分支节点编号来统计对应的分支节点的分支路径数目，进行路径数目的匹配核对。如果发现聚合节点到达的连线中，有超过一个连线对象包含“所属分支节点编号”是相同的，则该工作流模板是错误的。
该逻辑还可以处理另外一个特殊的情况，图示如下：

[img]http://dl.iteye.com/upload/attachment/252284/9fc3e68b-9101-3e30-88f5-c247ebf5b963.jpg[/img]

这个是我目前思考出来的解决方案。可能尚有没考虑到的特殊情况，导致我这个”模型“出现漏洞，希望思考过的同仁给出提示，谢谢！