activiti學習資料(架構描述)

時間 2019-11-17

原文原文鏈接

Activiti學習資料java

Activiti是業界很流行的java工做流引擎，關於Activiti與JBPM5的關係和如何選擇不是本文要討論的話題，相關內容能夠baidu一下。Activiti從架構角度看是比較優秀的，是很面向對象的，是我所閱讀過的代碼結構很棒的開源軟件，我的認爲比Spring，Hibernate的要好。

Activiti的基礎編程框架git

Activiti基於Spring，ibatis等開源中間件做爲軟件平臺，在此之上構建了很是清晰的開發框架。上圖列出了Activiti的核心組件。程序員

1.ProcessEngine：流程引擎的抽象，對於開發者來講，它是咱們使用Activiti的facade，經過它能夠得到咱們須要的一切服務。github

2.XXService（TaskService,RuntimeService,RepositoryService...):Activiti按照流程的生命週期（定義，部署，運行）把不一樣階段的服務封裝在不一樣的Service中，用戶能夠很是清晰地使用特定階段的接口。經過ProcessEngine可以得到這些Service實例。TaskService,RuntimeService,RepositoryService是很是重要的三個Service：sql

TaskService：流程運行過程當中，與每一個任務節點相關的接口，好比complete,delete,delegate等等編程

RepositoryService:流程定義和部署相關的存儲服務。緩存

RuntimeService：流程運行時相關服務，如startProcessInstanceByKey.session

關於ProcessEngine和XXService的關係，能夠看下面這張圖：架構

3.CommandContextIntercepter(CommandExecutor):Activiti使用命令模式做爲基礎開發模式，上面Service中定義的各個方法都對應相應的命令對象（xxCmd), Service把各類請求委託給xxCmd，xxCmd來決定命令的接收者，接收者執行後返回結果。而CommandContextIntercepter顧名思義，它是一個攔截器，攔截全部命令，在命令執行先後執行一些公共性操做。好比CommandContextIntercepter的核心方法：app

public <T> T execute(Command<T> command) {  
    CommandContext context = commandContextFactory.createCommandContext(command);  
  
    try {  
//執行前保存上下文  
      Context.setCommandContext(context);  
      Context.setProcessEngineConfiguration(processEngineConfiguration);  
      return next.execute(command);//執行命令  
        
    } catch (Exception e) {  
      context.exception(e);  
        
    } finally {  
      try {  
//關閉上下文，內部會flush session，把數據持久化到db等  
        context.close();  
      } finally {  
//釋放上下文  
        Context.removeCommandContext();  
        Context.removeProcessEngineConfiguration();  
      }  
    }  
      
    return null;  
  }

關於命令模式的細節說明，網上有不少資料，這裏不展開。我只是想說一下我看到Activiti的這種設計以後的兩點感覺：

1）一個產品或者一個項目，從技術上必須有一個明確的、惟一的開發模型或者叫開發樣式（真不知道怎麼說恰當），咱們常說但願一個團隊的全部人寫出的代碼都有統一的風格，都像是一我的寫出來的，很理想化，但作到很難，每每咱們都是經過「規範」去約束你們這樣作，而規範畢竟是程序以外的東西，主觀性很強，不遵照規範的狀況屢屢發生。而若是架構師給出了明確的開發模型，並使用一些基礎組件加以強化，把程序員要走的路規定清楚，那你想不遵照規範都會很難，由於那意味着你寫的東西沒發工做。就像Activiti作的這樣，明確以Command做爲基本開發模型，輔之以Event-Listener，這樣編程風格的總體性獲得了保證。

2）使用命令模式的好處，我這裏體會最深的就是職責分離，解耦。有了Command，各個Service從角色上說只是一些協調者或者控制者，他不須要知道具體怎麼作，他只是把任務交給了各個命令。直接的好處是臃腫的、萬能的大類沒有了。而這每每是咱們平時開發中最深惡痛絕的地方。

