1 實現了針對MS SQL的DAO部分
2 增加了對用戶的支持，可以制定與Node相關的用戶
3 修改了Spring整合部分
4 新增了基于Struts2的WEB程序示例
下載地址：
http://www.tkk7.com/Files/chaocai/swf-0.94.rar
參見
SWF一個簡單工作流引擎
DAO看似是一個非常簡單的模式，但這個模式卻十分重要，它可以幫助我們實現持久化邏輯和業務邏輯的分離；它可以幫助我們實現對多種持久化實現的支持。
同時，DAO模式并沒有看起來這么簡單，要真正發揮它的威力需注意的方面很多，而這些方面常常被大家忽略，以下是本人總結的一些最佳實踐。
1 不要在DAO上控制事務的邊界
應該在Façade層控制事務的邊界，這樣可以提高DAO的復用性，使它適用于不同的事務策略。
2 不要過分使用Checked Exception
開發者常常會將DAO中的各種異常通通捕捉并通過Checked Exception拋出，其實這是中不好的習慣，因為DAO中發生的異常常常是不可恢復的（如：數據庫連接問題等），既然如此就應該使用RuntimeException異常拋出，使用這種異常還有一個好處就是在CMP的情況下可以自動引發事務的回滾。
3 不要在DAO中處理懶加載問題
使用Hibernate就會經常遇到懶加載問題，但是這個問題不應該在DAO中解決，這樣會影響DAO的復用性，應為要加載那些對象域往往是和界面相關的，這個問題應該在Façade層中解決，應為這是離表現層較近的一層。
http://dev2dev.bea.com.cn/blog/chaocai/200806/dao_24_1070.html
蔡超
軟件架構師
軟件架構顧問
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn
“自己實現IoC,AOP容器”（http://www.tkk7.com/chaocai/archive/2008/05/26/203020.html）文章中給出的文件下載后有問題，請從以下地址下載。
http://www.tkk7.com/Files/chaocai/mini-container-beta-0.9-a.rar
源碼下載沒有問題可以繼續下載。
上一篇相關內容
http://www.tkk7.com/chaocai/archive/2008/05/26/203020.html
源碼下載
http://www.tkk7.com/Files/chaocai/mini-container-beta0.9-src.rar
希望對大家有幫z，也期待大家的反饋！
摘要:
Mini-Container 開發者手冊
(Mini-Container Beta 0.9,
下載地址：http://www.tkk7.com/Files/chaocai/mini-container-beta-0.9.rar
)
蔡超
軟件架構師
軟件架構咨詢顧問
Chaocai2001@yahoo.com.cn
序
Mini-Container...
閱讀全文
近期做了幾個使用OSGi開發的應用，發現使用過細粒度的Bundle不會給項目帶來任何好處，而很多設計人員實際都會在使用OSGi平臺時陷入這個陷阱。
首先我們分析OSGi的特點及可以給我們應用帶來的好處
1 良好的動態特性
2 更細粒度的類裝載控制，多個版本組件在同一運行環境中共同運行
3 在JVM內部實現SOA（我個人倒是認為OSGi所涉及的僅僅是SOA思想的一小部分）
4 DS提供的IoC支持
請思考你的應用程序真的需要這些嗎？
很多設計和開發人員都會在設計和實現時忽略應用的真正需要和OSGi的復雜性，將應用的所有內部細小劃分都采用Bundle實現。
而我們除了應該注意采用OSGi開發和調試帶來的復雜性；同時也要明白動態特性的支持并不是僅僅采用OSGi平臺就可以搞定的，要真正實現動態特性必須注意模塊的啟動順序無關性及對其所依賴服務的監聽等，這些都會大大增加系統實現和調試的復雜性。
其實我們應該認真分析應用是否需要這些OSGi的特性及這些特性應該在應用的那些部分體現，例如我們可以在擴展方面采用Bundle實現擴展插件，至于其它部分則不必采用過多的Bundles（甚至可以采用一個大的Bundle，而其內部則可以采用如Spring來幫助我們實現模塊化）。
同時，不要忘記其他的framework同樣提供了很好的組件化的基礎架構如Spring，Pico-Container，在OSGi與其它技術混合時SCA同樣是很好的選擇。
保持應用的簡單性，不要針對特定技術進行設計，而要為設計選擇適合的技術。
蔡超
Chaocai2001@yahoo.com.cn
JEE咨詢顧問
SCEA(1.2&5)
IBM Certified OOA&D Solution Designer vUML2
厭倦了那些厚書（特別是那些為了賺錢而特意寫厚的書），很多時候這些書讓我們找不到技術要點，甚至喪失了學習的興趣，而最終變成那些拒絕新技術的“頑固派”。
其實掌握技術的最佳方式是實踐，在實踐中不斷的深入學習。
本教程旨在幫助哪些已經掌握了OSGi和Spring技術基礎的開發人員，迅速將Spring DM應用于實際開發，這是一份入門教程，不求全面，但求簡單。
并請配合本教程的實例代碼一同學習。
下載教程和示例:
http://www.tkk7.com/Files/chaocai/spring-osgi.rar
蔡超
JEE咨詢顧問
SCEA(1.2&5)
IBM Certified OOA&D Solution Designer vUML2
引言
分層結構是目前復雜應用系統開發時普遍使用的模式，軟件中層之間的依賴關系約束是比較寬松的，并不要求上層僅可以依賴于直接下層，而是上層可以依賴于它的所有下層。
設計中我們會把各種系統的各種組件映射至不同層中，而在我所接觸的一些實際項目中設計人員在映射這種組件和層間的關系時經常無意中破壞了層結構的依賴關系約束。
圖表 1 典型分層結構
設計中的常見問題
問題一:數據傳輸對象（DTO）是否應該屬于業務層？
在J2EE開發的經典著作《Core J2EE Patterns》中數據傳輸對象被劃分在業務層模式中，那么是否數據傳輸對象應該被映射到業務層呢？
數據訪問對象（DAO）在該著作中是被映射到整合層的，這樣就會出現一個違反層依賴約束的問題，因為數據訪問對象是要依賴于數據傳輸對象的，因此下層就會出現對上層的依賴了。
所以本人認為DTO是在各層中傳輸數據的，我們可以不必強求的把他們映射到上述層次中，可以把他們放置在一個公共包中。
問題二:使用POJO作業務對象的輕量級架構與上述層模型的映射
在使用POJO的輕量級結構中我們通常會使用持久化框架（如Hibernate/JPA）同時會在架構中引入倉庫對象(Repository Object)，負責業務對象的獲取和保存。（注意：他的功能和DAO是有區別的，倉庫對象中通常只應包括業務對象的獲取和保存邏輯）。
通常設計人員會把業務對象映射至業務層，而將倉庫對象映射至整合層。由于倉庫對象對于業務對象的依賴關系就會破壞依賴關系約束，所以這種映射方式顯然不正確。
下圖是作者推薦的映射方式
圖表 2 輕量級架構參考模型
可以看到業務對象和倉庫對象都被映射至業務層，而持久化框架被映射到了整合層。
總結
因此大家在設計過程中不要僅僅將分層結構留于形式，而要時刻注意設計是否符合這種架構模式，這樣才能真正發揮這種架構模式的優勢。
JavaEE 咨詢顧問
SCEA (1.2&5.0)
IBM Certified Solution Designer for OOA&D UML2
http://dev2dev.bea.com.cn/blog/chaocai/200801/soa_component_28_885.html
這個考試和原來的SCEA一樣分成三個部分
1 選擇，基礎知識
2 設計，
3 簡答
感覺Beta版比正式版難度大多了，題目數量特別多。而且設計題難度也大。