【目錄】- 【熱插拔與動態支持】-【概念】
“熱插拔和動態支持”應該算是OSGi.NET最有趣，最Cool的一個功能，官方文檔是這樣介紹的
1） 熱插拔：所有的模塊都可以被動態的添加和卸載。
2） 生命周期：模塊生命周期狀態由“已安裝、已解析、正在啟動、已激活、正在停止、已停止、已卸載”組成，每一個生命周期狀態下，模塊提供的功能都可能不同。
3） 動態：當模塊執行任何生命周期操作時，模塊會動態的想外界暴露或者隱藏它提供的功能，比如動態提供服務、擴展或者其它功能。
4） 遠程部署：支持模塊遠程部署，比如遠程安裝、啟動、停止和卸載模塊，或者訂閱模塊倉庫中模塊變更並同步。
正如我們前面一直強調的，理想情況下，OSGi.NET的模塊都是一個個可獨立，且無任何邏輯或物理聯系的個體，就像一塊塊的積木，可通過多種搭配方式進行組裝和卸載。“熱插拔”就是在這種大前提下實現模塊的“在線（live）”，或着說，“動態（Dynamic）”添加和卸載，這使得“遠程部署”成為可能。上一節“模塊可擴展支持”中的小結就很好的展示了熱插拔特性。
注意這里的“遠程部署”
1） 它是在線的，而不是離線，也就是不需要將程序關閉，用戶可在正常情況使用下，部署模塊
2） 由於ASP.NET的特殊性，需要將“運行時”重啟，但Web本身就是非持久性連接，處理恰當的話，對最終用戶影響不是很大。WinForm不受影響。
當然，OSGi.NET對模塊的處理並不是安裝和卸載這么簡單，他有前面我們已經提到過的“生命周期管理”，具體流程參照官方圖例
對上面每個模塊的“狀態”，都有其特定的用意，稍后我們會通過實例做展示。這里“停止（Stopping）”和“卸載（Uninstalled）”需要稍加說明一下，停止是模塊將自己的生命進程交還給運行時環境前最后的一個狀態，而卸載是運行時環境將模塊結束前的最后一個狀態。簡單來說
1） 安裝、解析、卸載只能由運行時環境來管理，而啟動、激活、停止是模塊本身可一同參與的
2） 停止的模塊依然在運行時環境管理中，只不過模塊不能再管理自己的狀態，但其他模塊可通過運行時環境對它進行控制
3） 卸載的模塊，在下次重啟並刪除之前，依然在運行時環境管理中
4） 安裝和啟動，類似卸載和啟動
5） 解析和具體的模塊加載過程，可參照前文“模塊化和插件化”實例部分
“動態”特性其實我們在前面的“面向服務架構支持”和“模塊可擴展支持”中已經見識過了，看看官方給的具體過程示意圖
接下來的實例中，我們將通過一個具體的例子來看看可能比較關注的“動態性配置”和遠程部署。
【目錄】- 【熱插拔與動態支持】-【實例】
我們繼續使用上一節“模塊可擴展支持”的實例，這一次不需要寫什么代碼，只需要少量的編輯一下XML。
OSGi.NET為每個模塊提供一個專門的配置來設定它的初始運行狀態，雙擊OSGi.NET.APEDecoderPlugin的Manifest.xml文件，可以看到如下界面
1） “當框架激活時立即啟動Bundle”，這個選項如果勾選上的話，則這個模塊（Bundle）會按照安裝、解析、啟動、激活順序執行。如果不勾選，則到安裝后就停止了，如果這個模塊還被其他模塊依賴，則會忽略這個配置，直接運行到激活。還需要注意，每次更改這個選項時，須將此模塊中的persistent.xml刪除掉，否則無法看到效果。persistent.xml用來記錄最后一次的初始化狀態。
a) 我們來試試不勾選它，來看看運行效果
可以看到APE選項並沒有出現，再打開“遠程管理工具”，輸入字母l
OSGi.NET.APEDecoderPlugin的狀態為Installed，安裝。我們繼續輸入s 5
回到主程序，點擊回車
APE便回來了。
b) 當然你可以通過編碼的方式將它啟動起來，例如
2） 當存在“激活器”時，還可以選擇“晚激活，即當Bundle的類被加載是再激活”。這個有點兒類似.NET的晚激活策略，也就說如果勾選，則模塊會從安裝到解析便停止執行，而當別的模塊需要引用它的某個類時會自動繼續執行啟動和激活，理論上可以減少不必要的消耗。
接下來我們繼續使用這個例子，來演示一下如何完成“遠程部署”
1） 首先，我們將整個OSGi.NET.APEDecoderPlugin文件夾壓縮成zip包后刪除這個文件夾。壓縮包放到一個稍后可以訪問到的位置，如D:\
2） 運行起整個主程序，默認的APE選項將不會出現。接着我們打開“遠程管理工具”，輸入字母l，這時也沒有OSGi.NET.APEDecoderPlugin。保留着主程序不要關閉它。
3） 在遠程管理工具里輸入i "OSGi.NET.APEDecoderPlugin" "D:\OSGi.NET.APEDecoderPlugin.zip" "D:\cnblogs.com\OSGi.NET\Demo4\OSGi.NET.AudioPlayerShell\OSGi.NET.AudioPlayerShell\bin\plugins\FormatTypes\Lossless\OSGi.NET.APEDecoderPlugin"，並回車，可以看到提示已經安裝成功
再次輸入字母l
OSGi.NET.APEDecoderPlugin處於安裝（installed），而非激活（Active），還需要啟動它，繼續輸入s 6
OSGi.NET.APEDecoderPlugin啟動成功，在主程序中點擊回車
APE選項出現了。
【目錄】- 【熱插拔與動態支持】-【小結】
熱插拔和動態支持本身就是最開始提到的“模塊化和插件化”的最佳體現。基於模塊化和插件化才使得“熱插拔和動態支持”成為可能。
面對前陣子有人提出了對OSGi的質疑，想說
1） 程序員都這樣，當你想使用某種技術和思想的時候，你會想盡辦法去說它如何如何好，找很多相關的資料來證明它的好，反之，你不喜歡它也是一樣，你會研究，反駁等等，這其實是件好事情，讓更多人了解它的多方面OSGi和其他技術一樣，都有他的適用場景和最佳實踐方法，在宣傳人員的嘴里你是很少聽他們說這些的，反之，在反駁的時候你會聽到很多他“不怎么”適合的地方。
2） 一種技術或者一種思想方法適合不適合我們，並不會影響它的本質，它是好，還是壞，都是通過我們的質疑，質疑，反復質疑中建立起來的，但他如何的好，如何的壞都是我們自己去實踐和體會的
3） 當大多數人都在追捧某件技術或者思想的時候，你可以看到很多優秀的想法，或許也會看到不少糟粕，但這種認知不會是一塵不變的，他會隨着我們對問題的深入了解而隨時改變。與此同時，技術和思想也在不斷放生變化，去適應大多數人的需求，這種變化總是超前與我們對它的定論，這才是學習技術的美妙之處
針對質疑中的一個論點，“動態替換模塊，前提是不丟失運行時數據，否則就是空談。OSGi 官網、文檔從未提到可以替換正在忙碌中的模塊。問題是，如果是替換不忙的模塊，非要用 OSGi 么？我可以把應用系統停下來，更新版本，重新啟動新版本軟件，然后喝杯咖啡，眯會兒眼睛，...”，可以這么看
1） 丟不丟數據、模塊忙不忙取決你的設計策略，該不該更新、什么時候更新、怎么更新屬於你的部署策略，總體來說部署策略受設計策略約束，所以好的設計策略可以讓看起來不太可能的部署策略得以實現。當然，最重要是看你有沒有這種需求。
2） 部署策略也有很多種，人工復制粘貼，自動化腳本，補丁程序等等都可以，技術上沒有什么優劣，但用戶體驗上卻有不同。有的情況下，你快遞給用戶一個U盤，讓他自己復制再粘貼，也是可是被接受的，但如果客戶端是在成千上萬台分布全球的PC上時，就不能不考慮成本問題了
3） 即便都是統一的在線更新策略，典型的就是Windows Update，它也分更新完，需要重啟系統和不需要重啟系統。當然你可以設置你的更新策略是必須全部重啟更新。但對於用戶來說減少了一次不需要的重啟，是不是用戶體驗會更好些呢？畢竟有些更新的確不需要重啟的
4） 其次，用戶最看重的必然是功能和體驗，而作為產品的研發設計人員，您是否應該考慮不僅僅是完成某些功能，而且能讓你這個功能有着最佳的體驗？技術上對我們來說不是問題，問題是這里不完全是技術。如果需要考慮OSGi的時候，肯定不能只關注他技術上實現了什么，還得知道這種技術能改善什么
5） 需要強調的是，OSGi並不是一個簡單的模塊化框架，還是一種思考問題和解決問題的方式。既然是方式，那他就是條條大路通羅馬中的一條，不需要高估他，也不需要低估他，因為他自有他合適的地方
在稍后的“高級話題”中，我們會結合具體的實例來繼續探討，如何更好，更恰當的運用OSGi.NET來分析和解決我們的問題。