對於實現組件化業務系統的一些想法

         " href="http://goo.gl/cXS2d">組件化的業務系統架構觀念據說已經提出來20多年了,可是至今沒有見到讓人信服的 組件化業務系統(注: 組件化≠模組化).關於 業務組件是什麼,長什麼樣子,如何?,又有什麼樣的遠景? 大家也都做了很多思考和討論.
看了社區裡的一些內容，再加上平時跟同事們的交流和討論，對組件化業務系統的實現產生了一點想法。下面我說下我的想法，歡迎大家來拍磚討論。
        我覺得目前大家對 業務組件有一個共識：就是各個業務組件相對獨立，並且具有可組裝性和可插拔性。
        每個組件的運行僅依賴於平台或者容器，組件與組件之間不存才直接的耦合關係。同時，組件與組件之間又並非絕對的獨立。組件經過組裝後可以與其他的組件進行業務上的互動。比如銷售組件與財務組件，一筆銷售業務的完成必定會產生一筆或幾筆財務的業務，如銷售發票的開出和一筆新的應收應付或者現金銀行的記賬。又比如，採購與庫存管理，當採購的需求被提出，那麼是不是要先看看倉庫是不是有存貨呢？如果本倉庫沒有，是否允許從其他倉庫調撥呢？等等等等……，諸如此類的業務情境無法窮盡,而不同行業不同規模的使用者他們的業務過程又各自不同。
        也就是說,組件之間的互動在業務上存在著不可規範和不可窮盡的特點.這是個比較頭疼的問題，暫且記下，稍後再做討論。
        另外,我的理解: 組件化是介於模組化與應用系統整合之間的一個概念.關於 組件化、模組化、應用的不同，社區中的一篇文章寫得很好。這篇文章的最後，提到了組件化不同於模組化，引文： 模組化開發不同於組件開發，模組化開發只是在邏輯上做了切分，物理上（開發出的系統代碼）通常並沒有真正意義上的隔離，一切都只是在文檔中。文章中間也提到過組件化與應用整合的不同，引文： EAR或者WAR部署的是一個公司專屬應用程式，請注意EJB規範中明確說：The Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications(EJB 2.x和3.x唯一的區別是2.x有distributed），它們有自己的應用域，彼此相互隔離（簡單的看，它們有各自獨立的會話管理）。.NET也是有自己的應用域概念。
        根據上面所描述，結合我把 組件化放置到模組化和應用整合之間的定位。組件化應比模組化更獨立，但比應用整合結合得更加緊密。藉助上面提到的那篇文章分析的,引文: 基於應用的部署導致了三個隔離問題：互動（介面）隔離、程式訪問隔離和資料隔離.來看看組件化、模組化、應用整合的區別，以更清晰的看清楚組件化的位置。

	使用者互動（介面）	程式訪問	資料
模組化	統一	模組間直接依賴訪問	統一儲存
應用	獨立	對外部開放提供者	獨立

      
         組件化既然是介於上面兩者之間的，那麼這三個方面又該如何定位,如何?呢？
        1. 介面互動
        我認為使用者互動應該統一，因為組件化的各個業務組件最終拼裝成同一套公司專屬應用程式，UI作為使用者操作介面，必須看起來是統一的而不是獨立的。這一點與模組化實現的各種系統類別似，雖然屬於不同的模組但使用者介面使用起來始終如一。另外，開發和部署上我認為應該根據組件不同來分離。
        於是矛盾出現了，既然要看起來統一，又要可以分開來開發，可以分開來部署。首先如何保證不同的開發小組開發出的介面風格一致。其次分開部署使用什麼手段整合到一個介面中呢？
        針對第一個問題我們可以模仿模組化開發的經驗，複雜一點：使用統一的UI工具開發；簡單一點：也可以基於約定。至於UI整合的事情我們可能需要有一個門戶組件來搞定了。
        2. 程式訪問
        這個問題比較糾結。
        基於“組件僅依賴於平台運行,而不依賴其他組件運行”這個前提.組件之間的互動就不能像模組化那樣直接存取。那麼像應用整合那樣開放提供者如何呢？
        我認為也不妥。為什麼呢？讓我們想一下系統整合發生的情境。某公司已經有一套某業務領域的系統，現在又要上另一套其他業務領域的系統。當這兩套系統在業務上出現了互動時，找來兩套系統的開發商，制定方案，進行二次開發，彼此開放介面修改程式相互調用。從這裡我們可以看出，這種方案首先從誕生的那天起就是一個出於無奈的方案。註定被結合的兩方不夠緊密，其次開放提供者存在一定的安全隱患。另外，加上我們前面留下的那個難題：“組件之間的互動在業務上存在著不可規範和不可窮盡的特點。”這樣的整合方案是不是不適合我們的組件呢？首先,組件之間會存在如此頻繁複雜的互動,我們需要更緊密的結合,或者說是無縫的結合。另外,我們在開發組件的時候,不可能預想到那麼多的其他組件它們期望從我們這裡得到什麼，我們不可能事先為它們準備那麼多的服務介面。
        那麼程式間的訪問，又有什麼樣的介於模組化和應用整合兩者之間的方案呢？這個平衡點在哪裡呢？我有個還不太清晰的想法，這裡提一下，大家來拍吧。
        先說一下常規的方案.比較常規的想法，可能多數人(包括我)會想到引入匯流排，或類似於主板和插槽的概念，把我們的組件插上去，組件與匯流排結合，通過匯流排與其他組件實現互動。這樣做確實能實現互動和通訊，可我總覺得這樣的方案不是最好的,組件的結合還是不夠直接不夠緊密，依然存在我們無法窮盡哪些服務需要提供給匯流排，供其他組件調用的問題。而且,既然是匯流排就有類似於頻寬的問題,當業務高峰期,組件間的互動頻繁,勢必會發生擁堵,帶來效率問題.
        我認為我們需要更靈活、更直接的組裝結合.
        我們來創造一個“粘合層”或者“膠水層”怎麼樣？由“膠水層”來負責各個組件之間的互動和粘合問題.組件的組裝,我們經常比喻成搭積木或者拼圖。但實際上我們不能夠像積木和拼圖那樣,事先定義出明確的尺寸大小和足夠的插槽或介面，我們的組件實際形狀是比較靈活的、形狀不一、大小不一的。對於這樣形狀體的組合，我認為使用強力“膠水”來粘合比較合適。當我們選定了兩個組件，並要將他們聯合起來使用的時候，我們在中間塗上一層“膠水”把他們粘合起來，“膠水”實際是一種導體，它作為資訊傳輸的介質，在兩個組件中進行程式的調用和資料的傳輸。某一個組件可能會與多個組件進行結合互動，我們在它們之間分別加入“膠水”進行組合，使他們之間各有單獨的組合介質，而不是統一通過唯一的匯流排。這樣可以讓組合更加靈活，互動更直接。
至於膠水層的實現問題，可能需要一些技術上的突破。需要進一步的探討研究。目前考慮Python或者Ruby這樣的動態語言。這裡存在有諸如：事務控制，同步非同步，並發控制等問題，也需要進一步研究。
另外，引入膠水層可能會對人員的布局產生一些影響。不僅僅有負責各種組件開發的Team Dev，還可能需要有負責膠水組合的實施團隊（這個實施團隊貌似技術門檻有些高，我們可能需要考慮做一個工具來減輕這個團隊的技術門檻，使之儘可能多關注業務，少關注技術。當然，對於經常組合的組件我們會積累下他們之間的“膠水”代碼來複用）。
        3. 資料
        介於模組化與系統整合之間。我認為各組件的業務資料應該分別儲存，各個元件資料庫上實現大部分的資料自治。這部分自治的資料包括業務資料和中繼資料，至於主要資料考慮使用冗餘的方式，通過引入主要資料組件來同步分發給各個業務組件。注意，這裡我們叫做“主要資料組件”，而不叫做“主要資料匯流排”，表示其在系統中的地位與其他組件無異。
        關於查詢和統計分析。簡單的查詢，資料僅涉及本組件內的，可以直接查詢本組件內資料庫獲得。一些跨組件資料的查詢或者報表、報告，考慮進行資料幫浦進入BI組件，利用BI組件進行分析。          
        我簡單畫了一個基於業務組件的系統的布局圖，也順帶提一下關於容器的事情。

          

       

 每個容器內可以部署1-N個業務組件,容器可以有多個（註：容器≠物理伺服器，一台物理伺服器上可以有多個容器）。組件間的程式調用通過膠水層實現粘合,與本容器內或其他容器內的組件進行互動（膠水圖上不好畫，就不畫了）。這些組件中包括我們的功能許可權組件、資料許可權組件、主要資料管理組件等一些我們常稱之為系統級組件的組件。另外，需要有一個對使用者的出口，必須有一個容器上需要部署門戶組件。門戶組件將其他業務組件的操作介面嵌入到使用者頁面中，提供一致的人機互動出入口。
        上面這些只是些想法，尚未形成實際的方案，這裡先發出來拋個磚，大家集思廣益一下能扔塊玉回來就最好了。
 
        提供該文檔的機構為 OECP社區，更多的部落格文章可以到 OECP社區查看。該文檔附件歡迎各位轉載，但是在沒有獲得文章作者許可之前，不得對文章內容或者著作權資訊變更，著作權歸OECP社區所有，僅此聲明。