4.核心業務對象（Task，ProcessInstance，Execution...):org.activiti.engine.impl.persistence.entity包下的類是Activiti的核心業務對象。它們是真正的對象，而不是隻有數據沒有行爲的假對象，搞java企業級開發的人也許已經習慣了下面的層次劃分：controller->service->dao->entity, entity只是ORMapping中數據表的java對象體現，沒有任何行爲（getter/setter不能算行爲），對於面向對象來講，這固然是有問題的，記得曾聽人說過這樣的話「使用面嚮對象語言進行設計和開發與面向對象的設計和開發是兩回事」，面向對象講究的是「封裝」，「多態」，追求的是知足「開-閉」原則的、職責單一的對象社會。若是你認同上述觀點，那麼相信Activiti會讓你感受舒服一些，以TaskEntity爲例，其UML類圖以下：

（圖2：TaskEntity類）

TaskEntity實現了3個接口：Task，DelegateTask和PersistentObject。其中PersistentObject是一個聲明接口，代表TaskEntity須要持久化。接口是一種角色的聲明，是一份職責的描述而TaskEntity就是這個角色的具體扮演者，所以TaskEntity必須承擔如complete,delegate等職責。

可是這裏有些遺憾的是像complete這麼重要的行爲竟然沒有在3個接口中描述（難道是由於工期緊張？^_^），所以「面向抽象」編程對於TaskEntity來講尚未徹底作到。但至少Activiti告訴咱們：

1）牢記面向抽象編程,把職責拆分爲不一樣的接口，讓接口來體現對象的職責，而不用去關心這份職責具體由哪一個對象實現；

2）entity其實能夠也應該是真正的對象。

5.Activiti的上下文組件（Context）

上下文（Context）用來保存生命週期很長的、全局性的信息。Activiti的Context類（在org.activiti.engine.impl.context包下）保持以下三類信息：

（圖3：Context類）

CommandContext：命令上下文，保持每一個命令須要的必要資源，如持久化須要的session。

ProcessEngineConfigurationImpl：流程引擎相關的配置信息。它是整個引擎的全局配置信息，mailServerHost，DataSource等。單例。該實例在流程引擎建立時被實例化，其調用stack以下圖：

（圖4：ProcessEngineConfiguration的初始化）

ExecutionContext：剛看到這個類感受有些奇怪，不明白其做用是什麼。看其代碼持有ExecutionEntity這個實例。而ExecutionEntity是Activiti中很是重要的一個類，//TODO

6.Activiti的持久化框架（組件）

Activiti使用ibatis做爲ORMapping工具。在此基礎之上Activiti設計了本身的持久化框架，看一張圖：

（圖5：Activiti持久化框架）

頂層接口是Session和SessionFactory，這都很是好理解了。

Session有兩個實現類：

DbSqlSession：簡單點說，DbSqlSession負責sql表達式的執行。

AbstractManager:簡單點說，AbstractManager及其子類負責面向對象的持久化操做

同理DbSqlSessionFactory與GenericManagerFactory的區別就很好理解了。

持久化框架也是在流程引擎創建時初始化的，具體見圖4.

7.Event-Listener 組件

Activiti容許客戶端代碼介入流程的執行。爲此提供了一個基礎組件，看圖：

（圖6：用戶代碼介入流程的基礎組件）

用戶能夠介入的代碼類型包括：TaskListener，JavaDelegate，Expression，ExecutionListener。

ProcessEngineConfigurationImpl持有DelegateInterceptor的某個實例，這樣就能夠隨時很是方便地調用handleInvocation

8.Cache 組件

對Activiti的cache實現很感興趣，但如今我瞭解到的狀況（也許尚未了解清楚）其cache的實現仍是很簡單的，在DbSqlSession中有cache實現：

protected List<PersistentObject> insertedObjects = new ArrayList<PersistentObject>();  
protected Map<Class<?>, Map<String, CachedObject>> cachedObjects = new HashMap<Class<?>, Map<String,CachedObject>>();  
protected List<DeleteOperation> deletedObjects = new ArrayList<DeleteOperation>();  
protected List<DeserializedObject> deserializedObjects = new ArrayList<DeserializedObject>();

