再談SOA下的流程整合

　　對于SOA我們一直強調最終的目標是要為實現端到端的流程整合服務，而要達到這個目標需要首先形成可重用的服務資產庫，從數據集成，應用集成，再到流程集成，這是通常實施SOA的一個順序。但是對于SOA的實施也可以是一個迭代的順序，即找一個有端到端流程整合的業務場景為導入，以該流程整合分析入手，從頂向下識別和分析需要整合的內容和提供的服務，形成候選服務清單后對服務進行評估，完成服務定義和服務開發，最終對服務進行編排實現我們期望的流程。

　　對于SOA實施來講，真正要做到流程整合是比較困難的一件事情，但是如果有底層服務資產庫的良好支持，那流程整合就會變得容易，所以底層服務資產庫的形成，服務需求分析和服務的識別一定要以流程驅動進行，保證識別的服務具有很好的可重用性，識別的服務能夠為流程服務。

　　為何要進行流程整合，因為流程之間存在斷點;為何流程之間存在斷點?因為業務系統只關注它自己一塊具備范圍的業務。為何業務系統存在這種局限性?因為業務系統往往由企業的某一個業務部門主導建設，而業務部門存在明細的業務和職權分工，業務人員在建設業務系統的時候更多的是關注業務系統能夠完成本業務部分的業務支撐需要。

　　由于煙囪或豎井式的建設，導致端到端流程本身的割裂，原有大流程被業務系統拆分為多個獨立的子流程，端到端流程整合變化為在各個業務系統中的各個子流程的融合。而流程融合的底層仍然是數據的交互和集成，通過數據的交互和集成以解決全流程的集成問題。

　　綜合上面的分析，最核心的問題在于企業需要的是流程視圖或業務視圖，而現有的業務系統實現的是功能視圖，業務系統現在更多的看到的是功能，而非流程;功能可以解決單個業務功能點的問題，但是無法看清楚全流程的問題。

　　再回來談SOA下流程整合的難點，初步分析主要包括如下幾個方面的內容：

　　前期識別的數據服務或業務服務無法為流程整合服務，主要原因是流程分析識別方法沒有安裝業務和流程驅動的方式進行，單純的將原有業務系統的接口轉化為服務。

　　業務系統建設已經初具規模，業務人員已經有根深蒂固的業務系統的概念，各自為陣，流程整合的實現最終會在流程平臺或門戶系統，仍然導致業務人員使用多個系統。

　　對于BPEL重點是業務流自動編排，對于業務流+人工工作流集成還是需要BPM工具，而兩者如何更加有效集成又是關鍵問題，包括原有業務系統很多已有工作流工具的情況下如何進一步整合，而不是替代原有系統和原有功能。

　　流程整合一般有界面集成，門戶一起才能發揮作用，這涉及到需要BPM提供的數據建模和界面建模工具。

　　流程整合，則流程建模和服務組裝過程中自然涉及到業務規則，在沒有規則引擎前通過BPEL來實現復雜業務規則是不現實的，而規則本身對復雜系統的可適用性仍然需要驗證。

　　基于以上難點，初步考慮如下的一些思路來推進SOA流程整合的工作

　　流程整合前期重點關注端到端流程監控，以端到端流程監控為整合的切入點，這種方式下不會影響到已經固化在業務系統內部的業務功能，而解決了原有業務系統無法提供全流程視圖的問題。如項目管理，供應鏈，財務，物流都存在可以選擇的端到端監控流程。

　　重新定位BPM和BPEL工具，對于BPEL僅作為服務的組裝和編排，跨流程的整合啟用BPM提供的功能，BPEL編排的內容作為BPM端到端流程的子流程，這樣充分利用BPM的HWF人工工作流引擎，已有的界面建模和數據建模等能力。對于BPM工具本身需要支持SOA架構，支持和SOA平臺的ESB和BPEL的集成。對于BPM提供的業務流程建模工具倒是次要的。

　　進一步規范和梳理企業已有的IT建設中軟件基礎設施，主數據的建設情況。包括統一認證，單點，權限模型，組織模型，流程模型等，IT系統軟件開發基礎架構等內容，這些是進行SOA流程整合的基礎。流程整合中的業務跨了業務系統，而業務本身底層需要基礎主數據的支撐，這也是SOA流程整合需要主數據管理系統提供能力支持的原因。

　　前期數據服務和業務服務的識別，一定要從高端IT架構規范和分析導入，遵循流程建模和數據建模的思路，從端到端流程的逐層分解，由上到下的分析和識別服務，充分考慮服務的粒度和可重用性，這樣前期實施的服務才能夠真正為后續流程編排和端到端流程整合服務。

原文轉自：http://www.kjueaiud.com