放棄使用OSGi方式
OSGi是什么
OSGi是一種服務(wù)運(yùn)行平臺(tái)。通過(guò)實(shí)現(xiàn)能夠提供服務(wù)的符合OSGi規(guī)范的組件，用戶(hù)可以將其組件發(fā)布到OSGi運(yùn)行平臺(tái)，供用戶(hù)和其他組件使用。
OSGi 組件提供的服務(wù)具有兩個(gè)層面的含義：系統(tǒng)層面，即一個(gè)組件為其他組件提供服務(wù)，這些服務(wù)體現(xiàn)為Java接口的實(shí)現(xiàn)；業(yè)務(wù)層面，即一個(gè)組件為外部系統(tǒng)或用戶(hù)提供某種業(yè)務(wù)服務(wù)實(shí)現(xiàn)。
51CTO編輯推薦：OSGi入門(mén)與實(shí)踐全攻略
記錄下傳統(tǒng)和OSGi方式的開(kāi)發(fā)方式的特點(diǎn)：
傳統(tǒng)方式的開(kāi)發(fā) ：
開(kāi)發(fā)時(shí)，要引入整個(gè)依賴(lài)包。整個(gè)系統(tǒng)為一個(gè)工程，里面包含了各個(gè)功能模塊。（假如不使用像maven之類(lèi)的工具管理模塊依賴(lài)的話，在eclipse中開(kāi)發(fā)確實(shí)是個(gè)比較頭疼的問(wèn)題）
OSGi方式的開(kāi)發(fā) :
模塊的依賴(lài)，只需要引入使用到的接口。不需要引入整個(gè)bundle。（基于eclipse 的插件開(kāi)發(fā)就是這種類(lèi)型）只需要將bundle部署到服務(wù)器上，即可為系統(tǒng)增加相應(yīng)的模塊支持熱拔插（其實(shí)這個(gè)功能，雖然很好，但是對(duì)于企業(yè)級(jí)開(kāi)發(fā)，感覺(jué)意義不大。對(duì)于嵌入式那就另當(dāng)別論了）
OSGi在很大的部分上也是對(duì)模塊的管理，開(kāi)發(fā)都是基于服務(wù)的，我覺(jué)得這樣很好，不過(guò)目前來(lái)說(shuō)，我覺(jué)得在企業(yè)級(jí)應(yīng)用里面使用還是為時(shí)過(guò)早。目前使用的maven 加 soa的方式已經(jīng)可應(yīng)對(duì)大多問(wèn)題了。
所以我最終決定目前放棄使用OSGi方式：
考察了OSGi很久，最終決定放棄使用該技術(shù)作為zog平臺(tái)的模塊管理框架。還是使用目前使用得很多的maven+soa進(jìn)行開(kāi)發(fā)。主要有以下考慮：
1.OSGi 目前不成熟。特別在B/S方面，因?yàn)榇蠖鄶?shù)應(yīng)用服務(wù)器都不支持OSGi，這樣讓部署很困難，而且目前已有的解決方案也不好。OSGi是底層的，我認(rèn)為他應(yīng)該在服務(wù)器級(jí)提供實(shí)現(xiàn)，或者jvm級(jí)實(shí)現(xiàn)。給應(yīng)用層增加一層OSGi是不明智的。
2.maven管理模塊的依賴(lài)目前還是很成熟了。maven的模塊管理是傳統(tǒng)意義的管理，即把包作為jar包導(dǎo)入引用工程。由于maven強(qiáng)大的包管理功能，使得包依賴(lài)問(wèn)題得到了解決。光從開(kāi)發(fā)這點(diǎn)上OSGi沒(méi)有明顯的優(yōu)勢(shì)，因?yàn)樵诨贠SGi開(kāi)發(fā)中，要引用其他包，必須在eclipse中把這些作為一個(gè)個(gè)工程打開(kāi)，其他工程才能引用它們（想想假如你有100個(gè)bundle的情況，就可想而知?。?。
3.假如光把OSGi作為zog平臺(tái)級(jí)開(kāi)發(fā)使用，而在開(kāi)發(fā)具體項(xiàng)目時(shí)采用普通開(kāi)發(fā)模式，咋樣呢？依據(jù)我目前掌握的OSGi知識(shí)來(lái)看，我不贊同這樣。首先問(wèn)題的原因也如同剛剛2所提到的，同時(shí)也考慮到zog平臺(tái)打包的問(wèn)題。你想想，bundle是按照功能來(lái)創(chuàng)建的，為了管理這些小東西，也會(huì)打開(kāi)很多的模塊工程。很麻煩。
4.以后等OSGi成熟了，轉(zhuǎn)換過(guò)程也很簡(jiǎn)單。不過(guò)前提是要對(duì)架構(gòu)設(shè)計(jì)好才行。
【編輯推薦】
