二.背上鋪蓋帶上干糧SCA
服務框架之路啟程
記得我在推廣SCA規范的時候,常常和Spring作比較,Spring廣為流傳很大的一點就是在于它的IOC理念,SCA中也很徹底貫徹了這點(這點應該是個趨勢,包括OSGI等等開源框架),但是也正是這個理念,在實際運用當中會帶來困擾。當開發系統越來越大,一個工廠里面的bean組裝復雜度不斷增加,龐大的spring bean factory就好比一個大鍋子,越來越多配置交織在一起,最終模塊與模塊之間無法分割,架構師雖然規劃了很好的目錄結構以及配置文件,但是在運行期的結構依然是耦合性極強,難以分割的業務模塊邏輯團。這樣的系統所面臨的問題就像當初OO要解決的問題一樣,只是上升到了業務級別:業務耦合性強,需求變更適應能力弱,維護成本高,無法剝離較為獨立的業務組件提供復用,模塊與模塊之間牽制性強等。
SCA規范中描述的元數據就是Composite和Component,在代碼級別的概念中Component就是Spring的bean,Composite可以看作Spring bean factory(其實使用Spring也可以實現SCA,只是如果使用factory來作為composite那么可能在性能上和可擴展性上還有一些問題)。在業務級別的設計中Composite就是業務模塊,Component就是業務內部的業務實現邏輯單元,同時引入了Service和Reference的概念,將服務和引用單獨作為內部邏輯單元,同時定義了Service和Reference的兩種級別(Composite和Component),達到了業務實現作用域的控制,真正做到了業務組件級別的封裝。
應該來說,除了開放性的特質以外,業務模塊封裝的特質是SCA的模塊化最突出的優勢,也是解決系統日益龐大情況下,如何降低維護成本,如何適應需求變更,如何提高開發效率的有效手段。但就是規范中的這一點,Tuscany的實現,不得不讓我由原來的基于Tuscany架構二次擴展開發的想法做了轉變,同時在后面對于服務框架的需求不斷發展的情況下,對于Tuscany在服務框架中的定位不斷的作著改變。
Tuscany在業務模塊封裝上面究竟有什么問題呢?在Tuscany中提供給第三方嵌入的SCA容器EmbeddedSCADomain結構如下:

EmbeddedSCADomain運行期結構圖
上面的圖展示了EmbeddedSCADomain如何載入外部的Composite到容器中,這里所用的一個技巧,就是include,Composite可以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沒有什么區別,丟失了最大的一個優勢。同時serivce和reference都沒有兩種級別之分,業務模塊化就無法實現和控制。
就這樣兩個問題,讓我需要考慮重新基于Tuscany的部分內核機制來重新構建容器裝載,解析,組裝機制。下圖是ASF(Application Service FrameWork)的運行期結構設計圖


ASF(Application Service FrameWork)的運行期結構設計圖
問題一的解決方案:
ASF中定義了真正包容所有Composite的Service Container,創建的過程中,通過搜索Classpath中所有的有composite-load-config.xml文件的jar,composite-load-config.xml定義了需要裝載的Composite,然后resolve這些jar的所有的resource,根據定義要加載的內容動態加載所有需要加載的composite。
問題二的解決方案:
基于問題一的解決,然后在Container中記錄各個composite的必要信息和狀態,然后按照不同級別的service和reference組裝所有的composite,最后激活所有的composite。
這兩個問題的解決,也標志著ASF的基礎框架形成,后續的戰斗真正開始。
更多內容可訪問我的blog:http://blog.csdn.net/cenwenchu79