根據上一篇
服務框架的要素的blog，來分析下基于OSGi實現一個這樣的服務框架時需要對目前的OSGi框架做出哪些方面的修改，以及預估一下實現的難度。
1、如何注冊服務
OSGi服務采用的是xml+pojo的方式，應該說還是符合要求的，但如果要把這個服務注冊到一個服務中心的話，目前是不支持的，但這個對于分布式部署服務的需求而言，是必須實現的了。
要實現注冊服務至遠程的服務中心，這個可以通過編寫一個監聽服務生命周期變化的對象來實現，當監聽到服務的生命周期發生變化時，發送消息至遠端的服務中心，這里也就需要做出一個服務中心和各OSGi應用與服務中心遠程通訊的機制（消息機制、RPC機制、Webservice機制等等）。
2、如何調用服務
調用服務涉及的點比較的多，來看看基于OSGi如何來實現所有的需求：
injection方式和顯示調用方式
OSGi支持injection方式的調用服務，在顯示調用方式方面，OSGi不支持在OSGi框架范圍外的顯示調用，這個是有一定的不足的，因為這樣會導致和第三方框架集成的復雜，不過由于目前有了Spring-OSGi，所以呢，可以選用Spring-OSGi，這樣就兩種方式都支持了，如果不想使用Spring-OSGi的話，那么可以選擇查看OSGi框架的代碼，找出顯示調用的實現方法。
另外一個就是可以通過服務中心來實現顯示的服務調用和injection方式。
本地調用和遠程調用的區別
OSGi并不支持遠程服務的調用，在《OSGi進階》Opendoc中我曾經寫過基于webservice調用的方式，但這個對于高性能的分布式調用時其實是不可用的，要屏蔽本地調用和遠程調用的區別，就得在現有的DS模型的基礎上做改進了，需要支持引用服務時從當前的OSGi環境中或從服務中心中注冊了，這個需要對現有的OSGi框架的DS實現做出改進，才能做到屏蔽本地調用和遠程調用的區別，就可以僅僅通過在xml中做動作就可以了。
同步調用和異步調用
這個不用說，目前OSGi自然也是不支持的，只能是對DS的實現進行改進了，增加服務的同步調用和異步調用的支持，同步調用的話就沒什么改動的了，異步調用的話就得對ds做比較大的改動了，注入引用的服務時注入的不能像目前的ds實現一樣直接注入服務實例對象了，而是只能注冊一個proxy對象了。
lazy式的調用和固定的引用調用
lazy式的調用目前OSGi并不支持，只能是自己對DS進行改動了，在引用遠程服務和異步調用時，lazy調用是非常重要的。
至于查找服務方面，這個OSGi目前的模型就可以了，只是要增加查找服務中心服務的功能，這個在修改DS實現調用遠程OSGi服務時會去實現。
在服務的安全性等方面這個也只能基于DS擴展實現了。
3、如何測試服務
由于OSGi的服務是POJO的方式，在服務的測試方面是完全不會有問題的。
4、服務的生命周期
在服務的生命周期方面，我想OSGi服務目前的機制就是不錯的，即如果當前這個服務組件是對外暴露服務的，那么只有當其被引用且其本身所引用的服務可用時才被激活，如組件沒有對外暴露服務，那么只需其引用的服務可用就可激活了，至于服務的卸載就是在上面條件不符合的情況下就應該卸載了。
如果有必要的話，可以把服務的狀態區分出installed、active、deactive。
另外一個值得注意的問題就是，OSGi的DS是當服務的生命周期發生變化時，會通過bind-method和unbind-method去通知引用服務的組件的，這個特性我想即使是對于lazy式的調用也應該保持，這里也就需要DS關于服務通知的部分實現的代碼了。
來看看在這種服務框架的需求下的服務的生命周期的處理情況：
安裝服務：
服務被激活：
服務被鈍化：
服務被卸載：
5、服務的管理和維護
在服務的管理和維護上，應該說目前OSGi的DS模型提供的已經是很完整了，不過在服務中心點的服務的管理上則需自己實現了，基本可以參照OSGi的實現，需要考慮和增加的仍然是服務中心和各遠程的OSGi應用的通訊。
6、服務的組裝
服務的組裝方面，這個OSGi也是完全沒有支持的，這個可以考慮基于服務中心去實現，抑或完全可以單獨實現，只需可組裝遠程的服務中心中的服務即可了。
7、服務的出錯處理
服務的出錯處理，這個對于OSGi來說還是有點的麻煩的，就像erlang強調的一點一樣，不是進程隔離方式，自然很難保證當在同一VM中的一個OSGi服務出錯時不影響到整個VM。
只能盡量的去考慮另外一種方式了，當服務處理出錯時的廣播了，這樣可以做到fail-fast。
8、服務事件的廣播和訂閱
服務事件的廣播和訂閱，這方面OSGi目前支持的還是挺好的，不過在增加服務中心后，就需要增加事件廣播至多個服務中心了。
在增加考量的兩個因素方面，OSGi的DS是不支持aop方式的，不過要搭建一個服務庫不是一件什么難事，其實服務中心本身就已經是服務庫了。
上面的實現分析還是有點的虎頭蛇尾吧，最后就按照上面的分析總結成一張圖吧，來管窺下基于OSGi實現的分布式服務框架會是個什么樣的結構：
從上圖并結合服務的生命周期管理的部分可以看出要基于OSGi實現一個這種適合分布式場景的服務框架還是比較麻煩的，需要重寫的部分是非常的多，以此來看的話，目前OSGi最適合的場景應該還是如下幾種：
1、不需要分布式部署的應用場景；
2、需要分布式部署，但僅僅是分層的分布式部署，例如業務層在一臺機器上，數據層在另外的機器上。
不過基于OSGi實現一個這樣的服務框架也是一件很不錯的事，估計這也是EEG目前正在做的事，希望以后能在自己有空的時候動手做做這個基于OSGi的服務框架。