10 2007 檔案
摘要: 上次發布OSGi in action的PPT后，得到了flyisland的反饋意見，:)，在此也謝謝他，正是從他的意見中看到了之前PPT的一些問題，之前PPT的問題應該是目標聽眾不明確，講的內容多但卻都不詳細，很有可能最后講完了無論是對于OSGi Newer還是OSGi熟悉的人都沒有什么任何的幫助，為了解決這個PPT，決定把PPT分為兩篇來完成，一篇為OSGi Newer編寫的關于OSGi介紹方面的PPT，將名字定為了Introduce OSGi，重點的介紹OSGi的基礎概念和基本的使用方法；而另外一篇則是為較為OSGi的同學們編寫的，名字仍然保持為OSGi in action，會重點和較為詳細的講解OSGi在實際項目的使用，目前先發布Introduce OSGi的PPT，希望能繼續得到大家的反饋意見，感興趣的同學們可以從這下載這篇PPT：
http://www.riawork.org/opentopic/Introduce.OSGi.ppt
閱讀全文
摘要: 在我現在的項目中出現了這么兩個問題，大家可以來探討下這樣的兩個問題的解決方法，:)
1、從開發環境到正式環境的部署/校驗非常麻煩；
2、數據庫的頻繁移植/校驗非常麻煩。
我的解決方法：
對于上面兩個問題，我自己想到的解決方法是：
1、建立持續集成機制，編寫環境部署腳本和文檔，采用這兩種方法可保證從開發環境到正式環境的部署是非常簡單的；
編寫自動驗收測試腳本，可以基于Selenium進行編寫，這樣每次在升級版本的時候就不需要再人工的進行回歸測試了，這里面的問題是如何在測試完畢完畢后清除這些測試數據，因為這些測試數據是不能和正式數據共存的。
2、建立數據庫升級移植機制，每次升級時做增量的升級，不過這需要建立在對原庫建立版本記錄，這個方法對于我們的項目而言不太可行；
第二種方案就只能每次進行全面的重新移植了，但這個帶來的一個巨大問題就是存儲過程的重復修改，目前我還沒想到什么解決方法，而且；
至于如何校驗數據庫移植是否成功，我覺得可以建立數據庫移植校驗的Checkpoint，除了保證數據庫結構、數據量等的
閱讀全文
摘要: 這個PPT將會用于最近的一些OSGi活動作為Topic來講講，不過是英文版的，:)，一方面是鍛煉自己的英文，另一方面也準備把這PPT再雕磨雕磨，提交到OSGiDevCon 2008的Topic中試試。
感興趣的朋友請從以下地址下載此PPT：
http://www.osgi.org.cn/opentopic/OSGi.in.action.ppt
不過俗話說，PPT嘛，靠的主要是講，但同時也希望得到大家對此PPT的反饋意見，以便我進行進一步的修改，希望在之后的公開的活動中不會把這Topic講砸了，此PPT會不斷的進行修改，我會在此篇blog中公布目前ppt的版本號，大家就可以確認手頭的PPT是否是最新的了，:)。
version info:
1.0 2007-10-21
閱讀全文
摘要: 在歷時兩個多月后，OSGi進階的編寫已完畢，感謝N多朋友一直以來的關注和支持，現將正式版對外發布，下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2.pdf
隨文的代碼的下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2-source.zip
隨文的例子的可運行版本的下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2-dist.zip
隨后將會相繼在Redsaga上發布Redsaga Opendoc版本，以及在InfoQ中國站上發布InfoQ miniBook版本，這兩個版本在精美程度上都會超過我現在發布的版本，到時再給予大家通知，:)
閱讀全文
摘要: 軟件架構的選擇和設計并不是很容易做出的，一個成功的軟件架構取決于N多的因素，軟件架構這個詞向來就是最為模糊的一個詞，個人認為軟件架構實在是個很大的話題，業界一直采用的形象比喻就是建設房子時的房屋結構圖，以軟件的角度來說，軟件架構應至少包括軟件開發時使用什么語言、形成軟件開發時可運行的核心基礎框架、軟件應用模塊的設計（包括模塊內聚的功能、對外提供的服務等）、軟件測試的方法、軟件部署的方法以及團隊開發的方法，那么怎么來選擇和設計軟件架構呢，其衡量的因素是什么呢，個人認為其中質量和快速是衡量軟件架構的選擇和設計是否成功的兩個最重要的因素。
閱讀全文
摘要: OSGi在應用時具備了典型的微核系統的特點，但對于實際項目/產品型的應用而言，這個微核有些過于底層了，為什么這么說呢？
對于實際項目/產品型的應用而言，何謂其微核呢，應該說其腳手架或開發平臺才是它的微核，而并非僅僅是OSGi框架，當然，也可以將自己的腳手架或開發平臺以Fragment-Host的方式綁定到OSGi的System Bundle上去，但這樣的做法無疑有些evil了，TPF誕生的最主要的目的就是形成一個應用級的微核的概念，使得我們在管理實際的項目和產品時，能夠將腳手架和實際的業務應用模塊分離管理，讓腳手架也變成微核，這樣在管理時就可以做到對應用系統的統一管理，而同時保持一個含應用意義的微核（也可以認為是開發平臺）的穩定運行，在具備了TPF的情況下，就可以將應用系統從部署上分為腳手架和應用系統，而在管理上也可以單獨對應用系統進行管理，如啟動應用系統、停止應用系統，同時避免應用開發人員對腳手架無意的修改。
在本篇文檔中將介紹TPF提供的功能、TPF實現的方法以及TPF的下載地址。
閱讀全文