JWFDv0.96 最新设计思路

                  


随着工作流技术的发展，工作流产品的应用范围也不断的在扩展，开始进入了像金融行业(我已经看到国有四大商业银行的工作流产品招标公告了)，实时生产控制和其它比较重要的工程领域，而这些领域对数据的准确性和实时性要求都比类似文件管理，办公系统这些高得多，那么如果工作流技术要进入这些领域，我们该做些什么准备呢？

       我在这里需要结合工作流系统设计的一些具体技术问题来阐述，首先是由于我们向用户提供的是可以让用户自定义流程的设计器,那么用户会设计出什么样的流程出来，我们作为系统的设计者并不能够完全确定，这句话的意思就是说，流程系统可能会遇到一些由于用户自定义的流程超出我们设计的引擎处理能力的情况，特别是像流程系统同时还给用户提供了自定义公式或脚本设计器的那种情况下，而我们设计的流程后台处理系统又不可能设计得太过于复杂，以至于可以像某些宣传的那样："我们的引擎可以处理各种复杂的流程" (其实JWFD也曾经这样宣传过,但是这是不科学的)，但是事实上，我不会真正的有这个胆量向客户保证，因为从数学的角度来讲，一个流程图的拓扑结构在超过某个复杂的程度之后，有可能出现节点不可到达的情况，也会出现流程数据不可计算或者计算结果是错误的情况(这并非是设计水平问题，而是复杂的情况会超出我们的想象)，这样的情况的出现将会导致某些行业的应用出现严重的后果(在这里，我宁愿把问题想象得严重些)，如果出现某些故障，作为系统的设计者也有可能因为这些故障导致的事故承担某些或轻或重的后果，因此我曾经说过,JWFD只是作为要从事流程系统设计和开发的朋友的学习和设计的参考，并不能够仅仅进行一些简单的修改就当做产品去销售，但是据我所知，有不少这种把开源技术和产品直接经过简单包装和修改之后就作为商业产品拿去销售的情况。。。那么在说明这种情况之后，我也要提出针对这些问题的解决办法，做任何事情都会遇到困难，而人就是因为解决这些问题而不断进步的。。(个人如此，一个公司也应该如此，不能够因为想赚快钱，就放弃对技术的执着的热爱。。。。反过来一样，哈哈)，针对上述的问题，我提出的解决方法是：

1：为用户提供一个用于对流程图和流程进行模拟运行和调试的工具，国内的开源软件Fireworkflow(www.fireworkflow.org)就提供了这个工具，这样一来，哪怕用户设计出一个复杂的流程，在正式提交运行之前，设计流程的用户也可以对这个流程模拟运行，然后根据运行情况进行调试和修改，甚至需要对流程图进行反复的修改，这个过程就好像我们做软件开发一样，写代码，然后运行，查找错误，修改，再调试，如此反复N次，这样下来，一个运行着重要数据的流程才能够保证其运行过程中的数据正确性，也就避免了我在前面说的那种不可预测的复杂流程导致失败的问题，所以这个流程模拟运行与调试工具对于一个有志于进入高风险行业的的流程产品来讲是必须的。。。。。。。。。。

2：规范用户的自定义行为,我们可以通过对流程设计器的定义流程的功能进行某些调整，比如说不容许用户设计出不对称的，或者包含多个环形结构的流程图，因为这些流程拓扑结构会加大流程引擎处理的难度，也增加流程系统设计的开发成本，对于一个中小软件企业来讲，要开发出一个很稳定，而又能够处理各种流程的系统并非很简单的事情，而用户在其它办公和信息系统中又都要求包含工作流系统的情况下，软件开发企业必须采取某些策略，来保证自己即能够拥有工作流产品，又避免企业对工作流系统的开发成本过高，那么这种办法值得考虑。。。
。。(在这里我应该为JWFD不遵守XPDL等规范而辩护，流程图的规范是应该由各个软件企业自己来设计和定义的，所谓的统一规范和标准虽然具有一定得必要性，但是却并非普遍适用的）

3: 把流程引擎自动控制方式转变为半自动，半手工的控制方式：对于某些简单的流程应用，我们并不需要让流程引擎完全自动化运行，可以采用用户手动推进流程的运行方式来减少流程系统的设计难度和代码的复杂度(JWFDv0.96版本就是采用半自动方式，JWFDv0.94之前的引擎都是自动方式)

4: 对流程图进行扫描并分类，并根据不同的类别提供不同的流程引擎模块: 我们可以在流程引擎系统中嵌入一个流程图扫描工具，对用户自定义的流程图进行预扫描，并根据扫描的结果来判断这个流程图的节点数是多少？大于10，还是大于20，流程的拓扑结构是简单的，还是复杂的，内部嵌入的数据结构是简单的，还是复杂的，然后根据这些扫描结果，分别调用不同的流程引擎模块，对于简单流程图就用简单引擎算法，对于复杂图就用功能更加强大的引擎算法，这样一来，整个系统的设计就更加清晰，也避免了一些不必要的设计。。。


  事实上，一个包含自定义设计器的流程产品的提供者应该在产品说明中，向用户说明，这个流程产品所能够处理的流程图的极限复杂程度等情况，避免用户使用自定义设计器设计出引擎无法处理的流程图之后，导致无法运行而产生的一系列商业上面的纠纷。。。。。。对于仅仅为普通办公系统提供业务流转的工作流模块，其开发的难度和功能都是非常有限的，甚至某些流程并不是一定需要用户自定义设计器，这样的工作流系统的开发也不一定要花费比较昂贵的成本，但是对于要进入某些重要而具有风险的行业的工作流产品和包含工作流模块的产品来讲，应该花费的开发成本是不能够因为某些情况而降低的，否则不可预知的风险就等待着我们