看了下BlueDavy的OSGi實戰(zhàn)這篇OpenDoc，很感謝BlueDavy同學(xué)！
例子舉的是一個User Login的Case，例子很簡單，讓我們從中領(lǐng)略了OSGi的風(fēng)情。這個Doc中的例子都是圍繞Equinox展開的，它是Eclipse 3.1以后的核心實現(xiàn)，也就是說現(xiàn)在的Eclipse是個OSGi架構(gòu)。
從架構(gòu)上來說OSGi和SOA如出一轍，都強調(diào)面向服務(wù)，而OSGi似乎對熱切換和契約管理比較著重，也就是說OSGi更現(xiàn)實，它強調(diào)的是一種實際的合約標(biāo)準(zhǔn)。產(chǎn)生的結(jié)果是差不多的，就是系統(tǒng)模塊之間的高度解藕。
可以看OSGi的Core Framework，最內(nèi)層是L0：運行環(huán)境（就是語言平臺或者解釋平臺一類的環(huán)境），然后是OSGI的L1：模塊，L2：生命周期管理，L3：服務(wù)注冊。
我認(rèn)為這種架構(gòu)也基本上是一個SOA需要關(guān)注的幾個問題。
L1是實現(xiàn)OSGi的基礎(chǔ)，在Java下提供了類加載機制，使系統(tǒng)能夠模塊化。個人感覺類似原來Eclipse中的微內(nèi)核。
L2是解決模塊之間依賴關(guān)系的最基本工作單位，負(fù)責(zé)初始化、停止、更新等操作，這樣模塊能夠活起來，同時在這些過程中可以手動維護(hù)依賴關(guān)系，也是模塊協(xié)作的基礎(chǔ)。
L3則是協(xié)作的合同簽署場所，應(yīng)該是L2的擴(kuò)展，使模塊之間能夠按照契約工作。我覺得更形象地說就是路由器，模塊間的動態(tài)依賴可以很好地通過它來解決，讓OSGi可以動起來。
擁有了這幾層，我想我們完全可以理解為一個SOA的實現(xiàn)，當(dāng)然更細(xì)化。應(yīng)該是一種新的組合應(yīng)用的方式。
白嘴說肯定沒有BlueDavy的文章好，大家還是去看看那篇文檔。
說說遺憾：
1、OSGi在B/S架構(gòu)中還不好應(yīng)用。雖然例子是B/S的，可是居然是Servlet模型，里面解釋了目前Equinox項目也在擴(kuò)展應(yīng)用服務(wù)器支持和JSP支持等，可是起碼目前還不成熟。
2、模塊的粒度很成問題。目前OSGi的契約機制與java interface機制對比一下。OSGi不可能完全取代本地的interface式的解藕，當(dāng)然人家也沒這么說。只使我擔(dān)心過渡設(shè)計后，過細(xì)的Bundle肯定會得不償失，所以需要有人設(shè)計/計劃這個粒度。這個可能與基于Web services的SOA架構(gòu)面臨類似的問題，需要好的架構(gòu)師。
3、文檔不友好么？說實話，很感謝BlueDavy和OSGi觀察者那些大牛的貢獻(xiàn)。但是感覺production的樣例工程還是很難搞到（其實Eclipse plugins的例子滿多哈，可惜沒啥文檔，需要硬著頭皮看），對應(yīng)的指導(dǎo)文檔還沒出現(xiàn)。BlueDavy提供的servlet實現(xiàn)我們不可能跟上，畢竟簡單也是一種需求。（那誰說過度設(shè)計比設(shè)計不足更可怕，那個我不是唱反調(diào)，我希望我們都能找到那個sweet point，有個好的參照那最好不過了）。
4、由于思想先進(jìn)，在某些人看來是陽春白雪。估計不少人還是埋頭下里巴人。觀望態(tài)度。
結(jié)束，又是流水賬，大家拍磚。