OSGI聯(lián)盟的初始目標(biāo)是構(gòu)建一個(gè)在廣域網(wǎng)和局域網(wǎng)或設(shè)備上展開業(yè)務(wù)的基礎(chǔ)平臺(tái)，對(duì)OSGI的最早設(shè)計(jì)也是針對(duì)嵌入式應(yīng)用的，諸如機(jī)頂盒、服務(wù)網(wǎng)關(guān)、手機(jī)、汽車等都是其應(yīng)用的主要環(huán)境。

　　由于OSGI的諸多優(yōu)秀特性（可動(dòng)態(tài)改變系統(tǒng)行為，熱插拔的插件體系結(jié)構(gòu)，高可復(fù)用性，高效性等等），它被應(yīng)用于許多PC上的應(yīng)用開發(fā)，因此逐步為開發(fā)者所知和鐘愛?，F(xiàn)在人們對(duì)OSGI的理解已經(jīng)遠(yuǎn)遠(yuǎn)不是它字面和初衷所能解釋的了，稱其為一個(gè)輕巧的、松耦合的、面向服務(wù)的應(yīng)用程序開發(fā)框架更為確切一些。

　　OSGI發(fā)展到今天已經(jīng)得到了眾多企業(yè)、廠商、開源組織的支持，主流的Java應(yīng)用服務(wù)器（Oracle的Weblogic、IBM的Websphere及Sun的Glassfish等)都已經(jīng)采用了OSGI。OSGi作為Java模塊化標(biāo)準(zhǔn)已成為事實(shí)。

　　OSGI著名案例

　　Eclipse作為Java業(yè)界成功的IDEproject，在3.0以前的版本它采用的是自己設(shè)計(jì)的一套插件體系結(jié)構(gòu)，而Eclipse的插件體系結(jié)構(gòu)在整個(gè)業(yè)界都是非常知名的，也是被認(rèn)為非常成功的一種設(shè)計(jì)，但Eclipse在3.0版本時(shí)卻做了一個(gè)重大決度，就是推翻它自己以前的插件體系結(jié)構(gòu)，采用OSGI作為其插件體系結(jié)構(gòu)。Eclipse之所以要拋棄自己那套已經(jīng)比較成熟的插件體系結(jié)構(gòu)而轉(zhuǎn)而采用OSGI，就是因?yàn)镺SGI的規(guī)范性以及OSGI對(duì)于插件體系結(jié)構(gòu)更為完整的定義，Eclipse采用OSGI作為其插件體系結(jié)構(gòu)的成功是很明顯的，在Eclipse 3.1版本以后大家可以明顯的感覺到啟動(dòng)速度的提升，同時(shí)也使得可以在運(yùn)行時(shí)對(duì)插件進(jìn)行管理，更明顯的提升是插件的開發(fā)更加的規(guī)范，從而可以使用很多已有的OSGI插件。

　　BMW汽車的應(yīng)用控制系統(tǒng)采用OSGI作為其底層架構(gòu)，很多人都認(rèn)為基于java的系統(tǒng)低效，不可能用于汽車這樣的應(yīng)用控制系統(tǒng)上。這套系統(tǒng)主要用來控制汽車上的音箱、燈光等等設(shè)備，總共由1000多個(gè)Bundle構(gòu)成，但BMW汽車的應(yīng)用控制系統(tǒng)啟動(dòng)時(shí)間卻只需要3.5秒，這也從很大程度上反應(yīng)了采用OSGI的系統(tǒng)的效率并不會(huì)低。

　　OSGI優(yōu)點(diǎn)

　　第一點(diǎn)，基于OSGI的應(yīng)用程序可動(dòng)態(tài)更改運(yùn)行狀態(tài)和行為。在OSGI框架中，每一個(gè)Bundle實(shí)際上都是可熱插拔的，因此，對(duì)一個(gè)特定的Bundle進(jìn)行修改不會(huì)影響到容器中的所有應(yīng)用，運(yùn)行的大部分應(yīng)用還是可以照常工作。當(dāng)你將修改后的Bundle再部署上去的時(shí)候，容器從來沒有重新啟過。這種可動(dòng)態(tài)更改狀態(tài)的特性在一些及時(shí)性很強(qiáng)的系統(tǒng)中尤其重要。

