前面我有一篇《JBPM源碼解讀之：Fork》，大致分析了JBPM對于Fork的實現(xiàn)方式，其實Fork和Join是不可分割的一對，F(xiàn)ork實現(xiàn)分拆，Join實現(xiàn)匯集。先讓我們看一下《JBPM 3.2.3 User Guide》中關(guān)于Join的描述：
 The default join assumes that all tokens that arrive in the join are children of the same parent. This situation is created when using the fork as mentioned above and when all tokens created by a fork arrive in the same join. A join will end every token that enters the join. Then the join will examine the parent-child relation of the token that enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the (unique!) leaving transition. When there are still sibling tokens active, the join will behave as a wait state.
     下面就讓我們從JBPM源碼的角度分析一下Join是如何關(guān)閉每一個到達它的Token，是如何檢查各個子Token與父Token的父子關(guān)系，又是如何重新激活父Token實現(xiàn)流程的繼續(xù)流轉(zhuǎn)，更重要的也是我寫這篇文章的原因：我們?nèi)绾文軓腏oin默認的實現(xiàn)方式中得到啟發(fā)，讓我們能夠更好的理解JBPM整個運轉(zhuǎn)流程，更好的駕馭整個項目。

 我們來看Join類的成員變量:

      parentLockMode用于控制Hibernate的鎖機制，這點我們暫且不去深究，有意思的是下面幾個變量：isDiscriminator、tokenNames、script、nOutOfM共同決定了Join節(jié)點內(nèi)被的具體行為，本文稍后會具體解說。

       Join的read方法很簡單，只是起到了讀取JPDL中對lock的配置，并沒有關(guān)心其他成員變量的初始化，這也就直接說明了isDiscriminator、tokenNames、script、nOutOfM這幾個變量均屬于運行期，也就是我們沒有辦法在配置文件里頭像Fork一樣配置Script，就算配了Join也不認。
 execute(ExecutionContext executionContext)方法是每個繼承自Node的類的核心方法，Join類也是在這個方法中實現(xiàn)了Join的控制機制。在解讀這個方法之前必須應該明白的一件事是：Join的execute方法就像Fork的Node-Leave 事件一樣是會執(zhí)行多次的，同樣這取決于與Join搭配的Fork具體產(chǎn)生了幾個子Token。

  Join的這種處理方式，讓我們可以方便的實現(xiàn)一種生活中經(jīng)常用到的抄送機制，例如：在某個流程中有一個審批的環(huán)節(jié)，這個審批的默認執(zhí)行人為李副處長，既定情況下，如果這位李副處長審批完畢，流程就應該繼續(xù)，但是現(xiàn)在王正處長要求所有審批過的文件都要自己親自過目，但是只是過目，王處長的這個“過目”的行為要求并不會影響流程的運行，意思就是說，王處長完全有可能在流程都已經(jīng)結(jié)束過了才去過目。稍后我會另有文章具體介紹我的使用Fork+Join實現(xiàn)抄送的思路。
  繼續(xù)，呵呵，接下我們分析的方法都是在if (isAbleToReactivateParent)塊內(nèi)的，剛才我們說如果isAbleToReactivateParent == false那么整個方法就結(jié)束了。

    讀了這段邏輯很少，但是注釋很多的代碼相信已經(jīng)明白了Join內(nèi)部的核心了，有一種豁然開朗的感覺，JBPM的設計思想真的很迷人：幾句簡單的If、Else
 就實現(xiàn)了讓人看來很神秘的功能。這個時候我們可以來分析一下他的幾個成員變量的作用了。
   如果isDiscriminator為True，這個時候Join節(jié)點其實是起到一種選擇器的作用：當?shù)谝粋€子Token到達Join之后，Join就會馬上取消其他子Token執(zhí)行自身execute方法的能力，而且流程會馬上繼續(xù)而不會再理會其他的子Token有沒有到達Join或結(jié)束，因為根據(jù)我們上面的分析，isDiscriminator被設置為false的子token是不具備激活父Token的能力的。原來實現(xiàn)網(wǎng)上經(jīng)常爭論的用Join實現(xiàn)多選一是那么簡單（呵呵）！
   下一個有意思的是nOutOfM，代碼寫的很明白，當子Token到達Join的時候n就加1，如果n<nOutOfM Join就一個處于等待狀態(tài)，直到n > nOutOfM 流程馬上繼續(xù)，這就Join實現(xiàn)多選多的機制，真的很簡單，當然如果我們把nOutOfM設置為1，那么他所起到的作用就跟isDiscriminator一樣了。
   在說明其他兩個變量之前，讓我們先來看一下public boolean mustParentBeReactivated(Token parentToken, Iterator childTokenNameIterator)方法

    isDiscriminator和nOutOfM實現(xiàn)了多選一和多選多，但是這兩個變量起到的控制作用是死的，也就是我們并不能指定從Fork那里產(chǎn)生的子Token中哪幾個到Join之后流程可繼續(xù)。例如Fork創(chuàng)建了A、B、C、D、E五個Token，如果用前面那兩個控制機制，這五個哪幾個到Join之后流程會繼續(xù)完全是不可控的，如果我們要實現(xiàn)必須是A、C、E到達Join之后流程才可繼續(xù)，這樣的需求用isDiscriminator和nOutOfM是無法實現(xiàn)的。別著急，tokenNames是專為解決這個問題而設置的，我們選定幾個子Token塞給tokenNames，那么Join就會自動為我們做這些事情了。
 相比tokenNames Script為我們提供了更靈活的控制機制。如果Script返回Collection類型，那么Script起到了tokenNames的作用，如果返回Bolean類型，那么Script起到isDiscriminator的作用，源碼上注釋的很清楚，我就不在這羅嗦了。
     到這Join的代碼我們也就讀完了，如果上述四個成員變量都為默認值，那么Join也就按默認的行為執(zhí)行，Join是JBPM源碼中少數(shù)注釋很全的類，這也說明這是JBPM開發(fā)組的得意之作。通過四個屬性我們可以非常靈活的使用Join實現(xiàn)很多實用的效果。

          文章原創(chuàng)，轉(zhuǎn)載請注明出處！