放翁(文初)的一畝三分地

            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
            210 隨筆 :: 1 文章 :: 320 評論 :: 0 Trackbacks
           在路上---基于SCA規范的應用服務框架成長記(二)(連載中...)    文章指數:0  CSDN Blog推出文章指數概念,文章指數是對Blog文章綜合評分后推算出的,綜合評分項分別是該文章的點擊量,回復次數,被網摘收錄數量,文章長度和文章類型;滿分100,每月更新一次。
           二.背上鋪蓋帶上干糧SCA服務框架之路啟程

          記得我在推廣SCA規范的時候,常常和Spring作比較,Spring廣為流傳很大的一點就是在于它的IOC理念,SCA中也很徹底貫徹了這點(這點應該是個趨勢,包括OSGI等等開源框架),但是也正是這個理念,在實際運用當中會帶來困擾。當開發系統越來越大,一個工廠里面的bean組裝復雜度不斷增加,龐大的spring bean factory就好比一個大鍋子,越來越多配置交織在一起,最終模塊與模塊之間無法分割,架構師雖然規劃了很好的目錄結構以及配置文件,但是在運行期的結構依然是耦合性極強,難以分割的業務模塊邏輯團。這樣的系統所面臨的問題就像當初OO要解決的問題一樣,只是上升到了業務級別:業務耦合性強,需求變更適應能力弱,維護成本高,無法剝離較為獨立的業務組件提供復用,模塊與模塊之間牽制性強等。

          SCA規范中描述的元數據就是CompositeComponent,在代碼級別的概念中Component就是SpringbeanComposite可以看作Spring bean factory(其實使用Spring也可以實現SCA,只是如果使用factory來作為composite那么可能在性能上和可擴展性上還有一些問題)。在業務級別的設計中Composite就是業務模塊,Component就是業務內部的業務實現邏輯單元,同時引入了ServiceReference的概念,將服務和引用單獨作為內部邏輯單元,同時定義了ServiceReference的兩種級別(CompositeComponent),達到了業務實現作用域的控制,真正做到了業務組件級別的封裝。

          應該來說,除了開放性的特質以外,業務模塊封裝的特質是SCA的模塊化最突出的優勢,也是解決系統日益龐大情況下,如何降低維護成本,如何適應需求變更,如何提高開發效率的有效手段。但就是規范中的這一點,Tuscany的實現,不得不讓我由原來的基于Tuscany架構二次擴展開發的想法做了轉變,同時在后面對于服務框架的需求不斷發展的情況下,對于Tuscany在服務框架中的定位不斷的作著改變。

          Tuscany在業務模塊封裝上面究竟有什么問題呢?在Tuscany中提供給第三方嵌入的SCA容器EmbeddedSCADomain結構如下:

                                                                                       

          EmbeddedSCADomain運行期結構圖

                 上面的圖展示了EmbeddedSCADomain如何載入外部的Composite到容器中,這里所用的一個技巧,就是includeComposite可以include多個Composite。下圖是一個很簡陋的活動圖,主要就是大致描述了EmbeddedSCADomain是如何加載所有的Composites的。這里面省略了Tuscany對于插件擴展的載入以及一些細節方面的處理。

          EmbeddedSCADomain啟動活動圖

                 根據上面兩個圖就出現了兩個比較大的問題:

          1.       首先EmbeddedSCADomain所有的Composite和資源都是根據固定的URI載入,但是這個或者是目錄或者是jar,但是如果是目錄中的jar將不會去解析,那么對于我們業務模塊當前的開發要求,各個業務開發組會把不同的Composite最后打包到各個業務模塊的jar中,這樣就沒有辦法通過一個EmbeddedSCADomain去裝載,互通就更加說不上了。不過這個問題不是根本性的問題。而后面2的問題是根本性的原則問題。

          2.       Tuscany讓所有的Composite互通,是將所有的composite通過include到一個domainComposite中,在build的過程中將所有的Composite的內部components克隆到了domainComposite中,這樣其實所有的Component就在一個Composite中,也就很方便的互通了。這樣SCA框架的業務模型封裝形同虛設,和spring一樣一個大的factory沒有什么區別,丟失了最大的一個優勢。同時serivcereference都沒有兩種級別之分,業務模塊化就無法實現和控制。

          就這樣兩個問題,讓我需要考慮重新基于Tuscany的部分內核機制來重新構建容器裝載,解析,組裝機制。下圖是ASF(Application Service FrameWork)的運行期結構設計圖

          ASF(Application Service FrameWork)的運行期結構設計圖

          問題一的解決方案:

          ASF中定義了真正包容所有CompositeService Container,創建的過程中,通過搜索Classpath中所有的有composite-load-config.xml文件的jar,composite-load-config.xml定義了需要裝載的Composite,然后resolve這些jar的所有的resource,根據定義要加載的內容動態加載所有需要加載的composite。

          問題二的解決方案:

                 基于問題一的解決,然后在Container中記錄各個composite的必要信息和狀態,然后按照不同級別的servicereference組裝所有的composite,最后激活所有的composite。

          這兩個問題的解決,也標志著ASF的基礎框架形成,后續的戰斗真正開始。

          更多內容可訪問我的blog:http://blog.csdn.net/cenwenchu79

          posted on 2007-11-21 08:03 岑文初 閱讀(1237) 評論(1)  編輯  收藏

          評論

          # re: 在路上---基于SCA規范的應用服務框架成長記(二)(連載中...) 2007-11-21 16:27 thoth
          圖不清楚,能把圖發給我嗎,謝謝
          w_dasheng@yahoo.com.cn  回復  更多評論
            


          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 凉城县| 平乐县| 阳春市| 阿巴嘎旗| 四子王旗| 山阴县| 临澧县| 司法| 高平市| 潜山县| 临湘市| 洱源县| 南皮县| 赤水市| 玉溪市| 闻喜县| 汤原县| 娱乐| 类乌齐县| 防城港市| 巴东县| 阿鲁科尔沁旗| 大竹县| 寻乌县| 阳高县| 伊通| 疏勒县| 麻城市| 宁德市| 伊宁市| 乌拉特前旗| 黄浦区| 修武县| 米易县| 阜城县| 含山县| 南部县| 黄大仙区| 永康市| 沐川县| 嵩明县|