模塊的組織
OSGi不會出現(xiàn)需要引用其他模塊Bundle的情況，只需引用接口。
模塊的復(fù)用和擴展
只需要將Bundle部署上去即可為系統(tǒng)增加相應(yīng)的模塊。
OSGi吸取了Eclipse
plugin中Extension Points的思想。
Equinox作為OSGI
R4的RI，Equinox除了完整實現(xiàn)OSGI R4規(guī)范外，最重要的就是Extension Registry，它是Eclipse插件機制中關(guān)鍵的部分，它為插件的擴展提供了一種實現(xiàn)的機制。Bundle通過發(fā)布擴展點的方式來定義Bundle可擴展的部分，當(dāng)需要擴展Bundle的時候只需要實現(xiàn)Bundle提供的擴展點的接口就可以了。
如果開發(fā)要保證符合OSGI標(biāo)準(zhǔn)，那么就不要使用Equinox對于OSGI的擴展，這個在使用Eclipse進行開發(fā)時可以指定僅使用標(biāo)準(zhǔn)的OSGI框架。
可插拔的系統(tǒng)
可通過安裝新的Bundle、更新或停止現(xiàn)有的Bundle來實現(xiàn)系統(tǒng)功能的插拔。
可插拔、可動態(tài)改變行為從根本上保證了系統(tǒng)在運行期足夠的靈活性和擴展性。
穩(wěn)定、高效的系統(tǒng)
OSGI采用微核機制，微核機制保證了系統(tǒng)的穩(wěn)定性，微核機制的系統(tǒng)只要微核是穩(wěn)定運行的，那么系統(tǒng)就不會崩潰，基于OSGI的系統(tǒng)不會受到運行在其中的Bundle的影響，不會因為Bundle的崩潰而導(dǎo)致整個系統(tǒng)的崩潰。
延遲加載，只有在請求發(fā)生時OSGI才去完全加載、啟動相應(yīng)的Bundle、Service。
規(guī)范的、可積累的模塊
基于OSGI的系統(tǒng)采用規(guī)范的模塊開發(fā)、部署方式構(gòu)建系統(tǒng)。
OSGI框架是一個微核結(jié)構(gòu)的容器，所有的模塊都需要運行在容器范圍內(nèi)，在OSGI中所有模塊的部署都必須以Bundle的方式來進行部署
Bundle就是一個jar文件，在OSGI框架中是采用Bundle的方式來組織和部署系統(tǒng)的。Bundle通過實現(xiàn)BundleActivator接口去控制其生命周期，在Activator中編寫Bundle啟動、停止時所需要進行的工作，同時也可以在Activator中發(fā)布或者監(jiān)聽框架的事件狀態(tài)信息，以根據(jù)框架的運行狀態(tài)做出相應(yīng)的調(diào)整。BundleActivator類是可以不需要的，建議不要在BundleActivator中初始化過多的東西，這樣會使得系統(tǒng)的啟動速度會變得很慢，同時也會消耗大量的內(nèi)存。
在OSGI框架中對于每個Bundle采用的是獨立的classloader機制。借助使用Bundle的元數(shù)據(jù)來實現(xiàn)工程之間package的共享。
? 在OSGI框架中對于每個Bundle可以定義輸出的包以及引用的包，這樣在Bundle間就可以共享包中的類了，直接實現(xiàn)簡單的Bundle的協(xié)作。
? Bundle采用Require-Bundle的方式來直接引用其他的Bundle
? 每個Bundle可以通過BundleContext注冊對外提供的服務(wù)，同時也可以通過BundleContext來獲得需要引用的服務(wù)。和Import-Package、Require-Bundle不同的地方在于通過Service獲取的是其他Bundle中類的實例。
OSGI R4規(guī)范
Module Layer
Bundle的元數(shù)據(jù)屬性的值，都支持增加附加過濾屬性的方式：版本過濾、Bundle元數(shù)據(jù)信息過濾、自定義屬性過濾
Lifecycle Layer
Bundle的狀態(tài)：
? INSTALLED
Bundle已經(jīng)成功的安裝了。
? RESOLVED
Bundle中所需要的類都已經(jīng)可用了，RESOLVED狀態(tài)表明Bundle已經(jīng)準(zhǔn)備好了用于啟動或者說Bundle已被停止。
? STARTING
Bundle正在啟動中，BundleActivator的start方法已經(jīng)被調(diào)用，不過還沒返回。
? ACTIVE
Bundle已啟動，并在運行中。
? STOPPING
Bundle正在停止中，BundleActivator的stop方法已經(jīng)被調(diào)用，不過還沒返回。
? UNINSTALLED
Bundle已經(jīng)被卸載了。
管理Bundle的狀態(tài)時，OSGI主要是通過Bundle、BundleContext這兩個對象來實現(xiàn)。
Service Layer
Service通過BundleContext完成注冊和獲取。
Declarative
Services(聲明式服務(wù))
Component
? 對外提供Service；
? 使用其他Component提供的Service；
? 交由OSGI框架管理生命周期。
Service的發(fā)布和引用，component.xml
模塊化設(shè)計
真正意義的模塊化，模塊的設(shè)計更加的完善和規(guī)范
面向服務(wù)的組件模型設(shè)計
面向服務(wù)的組件模型設(shè)計則是對模塊進行詳細(xì)設(shè)計時的核心思想。
Component通過引用Service或暴露Service來完成模塊中用例的實現(xiàn)，面向服務(wù)的組件模型設(shè)計更加強調(diào)在設(shè)計時分解模塊中用例的實現(xiàn)（形成組件和服務(wù)）以及組件依賴的關(guān)注。
動態(tài)性設(shè)計
要充分的發(fā)揮基于OSGI的動態(tài)性，就要完全的采用面向接口的設(shè)計方式，而不是去依賴實現(xiàn)，要記住基于OSGI搭建的系統(tǒng)是在運行期才構(gòu)成依賴的。設(shè)計基于OSGI的系統(tǒng)時特別要注意依賴不要在設(shè)計時就定死
面向接口的開發(fā)
OSGI為每個Bundle提供獨立的ClassLoader機制，使得基于OSGI的系統(tǒng)讓我們在開發(fā)時真正的做到面向接口的開發(fā)。
在基于OSGI框架進行開發(fā)時應(yīng)該養(yǎng)成對外Export接口的packages，而隱藏實現(xiàn)接口的packages，更為好的方法就是把接口單獨的放入一個Bundle中，這樣對于更換接口的實現(xiàn)就更為方便了。