也就是說Activiti就是基於內存的List和Map來作緩存的。具體怎麼用的呢？以DbSqlSession.selectOne方法爲例：

public Object selectOne(String statement, Object parameter) {  
  statement = dbSqlSessionFactory.mapStatement(statement);  
  Object result = sqlSession.selectOne(statement, parameter);  
  if (result instanceof PersistentObject) {  
    PersistentObject loadedObject = (PersistentObject) result;  
緩存處理  
    result = cacheFilter(loadedObject);  
  }  
  return result;  
}

protected PersistentObject cacheFilter(PersistentObject persistentObject) {  
    PersistentObject cachedPersistentObject = cacheGet(persistentObject.getClass(), persistentObject.getId());  
    if (cachedPersistentObject!=null) {  
//若是緩存中有就直接返回  
      return cachedPersistentObject;  
    }  
//不然，就先放入緩存  
    cachePut(persistentObject, true);  
    return persistentObject;  
  }

protected CachedObject cachePut(PersistentObject persistentObject, boolean storeState) {  
  Map<String, CachedObject> classCache = cachedObjects.get(persistentObject.getClass());  
  if (classCache==null) {  
    classCache = new HashMap<String, CachedObject>();  
    cachedObjects.put(persistentObject.getClass(), classCache);  
  }  
  //這裏是關鍵：一個CachedObject包含被緩存的對象自己：persistentObject和緩存的狀態：storeState  
  //Activiti正是根據storeState來判別緩存中的數據是否被更新是否與db保持一致的。  
  CachedObject cachedObject = new CachedObject(persistentObject, storeState);  
  classCache.put(persistentObject.getId(), cachedObject);  
  return cachedObject;  
}

看了Activiti的緩存設計，我如今最大的疑問是Activiti貌似不支持cluster，由於其緩存設計是基於單機內存的，這個問題還須要進一步調查。

9.異步執行組件

Activiti能夠異步執行job（具體例子能夠看一下ProcessInstance startProcessInstanceByKey(String processDefinitionKey);），下面簡單分析一下其實現過程，仍是先看圖：

（圖7：異步執行組件核心類）

JobExecutor是異步執行組件的核心類，其包含三個主要屬性：

1）JobAcquisitionThread jobAccquisitionThread:執行任務的線程 extends java.lang.Thread

2)BlockingQueue<Runnable> threadPoolQueue

3)ThreadPoolExecutor threadPoolExecutor:線程池

方法ProcessEngines在引擎啓動時調用JobExecutor.start，JobAcquisitionThread 線程即開始工做，其run方法不斷循環執行AcquiredJobs中的job，執行一次後線程等待必定時間直到超時或者JobExecutor.jobWasAdded方法由於有新任務而被調用。

這裏發現有一處設計的不夠好：JobAcquisitionThread 與JobExecutor之間的關係是如此緊密（你中有我，我中有你），那麼能夠把JobAcquisitionThread 做爲JobExecutor的內部類來實現，同時把ThreadPoolExecutor threadPoolExecutor交給JobAcquisitionThread 來管理，JobExecutor只負責接受任務以及啓動、中止等更高級的工做，具體細節委託給JobAcquisitionThread ，責任分解，便於維護，JobExecutor的代碼也會看起來更清晰。

10.PVM

PVM:Process Virtal Machine,流程虛擬機API暴露了流程虛擬機的POJO核心，流程虛擬機API描述了一個工做流流程必備的組件，這些組件包括：

PvmProcessDefinition：流程的定義，形象點說就是用戶畫的那個圖。靜態含義。

PvmProcessInstance：流程實例，用戶發起的某個PvmProcessDefinition的一個實例，動態含義。

PvmActivity：流程中的一個節點

PvmTransition：銜接各個節點之間的路徑，形象點說就是圖中各個節點之間的鏈接線。

PvmEvent：流程執行過程當中觸發的事件

以上這些組件很好地對一個流程進行了建模和抽象。每一個組件都有很清晰的角色和職責劃分。另外，有了這些API，咱們能夠經過編程的方式，用代碼來「畫」一個流程圖並讓他run起來，例如：