　　第二點(diǎn)，它是一個(gè)穩(wěn)定高效的系統(tǒng)。OSGI是一個(gè)微核的系統(tǒng)，所謂微核是指其核心只有為數(shù)不多的幾個(gè)jar包。基于OSGI框架的系統(tǒng)可分可合，其結(jié)構(gòu)的優(yōu)勢(shì)性導(dǎo)致具體的Bundle不至于影響到全局，不會(huì)因?yàn)榫植康腻e(cuò)誤導(dǎo)致全局系統(tǒng)的崩潰。

　　第三點(diǎn)，可復(fù)用性強(qiáng)。OSGI框架本身可復(fù)用性極強(qiáng)，很容易構(gòu)建真正面向接口的程序架構(gòu)，每一個(gè)Bundle都是一個(gè)獨(dú)立可復(fù)用的單元。

　　OSGI缺點(diǎn)

　　管理端不夠強(qiáng)大目前OSGI框架提供的管理端不夠強(qiáng)大，現(xiàn)在的管理端中僅提供了基本的Bundle狀態(tài)管理、日志查看等功能，像動(dòng)態(tài)修改系統(tǒng)級(jí)別的配置(config.ini)、動(dòng)態(tài)修改Bundle的配置(Manifest.mf)、啟動(dòng)級(jí)別等功能都尚未提供，而這些在實(shí)際的項(xiàng)目或產(chǎn)品中都是非常有必要的。

　　采用OSGI作為規(guī)范的模塊開發(fā)、部署方式自然給現(xiàn)有開發(fā)人員提出了新的要求，需要學(xué)習(xí)新的基于OSGI的開發(fā)方式

　　什么是Bundle

　　在OSGI框架中是采用Bundle的方式來組織和部署系統(tǒng)的

　　Bundle其實(shí)就是一個(gè)jar文件，這個(gè)jar文件和普通的jar文件唯一不同的地方就是Meta-inf目錄下的MANIFEST.MF文件的內(nèi)容，關(guān)于Bundle的所有信息都在MANIFEST.MF中進(jìn)行描述，可以稱它為bundle的元數(shù)據(jù)，這些信息中包含有象Bundle的名稱、描述、開發(fā)商、classpath、需要導(dǎo)入的包以及輸出的包等等

　　Bundle是個(gè)獨(dú)立的概念，在OSGI框架中對(duì)于每個(gè)Bundle采用的是獨(dú)立的classloader機(jī)制，這也就意味著不能采用傳統(tǒng)的如引用其他Bundle的工程來實(shí)現(xiàn)Bundle間的協(xié)作了，那么在OSGI框架中Bundle之間是怎么協(xié)作的呢，在OSGI框架中對(duì)于每個(gè)Bundle可以定義輸出的包以及引用的包，這樣在Bundle間就可以共享包中的類了，盡管這樣也可以直接實(shí)現(xiàn)簡(jiǎn)單的Bundle的協(xié)作，但在OSGI框架中更加推薦的是采用Service的方式，Service-Oriented的概念(例如SOA)大家都接觸多了，OSGI框架也同樣是如此的，每個(gè)Bundle可以通過BundleContext注冊(cè)對(duì)外提供的服務(wù)，同時(shí)也可以通過BundleContext來獲得需要引用的服務(wù)，采用Service-Oriented的方式可以使得對(duì)外提供的服務(wù)能夠更加的封閉，不需要為了使用別的Bundle提供的Service而做環(huán)境依賴等的設(shè)置，同時(shí)，Bundle還可以采用Require-Bundle的方式來直接引用其他的Bundle（相當(dāng)于引用其他Bundle的工程或jar）。

　　主要的開源OSGI框架

　　Equinox

　　最知名，也是更新最頻繁的，由于Eclipse基金的支持，其功能越來越完善，實(shí)現(xiàn)了OSGi R4規(guī)范，并提供很多平臺(tái)性質(zhì)的服務(wù)，包括：常用功能模塊、日志模塊、Web服務(wù)器模塊、Servlet模塊、JSP解析模塊等等。由于其與Eclipse的天然聯(lián)系，使得開發(fā)基于Equinox的應(yīng)用程序變得很簡(jiǎn)單。Eclipse 3.1之后的版本，Eclipse 本身就已經(jīng)包含了Equinox。

　　遵循EPL (The Eclipse Public License)，任何擴(kuò)展自Eclipse源碼的代碼也必須是開源的,商業(yè)軟件可以使用，也可以修改代碼，但要承擔(dān)代碼產(chǎn)生的侵權(quán)責(zé)任。

　　Knopflerfish

