基于OSGi實現分布式服務框架歷程(二)
在這篇歷程中來完成對于JINI的Spike,目標仍然是判斷基于JINI實現服務的路由、查找需求的滿足度。
JINI是由Sun研究院制定的,其目標就是為了實現分布式的服務,所以在很多地方可以看到它和分布式服務框架是有不少重疊之處的,來先看看它對于需求的滿足度,最后再來分析做個總結。
1、怎么實現遠程的將服務注冊到服務中心?
在jini中暫時沒有找到遠程注冊服務到服務中心的方法。
jini的服務需要和服務中心部署在同一臺機器上,這個倒是可以通過服務管理中心直接將sar格式的服務部署上去,支持服務的動態管理,不過這是不符合分布式服務框架的需求的。
2、在服務應用端怎么查找服務中心的服務?
在服務的查找上,Jini采用的方法估計是和JNDI差不多的,不過相對來講要求就比JNDI高一些,因為它需要依賴它自己的serviceContext才能獲取到服務,這點不是很好。
3、有否現成可用的實現?
目前Jini的實現有好幾個,最出名的當然是sun自己的Jini Starter Kit,但對于實現分布式服務框架的話,Newton是個更好的參考。
4、是否支持Cluster?
由于服務和服務中心是在同一臺機器,因此不存在是不是支持Cluster的問題,大不了部署的時候整個cluster中的所有機器都部署一次。
5、可參考的資源有哪些?
jini可參考的資源主要就是:www.jini.org,通過這里可以找到挺多的jini的資料,比較好的有:
http://blogs.sun.com/warren/entry/jini_made_easier_writing_a
http://www.cheiron.org/seven/manual/html/developer/index.html
http://jan.newmarch.name/java/jini/tutorial/Jini.xml
從服務的注冊、查找和路由這三個需求去看,jini能直接滿足的就只有查找了,因為我們需要的僅僅是一個注冊、路由、查找的機制的框架,而不需要別的附加功能,jini就顯得有點和這個需求不是很貼合了,尤其是jini本身就是個功能并不強的服務框架,如果采用它的話會導致還需要進行改造,剝離它的服務那塊的機制或者做兼容,而且jini在使用時對于jini本身包的依賴性太強,這對于我們期待的pojo機制而言就挺麻煩了,當然,jini并不是毫無優點,如果大家去看看jini實現框架的那個可視化的服務的監控端,那實在是個很不錯的東西,具體了完整的服務生命周期管理(安裝、卸載、啟動、停止以及目前的運行狀態等)的功能。
jndi的簡單性和對于需求的貼合性使得它成為了我們用于實現基于OSGi的分布式服務框架的選擇。
在選擇了jndi作為服務的注冊、查找和路由機制后,我們需要逐步的演進基于OSGi的分布式服務框架的設計,在后續的篇章中我們將停留下spike過程,來分析下目前此分布式服務框架的狀況。
<< 基于OSGi實現分布式服務框架歷程(一)
>> 基于OSGi實現分布式服務框架歷程(三)
posted on 2008-01-18 19:24 BlueDavy 閱讀(5323) 評論(1) 編輯 收藏 所屬分類: OSGi、SOA、SCA