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