在現有工作流程引擎結構中加入反饋機制是否會引起混亂？

      如果我們的流程引擎是一個對流程圖進行有序處理的系統，那麼如果在這個系統裡面加入有條件跳轉的語句，在自動運行控制機制下，這種跳轉行為與原有的遞迴演算法共同作用，是否會引起整個流程運行控制機制的混亂呢？    我那天說的在程式裡面增加有條件跳轉 GOTO語句會大大增強程式的功能，這幾天仔細想一下，如果出現類似這種情況，流程圖原有的遍曆次序被打破，那麼是否會使得ARC對流程的控制失效？    存在這種疑問，所以我覺得需要從總體設計上重新考慮流程引擎的自動運行控制機制

      問題難就難在我們的引擎要全盤考慮整個流程的運行過程出現的每一個細節問題，好像設計一個發動機，連一顆螺絲釘的外形改變都會帶來全域設計的改變(我猜的,說得不對， 請專家指正)。。。流程引擎的ARC系統也不例外。。。這個就有點考水平了。。

     那我們就讓ARC遍曆一次，準備遞迴的時候，如果遇到一次反饋行為，那麼ARC對於其它節點的遍曆次序是否會發生錯誤呢？反饋行為發生在遞迴之前，遞迴之後，或者正在遞迴的時候，分別會出現什麼情況呢？那麼我們不管這些  先在ARC裡面加入一個判斷條件模組  在ARC模組中嵌入jumper()，然後運行流程，測試一下看看流程啟動並執行時候，出現反饋行為並調用jumper是否會引起ARC的控制錯誤，實踐是檢驗技術的關鍵手段，讓我們先行先試吧。。作為一個工作流程技術愛好者的實驗平台,JWFD就扮演著技術和理論測試的角色，行不行，好不好，試過再說。。。

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

一個工作流程系統是否能夠賣個好價錢，關鍵就在核心系統裡面。。現在市場上的流程產品越來越多，同質化也很嚴重，競爭是否勝出的關鍵還是在於核心技術方面，所以企業有必要加大在這方面的投入力度，我建議企業和大專院校和研究機構進行密切合作，避免從代碼裡面來再到代碼裡面去，沒有理論上的支援，代碼的設計水平難以提高，這點我很有體會。。。國內的天翔工作流程就開始和研究機構進行合作，真是不錯。。。期待他們的產品越做越有水平。。。。。。