和优快云网友的交流-关于流程令牌机制

    

     xxxxxxxxxx 2011-07-10 14:19

      好奇的问个问题，对于工作流产品，如果有N个业务交由业务员甲处理，而某天，业务员甲因故离职了，那交由他的待处理业务步骤就流转不下去了，那么我们应该怎么样处理呢？（我们知道使用组可以解决这个问题，但如果用户没有设置组，只设置了个人怎么办？另外如果组中的用户是空的又该怎么办？）
    *

      comsci 2011-07-12 08:47
      原则应该是  业务的处理和具体的处理人之间应该有个中间层，无论是谁来，都按照一组既定的规则来处理业务，人走了也不影响业务的处理
    *

      xxxxxxxxxx 2011-07-12 13:21
      我大致研究了一下JBPM， 它的机制貌似是利用其令牌(TOKEN)对象关联特定业务实例的待操作节点（这样不用遍历可以直接找到流转的步骤，大幅提高工作流遍历的速度），由于令牌同时还关联了NODE定义，因此可以通过定义的权限设置找到特定用户是否具有权限操作步骤。但它好像没有判断节点定义的操作人变更为空的情况。
    *

      comsci 2011-07-13 17:36
      令牌的作用是让系统是否处理某个节点而做出的处理控制机制，这种机制对于节点内部绑定的操作者是否为空完全没有任何相关，也不应该相关起来
    *

      xxxxxxxxxx 2011-07-14 09:31
      由于用户的步骤操作权限是绑定在“节点定义”对象的，从数据存取角度讲，用户登录后，先找到其可操作的所有节点，然后通过节点定义查找令牌，进而取到其待处理业务的途径是最快的（不用遍历节点了），另一个角度来看，如果一个节点定义关联的操作用户为空，也可以通过节点定义找到无人处理的业务流。但是好像现在还没有提供这个机制
    *

      comsci 2011-07-15 09:03
      如果对一个流程的处理不需要对整个流程进行遍历就可以进行，那么如果流程的待处理节点需要前一个节点输送过来的数据流和控制流，这种情况，令牌机制是否需要做出改进呢？  令牌机制的关注点不是流程的整体运行，而只是流程中某个节点的处理机制，只关注局部而不关注整体的处理方式在面对复杂的流程模型的时候，显得力不从心
    *

      xxxxxxxxxx 2011-07-15 13:35
      当前节点流转到下一节点的过程不需要判断令牌，令牌也没有关联到任何具体的流转数据信息。仅关联了业务实例，令牌只是保存流转的结果而已，因此不用任何改动。
            我的理解是它只是为了提高查询速度而设置的对象，因为没有令牌，我们其实也是可以找到业务流转关系的。
    *

      comsci 2011-07-16 15:44
      这几天就是在思考这个问题，如果我们不使用遍历的驱动模式，而使用令牌的模式，那么引擎的设计是否会变得更加简洁呢？
      令牌的机制的确也有比较明显的优势，遍历和令牌其实可以同时使用，在不同的场合，根据不同的情况既可以使用遍历，也同时可以使用令牌
    *

      xxxxxxxxxx 2011-07-16 23:02
      这令牌里面的文章很大，JBPM设计的令牌是最初级的一种方式。我使用的令牌更灵活。哈哈，天机等到年底再泄露吧。
    *

      comsci 2011-07-17 09:07
      但是你考虑同时使用遍历和令牌的两种机制吗？
    *

      xxxxxxxxxx 2011-07-17 11:55
      如果令牌的灵活性设计的足够，就可以避免遍历，毕竟遍历消耗的资源太厉害，微软的系统就有多种令牌。
    *

      comsci 2011-07-18 10:16

      嘿嘿，令牌设计得足够的灵活，其复杂性也不会低于遍历机制，令牌机制本身就使得流程图XML的结构变得很复杂了，还足够灵活，要灵活，还要简洁，不容易啊

       ==========================================================================================================================

       如果令牌机制的合理应用可以使得流程引擎在处理流程的时候，避免做全部拓扑结构的遍历，那么回大大降低引擎算法的难度，但是令牌机制的出现也会使XML结构变得复杂，如何取舍，如何做到在这两种处理模式上面的平衡，值得我们做进一步的思考