　　很早的，也很優(yōu)秀的一個(gè)OSGI框架，也實(shí)現(xiàn)了OSGI R4標(biāo)準(zhǔn)。該項(xiàng)目的宗旨在于創(chuàng)建一個(gè)易于開發(fā)的OSGI平臺(tái)，與Equinox不同之處在于它本身提供一些小應(yīng)用實(shí)例，包括一個(gè)可視化控制臺(tái)等，也提供基于Eclipse的插件。

　　遵循Knopflerfish License (BSD-esque) http://www./license.html

　　商業(yè)軟件可以使用，也可以修改使用BSD協(xié)議的代碼

　　Felix

　　很新的一個(gè)OSGi框架，社區(qū)很活躍，更新頻率高，是Apache的開源項(xiàng)目。該項(xiàng)目2007年8月才出1.0 版，也實(shí)現(xiàn)了OSGiR4規(guī)范，也提供相關(guān)的基礎(chǔ)服務(wù)和擴(kuò)展服務(wù)功能。

　　Felix也有了Eclipse集成支持，開發(fā)者可以在Eclipse IDE里運(yùn)行Felix。

　　Felix組件按照Apache軟件許可證2.0（Apache Software License Version 2.0）來發(fā)布許可。

　　Apache Licence也是對(duì)商業(yè)應(yīng)用友好的許可。使用者也可以在需要的時(shí)候修改代碼來滿足需要并作為開源或商業(yè)產(chǎn)品發(fā)布/銷售。商業(yè)軟件可以使用，也可以修改使用Apache協(xié)議的代碼。 
與流行框架的結(jié)合

　　Spring-DM指的是Spring Dynamic Modules。Spring-DM的主要目的是能夠方便地將Spring框架和OSGi框架結(jié)合在一起，使得使用Spring的應(yīng)用程序可以方便簡(jiǎn)單地部署在OSGi環(huán)境中，利用OSGi框架提供的服務(wù)，將應(yīng)用變得更加模塊化。

　　附錄

　　BSD開源協(xié)議（Felix遵守的許可證協(xié)議）

　　BSD開源協(xié)議是一個(gè)給于使用者很大自由的協(xié)議?？梢宰杂傻氖褂?，修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發(fā)布。當(dāng)你發(fā)布使用了BSD協(xié)議的代碼，或則以BSD協(xié)議代碼為基礎(chǔ)做二次開發(fā)自己的產(chǎn)品時(shí)，需要滿足三個(gè)條件：

　　1. 如果再發(fā)布的產(chǎn)品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協(xié)議。

　　2. 如果再發(fā)布的只是二進(jìn)制類庫/軟件，則需要在類庫/軟件的文檔和版權(quán)聲明中包含原來代碼中的BSD協(xié)議。

　　3. 不可以用開源代碼的作者/機(jī)構(gòu)名字和原來產(chǎn)品的名字做市場(chǎng)推廣。

　　BSD代碼鼓勵(lì)代碼共享，但需要尊重代碼作者的著作權(quán)。BSD由于允許使用者修改和重新發(fā)布代碼，也允許使用或在BSD代碼上開發(fā)商業(yè)軟件發(fā)布和銷售，因此是對(duì)商業(yè)集成很友好的協(xié)議。而很多的公司企業(yè)在選用開源產(chǎn)品的時(shí)候都首選BSD協(xié)議，因?yàn)榭梢酝耆刂七@些第三方的代碼，在必要的時(shí)候可以修改或者二次開發(fā)。

　　Apache Licence 2.0（knopflerfish遵守的許可證協(xié)議）

　　ApacheLicence是著名的非盈利開源組織Apache采用的協(xié)議。該協(xié)議和BSD類似，同樣鼓勵(lì)代碼共享和尊重原作者的著作權(quán)，同樣允許代碼修改，再發(fā)布（作為開源或商業(yè)軟件）。需要滿足的條件：

　　1. 需要給代碼的用戶一份Apache Licence

　　2. 如果你修改了代碼，需要再被修改的文件中說明。

　　3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協(xié)議，商標(biāo)，專利聲明和其他原來作者規(guī)定需要包含的說明。

　　4. 如果再發(fā)布的產(chǎn)品中包含一個(gè)Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現(xiàn)為對(duì)Apache Licence構(gòu)成更改。

　　ApacheLicence也是對(duì)商業(yè)應(yīng)用友好的許可。使用者也可以在需要的時(shí)候修改代碼來滿足需要并作為開源或商業(yè)產(chǎn)品發(fā)布/銷售。