PvmProcessDefinition processDefinition = new ProcessDefinitionBuilder()  
        .createActivity("a").initial().<strong style="background-color: #ff0000;">behavior</strong>(new WaitState())  
        .transition("b").endActivity().createActivity("b")  
        .behavior(new WaitState()).transition("c").endActivity()  
        .createActivity("c").behavior(new WaitState()).endActivity()  
        .buildProcessDefinition();  
PvmProcessInstance processInstance = processDefinition  
        .createProcessInstance();  
processInstance.start();  
PvmExecution activityInstance = processInstance.findExecution("a");  
assertNotNull(activityInstance);  
activityInstance.signal(null, null);  
activityInstance = processInstance.findExecution("b");  
assertNotNull(activityInstance);  
activityInstance.signal(null, null);  
activityInstance = processInstance.findExecution("c");  
assertNotNull(activityInstance);

以上代碼都很簡單，很好理解，只有一點須要說明一下，粗體紅色背景的behavior方法，爲一個PvmActivity增長ActivityBehavior，這是幹什麼呢？ActivityBehavior是一個interface,其接口聲明很簡單：

/** 
 * @author Tom Baeyens 
 */  
public interface ActivityBehavior {  
  
  void execute(ActivityExecution execution) throws Exception;  
}

個人理解：Activiti把完成一個PvmActivity的行爲單獨建模封裝在ActivityBehavior中。execute方法只有一個參數ActivityExecution，爲啥這麼設計？

爲了更好地理解ActivityBehavior的做用，咱們以TaskEntity.complete方法爲例,分析其執行過程，先看complete的代碼：

public void complete() {  
  fireEvent(TaskListener.EVENTNAME_COMPLETE);  
  
  Context  
    .getCommandContext()  
    .getTaskManager()  
    .deleteTask(this, TaskEntity.DELETE_REASON_COMPLETED, false);  
    
  if (executionId!=null) {  
    getExecution().signal(null, null);  
  }  
}

代碼很簡單，也很好理解（可能出乎咱們的意料，由於完成一個task，其實有不少事情要作的）：

1.fireEvent：通知Listener，本任務完成了。

2.數據持久化相關的動做

3.getExecution().signal(null, null)：發信號，這裏面隱藏的東西就多了，整體來講，完成了當前任務流程怎麼走，怎麼生成新的任務都是在這裏完成的。

進去看看：

public void signal(String signalName, Object signalData) {  
  ensureActivityInitialized();  
  SignallableActivityBehavior activityBehavior = (SignallableActivityBehavior) activity.getActivityBehavior();  
  try {  
    activityBehavior.signal(this, signalName, signalData);  
  } catch (RuntimeException e) {  
    throw e;  
  } catch (Exception e) {  
    throw new PvmException("couldn't process signal '"+signalName+"' on activity '"+activity.getId()+"': "+e.getMessage(), e);  
  }  
} <span style="background-color: rgb(250, 250, 250); font-size: 1em; font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', Consolas, 'Courier New', monospace; ">&nbsp;</span>

ExecutionEntity.signal方法核心工做就是把發信號的工做委託給PvmActivity的activityBehavior. 這裏的設計存在問題，很顯然其觸犯了一個代碼的壞味道：消息鏈。它讓ExceutionEntity沒有必要地與SignallableActivityBehavior 產生了耦合，更好的作法應該是PvmActivity提供signal方法，其內部調用ActivityBehavior完成發信號工做。

其實看看PvmActivity的接口聲明，我難免也有疑問，原本屬於PvmActivity的很重要的職責在其接口聲明中都沒有體現，why？？

/** 
 * @author Tom Baeyens 
 */  
public interface PvmActivity extends PvmScope {  
    
  boolean isAsync();  
  
  PvmScope getParent();  
  
  List<PvmTransition> getIncomingTransitions();  
  
  List<PvmTransition> getOutgoingTransitions();  
    
  PvmTransition findOutgoingTransition(String transitionId);  
}